The log produced by debugging your launcher is relatively straight forward to follow. We have written as much in-depth information in plain English as we possibly could, to give you (and us) an understanding of what is happening when your launcher is running.
Most of it is pretty self-explanatory, however we are aware that not all users are tech-savvy so we have written this guide to try and help you as best as possible.
The launcher debug log file lines always start with a timestamp, so you can see at what time this action or event was executed like this > [15:32:19].
Streaming Config File / Enumerating License
This is usually the first section of the log. This is the start-up of the launcher, it will check your license online. Your users must be online and have a valid internet connection in order to use your launcher. If this fails, the launcher will fail too.
Creating new config
The launcher will always make a copy of your config file and place it in your launcher’s %appdata% folder. It will also check if it is encrypted or not.
A list of notable directories
Launcher User Directory – This is your launcher’s own, unique %appdata% folder where pretty much everything is stored, written to and downloaded to
Log Directory – This is the directory where your launcher debug log is written to and stored
Working Asset Directory – This is the directory where your local launcher library files are stored
Launcher Config Path – This is the directory where the launcher can locate and read your launcher configuration file from
If you have enabled any Global Events to use throughout your launcher, the status of them should be loaded at the start here in a list. If you enabled a global event and it doesn’t show here, then it’s not loading correctly. Double-check you have the Global Event enabled in your launcher project then re-build. If the global event is loaded, it will display <global event name>: 1 in this list.
This section is pretty self-explanatory. If you have ‘Check at Start’ enabled for version checking, it will perform those checks here. You can see what the launcher is doing with version checking.
You should be able to see the local file it has loaded and checked, and the remote version file here. If it is blank or doesn’t contain a valid URL, there’s a problem with your config. Copy the URL from the remote version file and paste it into your web browser to see if it loads. If it doesn’t, you must have a typo in the URL, there maybe a file permission error with your server or your server is just blocking the connection. If your patch server isn’t hosted with us, we cannot help you with this as it is not our server. You must consult your web hosting company if this is the case.
This block contains all the loading sequence for the page load. You should be able to see things like the launcher setting the window size (Width x Height) etc.
You will then see a list of objects being rendered and drawn to the launcher page. You can check here the count of the objects.
When an event is triggered and your actions should run, the launcher compiles all the available actions for that event and runs them in sequence, one after the other. So if you have ‘Start of Page’ actions setup, they should run in order upon the load of the page. You should see this list being rendered here.
If you have an image button that has actions applied to it when the user clicks, then you should see that trigger inside the debug log file with the series of actions sent over to be parsed, like so…
[15-32-21]: MGK Button Clicked (3604534 - p_0_mgk_button_3) on Page 0 [15-32-21]: Building 1 actions to send to Action List Queue. [15-32-21]: Added: Change Page|1|0|/commandline|<HKEY_CURRENT_USER>|<Software\Your Game Company\Your Product>|InstallPath|0||||| [15-32-21]: Build Complete.
In the above example at 15:32, we clicked the Text Button which had a ‘change page’ action assigned to it. You can see in our example log where we clicked the button and it sent the command to the launcher and completes the action list build.
Where it says “Added:” this is an action it has added to the list, followed by all the parameters required for that action. The parameters in between the | pipe’s, are the parameters required for that particular action. You should investigate this line and the parameters sent. Sometimes there maybe additional parameters that don’t make sense. Like the above example, CHANGE PAGE is the action and |1| is the page number, 1. After that, is a series of other parameters that are not factored in. They are just placeholders.
After the action list has been compiled, the launcher works will take the actions and perform the required functions with the parameters. This should show after the Build Complete. The block where it starts performing the functions are lines proceeding this block that start with “Executing Action List command” and it is at this exact point, the action is performed along with any parameters.
Query Strings and Constant Strings
If you use any PHP Query Strings or Constant Strings in your project, they will be sent to the dynamic parsing queue for parsing every so often.
PHP query strings will only be parsed when you’ve set them to be parsed, either at the start of the page or when triggered by a button (or another event).
Constant Strings are constantly parsed and will update every x seconds. In the debug log you will see this:
Closing Routine after 1 iterations.
When you see this, it just means the runtime parsed 1 or more constant strings inside that page. You may see a lot of this line if your launcher contains any constant strings.