Category Archives: Programming

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.

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)

While experimenting with making my own controllers recently, I needed a nice visual way of testing them in Windows. For some reason the ‘Game Controller Settings->Properties’ panel doesn’t always work, especially for joysticks with lots of axes and buttons.

6 Axis 32 Button Joystick

4 Axis 11 Button Gamepad

As you can see it’s pretty simple and just shows a visual representation of each axis, POV and button. Currently it supports Joysticks with 8 axes, 4 POV and up to 128 buttons. I haven’t had a chance to test it with over 32 buttons so I would be interested to here from anyone who has such a device.

It’s currently only alpha software, so there will probably be the odd bug, please post feedback here or drop me a email. It should work on XP upwards but I have only tested it on Windows 7 64 bit. You just need Net framework 3 and DirectX 9 to run it.

Over the last year I have been using the CNC 3020 machine I got from Ebay and I have been quite pleased with it. It has done what I expected it to do for the price I paid for it. I have however made quite a few additions and tweaks, which I will hopefully document on this blog soon.

I have been building a aluminium enclosure and I am hoping to integrate all the electronics and laptop in this enclosure. Here’s a picture of the simple Sketchup model I made.

CNC Enclosure Sketch

The front panel will also have a couple of joysticks and a bunch of buttons for controlling the Mach3 software. With the exception of the screen, it will pretty much be a self contained unit. (I only plan to a dozen or so buttons to operate the things I use most in Mach3)

This is partly why I have been experimenting with the Teensy USB development boards and having managed to get the controller part working, I thought it would be cool if I could replicate some of the Mach3 software LEDs with real ones. This involved writing a plugin for Mach3 to communicate with the USB controller. Fortunately there are some nice people out there, that are will to make tutorials and templates that make this much easier. I used the Plugin Wizard from Joshua 1 Systems, which although was designed for Visual Studio 2008, I was able to get it working with Visual C++ 2010 Express. I was then able to integrate Simon Inns USB Hid Library. Now I am no C++ coder, and I felt like it was a major achievement to get this working. As sad as it sounds, it was really satisfying to see that LED go on and off by clicking a button in Mach3.

So all that is left, is to try and put the whole lot together. I have the software designed, along with most of the hardware. I just need to finalize what buttons and LEDs to use for Mach3 and design the PCB for the controller. I am also waiting on some hardware parts to finish off the enclosure frame. I hope to post some more details and pictures soon, in the meantime if you need any aluminium profile I can highly recommend KB Aluminium and Motedis who have been extremely helpful in the building of this project.

The Teesny series of USB development boards are fantastic for making your own gaming controllers. If you don’t want to get your hands dirty then Generic HID is a great GUI tool for the Teensy++ 2.0. If you have a Teensy 3, then this guide by Kenton Hamaluik is a good starting point. If you want complete control over your Teensy++ 2.0 joystick then read on…

First you will need the Arduino and Teesnyduino software installed. I would also suggest you make a backup of the arduino/teensy folder just in case. Next I would seriously recommend a decent text editor, especially if you intend on doing lots of editing, while you can obviously do it in notepad, things like custom syntax highlighting make life much easier. I have personally been using Editpad Pro for many years and wouldn’t be without it now. Lastly if you are running Windows Vista upwards, you either need to turn off UAC (not recommended), run your editor as administrator or work on the files outside of the program files directory and then copy them back after.

Ok lets get stuck in…

Add A New USB Type To The Tools Menu

We are going to add a new USB type for our new joystick and we will call it Gamepad. First open up the ‘boards.txt‘ file found in a ‘arduino install folder\hardware\teensy‘. We want to add the new USB type for the Teensy++ 2.0. (This should work for the Teensy++ 1.0 and the Teensy 2.0, just change accordingly) Look for the ‘teensypp2.menu.usb‘ entries. After the last one (teensypp2.menu.usb.flightsim.fake_serial=teensy_gateway) add the following lines.

The first line is setting the text that the menu item is going to show. The second line is setting a preprocessor directive, which is basically telling the software to use our USB code for this device. The last line is used for creating a serial port emulator. After saving the file, if you open the Arduino software, you should have Gamepad Controller listed under the Tools, USB Type: menu. (I have included the ‘boards.txt‘ in the download file for those lazy people out there)

Adding The New Includes

If you look under ‘arduino install folder\hardware\teensy\cores‘, you will see there are several folders, in fact one for each USB type and a global teensy folder. (Ignore the teensy3 folder as the code is completely different) We need to create a folder for our new USB type here. Lets make a folder called ‘usb_gamepad‘.

Now you may be wondering how does the compiler know what files to use? When we compile our sketch, it looks in the global teensy folder and reads the relevant USB files, it then checks the preprocessor directive to see what USB type is defined, and then includes the files defined by that directive.

So in the ‘arduino install folder\hardware\teensy\cores\teensy’ folder we need to edit the following files.

‘core_id.h’, ‘usb.c’, ‘usb_api.cpp’, ‘usb_api.h’ & ‘usb_private.h’

For each file we need to add a couple of lines, after the last #include to tell it where our files are, so ‘core_id.h‘ becomes…

There is an excellent guide here on the descriptors, but the key thing is to make sure the data is byte aligned. Our gamepad has 11 x 1 bit buttons and 4 x 10 bit axis, this is a total of 51 bits. 51 is not evenly divisible by 8 so we need to pad it out to 56 bits. The following part is the 5 byte padding.

The order in the hid descriptor is also very important, as this is the order the data must be laid out in the packet sent from the controller to the host. You shouldn’t have to edit anything else in this file unless you decide to change the variable names.

usb_api.h

This is the heart of the gamepad class, and is where we configure the controller data to be sent over the USB. Earlier I said the order was important, the following picture shows how the host is expecting the gamepad data to be formatted.

Gamepad USB Packet

This is the order from right to left that the buttons and axis are defined in the gamepad hid descriptor. You can see the first 11 bits are the buttons, followed by 5 bits of padding, 10 bits for the X axis, 10 bits for the Y axis, 10 bits for the RX axis and 10 bits for the RY axis.

core_id.h

I don’t think this file is even needed, as I couldn’t find out where other core defines were referenced. In fact I took it out completely and the gamepad worked fine, but I have included it here just for completeness.

The Gamepad Sketch

Here’s the actual Arduino sketch code. This is the part you will need to edit to suit your controller. You need to adjust the button and axis pins to match you physical connections to the Teensy++ 2.0. I am using pins 0 to 5 and 7 to 11 for my buttons. Pin 6 is the LED pin, which is actually flashing at 100 times per second in the code. You can’t see the individual flashes but at least you know the code is running all the time the LED is on. I am then using A0 to A3 as the analog input for the axis. I am using a MMA7361 Triple Axis Accelerometer for 2 of my axis, so you can ignore that part of the code if you want. I have included it in case anyone else wants do do something similar.

A recent project required me to print a lot of info to the immediate window via the Debug.Print command. A quick search came up with a few suggestions for clearing the output in my program but nothing that worked for me. They did point me in the right direction and I came up with the following code that seems to work in Microsoft Visual Basic 2010 Express.

The code itself is simple, find the VB window, focus it, and then send some keystrokes. The key thing is the name of the window, this must be an exact match, so you will need to adjust it for other versions of VB. It also relies on the keyboard shortcut for the immediate window, which in VB Express 2010 is Ctrl+Alt+I.

I have promoted Keybinder to the new site as it is still an ongoing project. Even though it has had 120 downloads nobody had reported a major bug, which could have prevented it from working on Vista/Win 7. Anyway to fix the problem I have move the location of temp data to the users local appdata\Keybinder folder and also moved the command list location to the users documents\Keybinder folder.(I never noticed the problem because I don’t have it installed in the program files folder) I also added some new features, including voice commands. You can find more info and download here. If you are trying to auto update and it doesn’t work, trying running Keybinder as administrator, the new version should automatically move your profiles/command lists to the new locations.

What was puzzling me, was an almost identical piece of code was working fine a few lines above. Anyway I eventually figured out the the parameter names are pretty much irrelevant when using an Access database, but it’s important the order matches the query. So simply moving one line of code fixed the problem.