{"id":483,"date":"2022-08-11T08:55:58","date_gmt":"2022-08-11T07:55:58","guid":{"rendered":"https:\/\/byteboxmedia.support\/?p=483"},"modified":"2022-08-11T08:57:27","modified_gmt":"2022-08-11T07:57:27","slug":"aops-troubleshooting-guide-part-1","status":"publish","type":"post","link":"https:\/\/byteboxmedia.support\/docs\/game-launcher-creator-v2\/aops-troubleshooting-guide-part-1\/","title":{"rendered":"AOPS Troubleshooting Guide – Part 1"},"content":{"rendered":"\n

AOPS (Advanced Online Patching System)<\/strong> may seem a bit daunting to look at or configure, but it’s actually very easy. We made the AOPS system to make patching for you as easy as possible, the issue is, all the fields AOPS requires, are actually needed. So when you see all those fields to fill in, without filling them in, won’t make AOPS work for you.<\/p>\n\n\n\n

We have a new built-in wizard for AOPS, built right into GLC V2, you can access via File > AOPS Wizard<\/strong>.<\/p>\n\n\n\n

AOPS has been developed and tested with hundreds of different types of setups and does work 100%, when there is an issue, 90% of the time it’s a user-error, but no fear, we have written this guide to help and assist you in troubleshooting what it could be.<\/p>\n\n\n\n

To enable debug logging, you first need to go into GLCV2 editor, open up your project, go to the AOPS settings and check the box ‘Allow Debugging Prompt’<\/strong>, then rebuild your launcher.<\/p>\n\n\n\n

Debugging the Patcher<\/h2>\n\n\n\n

First thing’s first, AOPS contains a built-in debugger, enabling you to see what the potential issue or problem could be. To do this, simply build your launcher<\/a>, then run it as normal and check for updates so AOPS launchers. When AOPS launchers you will be presented with a message…<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Click Yes and this will produce a debug log. Your users can do this also.<\/p>\n\n\n\n

The debug logs are produced in a temporary folder on yours (or your users) computers, it goes under %appdata% and the folder inside %appdata% will be whatever your game launcher is called, so if your Launcher Title is ‘My Game’ then the path to this temporary folder would be %appdata%\\My Game\\, it would look something like this<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

N.B – This is NOT your GLC project folder, it’s a folder that is created on yours and your users computers, there should be no GLCPro in the path.<\/p>\n\n\n\n

When you run the launcher in debug mode, it runs as normal and produces a debug log file<\/a> with every step it takes, this is just a normal text file you can view with Notepad (or Notepad++). It’s a file inside the temporary game launcher folder, under a folder called patchtemp called patch.log<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Inside this log file will display exactly what the game patcher is trying to do every step, so whichever step is the last step, is usually where the problem lies. In this guide, we will look at most of the common errors and see how you can rectify them.<\/p>\n\n\n\n

Stage 1 – Loading Patch Configuration<\/h3>\n\n\n\n

Stage is the first stage of the AOPS patching process. It initialises all the information from your patch settings file (the settings you put in GLC V2 when designing your launcher). If this is the stage where AOPS stops and doesn’t do anything else, then there are issues with your configuration settings. See the section Common Errors<\/strong> below.<\/p>\n\n\n\n

Stage 2 – Creating Temporary directories<\/h3>\n\n\n\n

This stage is where all the temporary directories are setup and stored for further use into the patching process…<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

If AOPS stops at this stage, then there was a problem writing out to the users AppData directory. The AppData Directory is usually the most freely available directory to write to, this is why we and other software developers use it. If you or your user have issues writing to this directory, you must have some serious restricted privileges on your computer. Either this, or a 3rd party software is stopping AOPS from writing to this folder.<\/p>\n\n\n\n

Stage 3 – Checking Directories and Patch File URL<\/h3>\n\n\n\n

This stage checks that the temp directories were setup correctly and are accessible and it also checks if a Patch file was specified, if the patch file was specified, it will start to download this file. If it stops at this stage, it’s either for the above reason or your patch file was not specified.<\/p>\n\n\n\n

Stage 4 – Downloading Patch File<\/h3>\n\n\n\n

This stage downloads the actual patch file from your server. When your patch file is downloaded from your server, it will be saved in this temporary folder as files.lst. Again, you can open this up with Notepad to inspect if you wish. If AOPS bombs at this stage, there’s either an issue with the way you’ve typed in your patch file url or it’s not accessible from your webserver. See Common Errors below. You can also put your patch file URL (in the debug log file) into Chrome\/Firefox and go to that page and see if it loads up, if it doesn’t, you know there is surely an issue.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

If you see our debug log above, if there was an error, we would go to https:\/\/byteboxmedia.co.uk\/testdir2\/patch.gcl and see if it loads within our browser. If it didn’t, we know there would be either a problem with the link we provided or something on our webserver blocking the file from being accessed.<\/p>\n\n\n\n

Stage 5 – Patch File Successfully Downloaded<\/h3>\n\n\n\n

If you have reached this stage of the AOPS process, this means your patch file has successfully downloaded and can be seen in your temporary folder as files.lst.<\/p>\n\n\n\n

Stage 6 – Retrieve Local Installation Information<\/h3>\n\n\n\n

Stage 6 is all about getting the current installation information from the registry. If you selected ‘Retrieve Install Location from Registry’ inside GLC V2 setup, this is where that stage is performed. So it will read the users registry and hunt down this information. If AOPS bombs at this point it’s because the registry information wasn’t found.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

As you can see from our settings above, we specified the registry settings AOPS should look for. The current key has no starting trail and no end trails \\ – you don’t need these.<\/p>\n\n\n\n

If you didn’t choose ‘Retrieve Local Installation Information’ within your AOPS patching configuration then the AOPS system will assume that the files are to be patched at the current location AOPS\/Your Launcher is ran from.<\/p>\n\n\n\n

Stage 7 – Testing Installation Directory<\/h3>\n\n\n\n

This is an important stage for AOPS to check whether the directory it will be installing the patch files to, exists… it will use the information you provided through ‘Retrieve installation from Registry’ section or through the current directory of which AOPS is launched from (where the launcher is installed to).<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

If it bombs at stage 7, the directory doesn’t exist or is protected somehow.<\/p>\n\n\n\n

Stage 8 – Patching Stage<\/h3>\n\n\n\n

This is the most important stage of AOPS. This is a stage which will cycle through all the files in your patch list<\/a> file and compare them with what’s installed on the users computer, it will then make a decision whether or not to patch. This stage will cycle until all files are completely scanned and checked. Then it will proceed to the final stage.<\/p>\n\n\n\n

Let’s take a look at Stage 8 more in-depth here.<\/p>\n\n\n\n

This is the order in which AOPS operates Stage 8, for each individual file:<\/p>\n\n\n\n

  1. Check data from Patch File<\/li>
  2. Check local file exists<\/li>
  3. Check local file size and local file checksum<\/li>
  4. If the checksum is the same<\/strong>, go to next file<\/li>
  5. If the checksum is different<\/strong>, download file, install file, loop back to part 1<\/li><\/ol>\n\n\n\n

    If the checksum was different for a file, this means either the users installed file was different to what is on the server or it didn’t exist at all. So AOPS will download and install the file.<\/p>\n\n\n\n

    If AOPS has to patch a particular file, after it has downloaded and patched it, it will re-scan over it again, just to make sure that the local file now has the same checksum as the server file.<\/p>\n\n\n\n

    If AOPS scans a file and the checksum is the same as the server, it will just move onto the next file. This cycle repeats until all files listed in the patch.gcl file are looped.<\/p>\n\n\n\n

    Stage 9 – Updating Version Number<\/h2>\n\n\n\n

    After AOPS has completed everything, before it finalises, it needs to update a version number somewhere. This tells AOPS when it runs again, which version is currently installed, otherwise it will just keep thinking there is a new update available.<\/p>\n\n\n\n

    You need to fill out one of the following in the AOPS configuration:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    If you are updating the version number via Registry, select Registry and fill out the corresponding fields. If you are updating a local INI or local file (ie: version.txt) which is in the same directory as the launcher, then specify that filename in the relative box (and don’t forget to select the checkbox for which one you’re using).<\/p>\n\n\n\n

    \n\n\n\n

    Common Errors<\/h2>\n\n\n\n

    Most “issues” with AOPS are typically user error. Here we list possible issues and their causes along with possible solutions.<\/p>\n\n\n\n

    Versioning<\/a><\/strong><\/p>\n\n\n\n

    AOPS only recognises whole integers or floating values to one decimal place. You should use either 1,2,3,4 incrementally for update triggers, or use 1.1 or 1.12 or 1.123. Please remember, this is only an internal reference number for you and AOPS. It doesn’t actually affect the versioning of your game or app, or files.<\/p>\n\n\n\n

    I checked my debug log and it keeps repeating the same file on the scan<\/strong><\/p>\n\n\n\n

    This usually means there is an issue between the file on the server and the file on the local machine. This is usually because you have rescanned your files in GLC, then produced a new patch file but not uploaded the new renamed files and overwritten them on the server. You must always ensure you use the same HASH<\/a> SALT for your original launcher all your future patches.<\/p>\n\n\n\n

    You must ensure whenever you push out a new patch you follow these steps:<\/p>\n\n\n\n