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 ...
Deadly Database
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.
The Solution
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.
Conclusion
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".
4 comments:
I assume by databases you are talking about 2da changes.
What I can tell you (similar but I think different situations) is that using a saved game and continuing on after you have created more content will have some kind of issues, although it weirdly works in some instances (conversation option to warp to a new area you just made etc).
Islander has always felt like a house of cards to me. Would it be affected by anything you are talking about? I dont modify any 2das in game.
Hi E.E.
No, the database functions create databases that are completely different to 2da files. So, if you ever have used SetCampaign .... type funtions, you will have created a database for the module. It is this database that (if not managed carefully) that causes the crashes.
Interesting to hear about the new content issue ... I imagine its along a similar line.
As for Islander, do a check for any functions you may have used that may have "campaign" as part of the function name, like "SetCampaignInt, or SetCampaignString, etc. If you have, then it is almost certainly these that are causing you crashes in the game at some time or another.
Modifying 2da files causes different problems to the ones I am talking about, but could still have a disasterous impact as well.
Lance.
There are a few SetGlobals.... problem?
Hi E.E.
No, SetGlobalxxx functions work fine, as they do not create a database. Only the SetCampaignxxx functions create a database and have the potential to cause crashes.
To be clear ....
SetLocalxxx work fine.
SetGlobalxxx work fine.
SetCampaignxxx can cause issues.
Lance.
Post a Comment