Category Archives: Gaming

I know it’s been a while since the last post, I have been working on Atlas Server Assistant for a least a couple of hours every day but just haven’t had as much progress to report as I would have liked. This is definitely the biggest programming project I have ever done, it’s now up to about 30000 lines of code, spread over 36 different classes and 24 windows forms and there is still a way to go. Also, as always with this project, I seem to take 2 steps forward and then 5 back!

After my last post I continued finishing up the deployment and server initialisation code and starting working on the schedule system, I thought I was making good progress and decided it was time to test it out on my local network server with the small 2 by 2 test grid. This is where I ran into a number of issues with the first time setup and deployment code and the whole setup process seemed clumsy. First off I encountered a number of crashes, related to initial values not being set correctly for first time use. Then I had problems connecting to the test server. I wasted a bunch of time trying to work out why I couldn’t connect, checking ports were forwarded, and disabling firewalls, only to find out it was a mistake in the server command line arguments and I had forgot to set the MaxPlayers parameter

After that fiasco it was time for a rethink on the first time run process and especially the Redis configuration. So now when you run the application for the first time you are asked to choose the program mode as before and then you will be prompted to set the SteamCmd and server paths. Regardless of the program mode you are running in, they are both required, so it makes more sense for them to be configured first. If you have them both installed you can simply set the paths or they can both be downloaded if it is a fresh server setup.

Once the paths are configured you will be prompted to import your server grid editor project and also set the admin password. The machine layout window has been tweaked a little with a toolbar and info label but the machine setup process remains the same. Once you have completed the import process you will be asked to configure the Redis database. The Redis configuration has been completely redesigned and now effectively ignores the grid editor project setup. The reason for this is to simplify the setup, while I guess technically, it is possible to have each database connection on a different machine, I suspect that most people, like me, are using the default settings. Now if you are running a single machine grid you only have to set the Redis password and if your grid is already running, it will even do that for you, by reading the password from the Redis config file. It also allows for a custom Redid installation and running the Redis server as a service. While it won’t start the Redis server service if using this configuration, it will check if the service is running and warn you if it is not. If using the standard setup it will start the Redis server before you try and start any Atlas servers.

The very last part of the configuration is the deployment. This is where you you you copy the ServerGrid.json, ServerGrid.ServerOnly.json and map images to the server, along with any global Game, Engine, GameUserSettings ini settings and the AllowedCheaterSteamIDs.txt file. During this process, if it is a fresh server installation, all grid servers will be started and stopped to initialise them and the Redis database.

I am pretty happy with this part of the application now and I can get a single machine grid, using the 2 x 2 sample grid, up and running in a minute or so without ever touching a batch/config file or without setting anything up in the server grid editor, other than the island layout.

Below are a few images of the new setup and configuration windows.

Once the setup was finished it was time to move on to the schedule system. There are currently 4 types of scheduled task implemented.

Restart the server. (Keep the server running smooth by rebooting it daily)

Check for server updates. (Keep the server up to date)

Server messages and Rcon command are fully implemented but I still have some work to do on the restart and update tasks, as these require a bit more work and a lot more testing. Here are some work in progress images of the scheduled task system windows.

As I have begun to use the application and test it I have been tweaking various parts to make it look and feel nicer and to make life easier. I redesigned the toolbar layout, icons and added new buttons to control the Redis server, start/stop the entire grid and edit various configuration settings. I changed the status strip to show a few key pieces of useful information.

When starting the server it will check if the Redis server is running and test the connection before starting the server, it will also check if the ServerGrid.json or ServerGrid.ServerOnly.json files have changed and prompt you to redeploy them. You will also be warned if the server is out of date when you try and start it. On top of that there are options to change the UI colours and other application settings. Below are some more work in progress images.

So as it stands, the application is almost fully functional and in fact today I did upload it to one of our gaming servers, so I can begin testing it in a working environment. The setup went pretty smooth and I only found a couple of small bugs, related to the UI. The next phase is to finish off the schedule and then concentrate on testing, bug fixing, tweaking and fine tuning.

Although are group have not been playing Atlas too much, we had outgrown our freeport and decided it was time to move on. Our feeport is in the middle of a 5×5 grid, so we decided to fire up the surrounding 8 grid cells. After setting everything up I immediately ran into issues starting the servers, they were crashing with a ‘ProcessTravelEntry’ error. I spent way too long trying to track down the problem, which actually turned out to be a simple typo in the ServrGrid.json file. I had simply missed a quote after an IP address. This brought home the importance of the application managing the data to prevent such simple mistakes.

Indecently if you want to verify your ServerGrid.json export file, simply load it as a project in the Server Grid Editor and if there are any mistakes like mine, you will get a parse error, like the image below. Note. Don’t load an export as a project for editing as it doesn’t contain all of the project data!

Since my last post, I haven’t spent as much time coding as I would like. I have spent far too much time trying to get our server settings just right and just when I think they are good, the devs make major changes, like the cost of stone structures. Then I waste more time trying to get the crafting overrides working or trying to find another solution. My time spent coding hasn’t been super productive either, as I have run into various issues and every time I think I am getting closer to having something functional to test on our servers, I find a bunch of things that need adding and my todo list gets longer instead of shorter.

Carrying on from the last post, I continued tweaking the setup process by adding the ability to download the server files and configure the Redis server. We are using this version of Redis for our grid, as it can by installed as a service, once configured you don’t have to worry about it and it’s once less window, cluttering up the screen. Because others will be using the included version of Redis I need to account for both options. I ran into an issue here where the included Redis server would not even start on my machine, failing with a not so useful ‘Unknown error’ message. The problem turned out to be with the bind setting in the config file, so if you have problems, try removing the comment (#) from the ‘#bind 127.0.0.1’ line. If you are running your grid on a single machine, you should be doing this anyway as all the servers will only need local access. If you have your grid on separate machines, then this won’t work as the servers will need to access Redis from your external IP, in this case you can try ‘bind 0.0.0.0’. With that part of the setup complete I also realised that the Machine setup form is a useful way of editing the grid, should you change the machine layout, so I added the option to run this at any time, rather than just once during the project import.

Moving on to the UI, I tweaked the way grid cells are drawn. Now cells that are not configured are drawn in grey and offline cells are drawn at a lower opacity. This makes it easier to instantly see the state of the entire grid, even when zoomed right out. I added custom rcon and server message menu items, with their own editor windows, so that you can build you own custom right click menu items. Finally I added a simple window for adding users to the ‘AllowedCheaterSteamIDs.txt’ file.

Next comes the deployment, as before I can start the servers, they need all of the data for the grid. First off, because I am using the grid editor project, I needed to be able to export the ‘ServerGrid.json’ and ‘ServerGrid.ServerOnly.json’ files the same way the server grid editor does. It turns out this requires the ‘Island.json’ file, so I have embedded it in the project but also given the option to override it locally should it need updating. I also have to copy the map images to the server folder. Finally there is the ‘AllowedCheaterSteamIDs.txt’ file and any global ‘Engine.ini’, ‘Game.ini’ and ‘GameUserSettings.ini settings but these can’t be done unless the servers have been run before. As part of the deployment, I have to consider a fresh server install and subsequently start and stop each server before I can do anything with the save folders. While I could possible create the folders manually, I am guessing that during this initial start up phase the Redis database is also populated.

That is where I am now, working on the initialisation and deployment code. There will be a simple UI where you can choose what to deploy, should you want to make changes to the grid or global settings.

Testing all the functionality is both tedious and time consuming as not only do I have to test that it works, but also if something doesn’t work, make sure a useful message is shown rather than simply crash. Hopefully these posts give you an insight into what is involved and why it is taking so long and also keep in mind I am just a hobby coder, not a professional.

Anyway, I’ll leave you with a few work in progress images, until next time.

Over the last couple of days I have been working on the remote communications between the master and slave applications. Two way communication is required, along with the ability to send files. My current thinking is that the slave, really is a slave and does nothing unless the master tells it to. Obviously the master will need to send commands to the slave, but also the slave will need to send commands to the master, such as request the grid data for example. The master also needs to send the grid data to the slave along with other files.

Having not done much in the way of network programming before, it was an interesting challenge. The first attempt, although it worked, was overly complicated from the code point of view. After remembering the K.I.S.S rule, a phrase my good old dad used frequently, a rewrite of the code and protocol produced a better result that was cleaner and easier to debug. There is still more to do with this, but now the basics are working, I can move on to last part of the setup process, installing the server files and exporting the data to the server. As it is the same for master and slave modes, it means that I can really concentrate on getting the master mode finished.

Having two different modes means having to do various checks to see which mode the program is running in but I think is preferable to having separate applications, as they share a lot of base code. The first time you run the application you will be prompted to choose the mode, and configure the settings for the master machine. If all goes well it will connect to the master and download the grid data, as seen from the images below.

The machine Ids that you configure on the master act as part of the authentication system, so that slaves can only connect to the master with the correct machine id and password. By default it will use the admin password, but this can be changed if needed.

While I have a lot of the core functions already running in the master application, such as built in rcon client, a simple schedule system, server queries, server updates and the ability to start and stop servers, the whole code is a mess. I have really just been testing the individual parts and now it is time to try and tie it all together with a clean user interface.

My first server assistant program was for the original Call of Duty way back in the early 2000s. Wow! look at that interface…

Things have moved on since then and I have written numerous other tools to assist me in setting up and running game servers over the years. Most of them have not been released publicly, with the exception of Insurgency Sandstorm Server Assistant, not because I am mean or selfish, but because they were thrown together quickly and I don’t think they were good enough for public release. A lot of the time, I will use other peoples tools, such as the excellent ASM, if there is already a good functional tool available.

Atlas is a different story however, as it has only just been released in early access and it’s setup is a bit more complex than your average server. This is because the Atlas map is divided into cells and each cell is a server instance. So if you have a 2 x 2 grid you will need to run 4 separate servers. In our group we are attempting to use a 5 x 5 grid, which means 25 servers to not only configure but also maintain and update. I was initially under the impression that you needed a separate install for each server but fortunately this is not the case, as you can run multiple instances from a single server installation. Even with multiple instances per server, the usual method of batch files becomes a nightmare as the grid size increases, hence the need for a suitable tool to assist in setting up the grid and maintaining it, with as much automation as possible.

Do you really need a big grid, if a single grid cell is 4 times the size of ARK’s Island map? It depends if you are playing solo, or with a group, how you play the game and what you want out of the experience. There appears to be a lot of hidden content in the islands and if you want to get the full experience you are going to want a good sized map with as many of the islands as possible. A big part of the game is discovery, by default you are clamped to maximum of level 8 on a home server and will have to discover new areas to level up more. If you have already played with the Server Grid Editor you will have seen discovery zones placed around islands. What you probably wont have seen is the discovery zones that are embedded in the island map files. These are the hidden content I was referring to. Take a look at the image below, which is the discovery zone information for cell 1,5 in the full 15 x 15 server grid. You can look at in the grid editor by Ctrl + Right clicking on the cell.

Now I haven’t checked them all, as I didn’t want too many spoilers, but in particular I looked at Pool of the Goddess of Dawn. One reason was because of the apparent typo in the Manual Name column. ‘Mnr_D_Near_04-PoolsoftheGoddessofDawn’ I am pretty sure it should be ‘Mnt_D_Near_04-PoolsoftheGoddessofDawn’. The Mnt_D_Near_04 is one of the umap files located in the ‘Content\Maps\SeamlessTest\Mnt’ folder and if you open it in a hex editor you will find a reference to Mnt_D_Near_04-PoolsoftheGoddessofDawn. What does all that mean in English? Simply put, any of the island map files can contain its own discovery zones and some of these, like the ones with power stones a very important for the story/end game.

If you have made it this far without falling asleep then I applaud you. Perhaps you were just curious if I would actually talk about the topic title. Some of you probably just scrolled down here and now you are feeling guilty for not reading the rest of my drivel. Part of the reason for the forwarding text, was to explain that there is a lot to learn about the game and it’s server mechanics. While it may share a lot of things from Ark, there are also enough differences to make it a learning experience, for example I hadn’t even heard of Redis until Atlas. It’s not going to be a trivial task to make a good, functional server manager application. It’s going to take some time and a lot of work and experimentation to get it right.

I am sure there are other people out there working on there own server manager applications and they will have different ideas but for me initially there a 3 main priorities .

The application should make it as easy as possible to setup a server grid.

It must be able to automatically update, start and stop servers.

It should have a nice friendly GUI that requires minimal instructions to use.

There are a whole bunch of other features that I have in mind to make maintaining the servers easier but the first stage is complete the above objectives. My idea is to have a master application that you use to setup the grid and also manage it’s local servers. Then on each machine that has servers installed on it, you install a slave application which controls it’s server instances through the master application. The first part of objective 1, is to get the server grid into the application. I do this by importing the Server Grid Editor project and the exported map images. In the first image below I have imported our grid project, images and I am beginning to setup the machine ids. The second picture shows the completed machine id setup. This took about 2 minutes to do. Also note that none of the ports were configured in the project, the import process took care of all of that for us, using the starting ports specified. I have used the same methodology used on the full server grid, which is increment game/query ports by 2 and seamless ports by 4, after all there is probably a good reason the game devs did it that way.

Obviously this part of the setup depends on the size of your grid and how many physical machines or virtual machines you have. Also note, you probably won’t have to enter the IP addresses for each machine, as the plan is to have these auto configured as well.

How many servers can you run per machine? That really depends on the specs of the physical machine and how many players you want on the servers. The number of players is a big factor as if you have a small group who all player together, then chances are you are all going to be on the same server, which means the other servers will be dormant and therefore using less resources. As we don’t have our full grid running yet I can’t help much with this, there is a thread in the official forums here, where server owners are sharing their system specs but at the time of writing there are only a few replies.

Going back to objective 1 in my list, the next part of the setup process requires that the slave application is installed on each machine and connected back to the master application. This requires some form of client/server networking protocol and without this functionality, the whole project falls apart. Having never done anything like this before, it’s not a trivial task and while I have some basic two way communication working, it’s a long way from being functional.

I will try and keep this blog updated with my progress, over the coming days/weeks for those that are interested.

Note 1: Gadgets were discontinued from Windows 8, but there does appear to be a way to bring then back.

Update: I have uploaded a new version which should now work if you have Internet Explorer 11 installed. (To uninstall the old version right click on the desktop and click Gadgets then right click on KF2 Monitor and click uninstall)