It came somewhat as a surprise when as I was testing my module it came crashing to the desktop. I had just created an entrance to a small cave area I required and was testing the transition between it and the outside area when this happened:
What had gone wrong? I had not changed any of my scripting and was unaware of any corruption in my files, and so I was somewhat dismayed when I could reliably repeat the crash every time I tested the new transition. I then tested an older transition and all seemed fine, until that was, I tested it a number of times, and then, sure enough, it would crash to the desktop. More investigation was required ...
I have often heard of the problems people claimed that the inbuilt database functions caused the game, but had never encountered anything specifically wrong with using them before. However, after some investigation, it turned out that the transition crashes were occurring after a database call had been made by one of these functions. Yet, as it turned out, it was not specifically this, but only if the database reference was new. That is, if the database reference already existed in the database, then any call to it did not lead the game to crash. However, if a database line was added to the database during the game, then the game was likely to crash at the next area transition, especially if either of the areas were large. (Larger areas appear to expedite the chance of a crash after the new database call occurs.) Even if you were lucky to get away with one transition, the game would crash at a transition soon after.
As The Scroll makes good use of these database functions I needed to find a resolution, or all my efforts to date with them would have been for nothing! Astute readers will have probably already guessed at the solution I finally came up with: Make sure the database is established (initialised) before the player plays the game. So when a player starts The Scroll for the first time, they will now be presented with the following GUI screen:
Hopefully, players will recognise this as a minor inconvenience to help provide a crash free game session thereafter. (That is the plan at least.) Depending upon how one has used the campaign database functions will also determine how you go about setting up your function to set up the database. For myself, there were one or two simple single lines to add a single row reference, and in other instances I was able to use a loop to set aside all the rows (for objects) that I needed. For added security, I added the variable holder reference to the object in question as a local string to refer to when the database variable holder was required. This was just to make sure there was no change in variable holder name between me setting the database up and the time I needed to refer to it.
It may be that you have had some strange transition crashes in the past and wondered what caused them. Hopefully, having read this you will be armed with another potential method to overcome them. I also discovered that Runtime Errors (especially on exiting the toolset) are caused by misuse of Include files. i.e. Different scripts may be calling the same Include that is already included in another Include associated with them (if you see what I mean).
So, if you have any information on what causes a game (or toolset) to crash, which may not be obvious at first glance, then please respond in a comment. Shared info like this is definitely a "prevention is better than a cure".
Schedule for Emerald City Comic Con
20 hours ago