Unfortunately, the dreaded save game issue that I last reported reappeared again. BUT, there is some good news: This time around, although we sadly did not get any gaming in, we did manage to spend the time doing enough "debugging" to help me to be able to reliably duplicate the problem (as far as I can tell) on just the LAN to be able to allow me to continue trying to find/overcome the issue before we next play. And, from that debugging, I believe I truly have found the route of the problem!
The issue stems back to the day I tried to resolve a "minor" issue where a player (upon returning to a saved game) would have to DISMISS a companion and then have to ask them to rejoin again, because the companion had not re associated itself with the player, but thought it was part of the party. It was simple enough to dismiss/re invite to work around the problem, but somewhere around v2.14, I wrote the piece of code that would "automatically dismiss" the companion "properly" when a player returned to their saved game, so that the player only had to re-invite the companions again.
In testing, this all appeared to work well and good, but it was the process of dismissing the companion that introduced the SAVE GAME issue, because when a player would rejoin the game, their own heartbeat script fired (which is the same as the companion's), and thereby "remove" themselves from the game that they were about to load back into. At that point, the game thought it was a new PC entering the game that shared the same name (which is not allowed in the campaign) and threw up the warning refusing them entry. It also explains why if we tried to disable this warning (to allow the player in anyway), that the session then treated them as a new PC entering the game, stripping the character of their equipment, which then triggered a second warning that the PC had "Missing Equipment" for their saved PC. Allowing a player to be able to examine their character by bypassing this check as well, confirmed all their equipment had indeed been removed.
After adding the simple && oPCORCOMP != oMainPC piece of code, to ensure the player PC was not removing itself from the party/session/game, the player was then allowed to rejoin the session, which was now recognizing the PC was still in the game. So far, I have tested this locally, and it does appear fixed. I hope to be able to confirm for sure after my friend joins and reloads via WAN. However, I reasonably confident that this has indeed resolved the problem this time around.
I am hoping that we may be able to continue from our last successful saved game (where the player can still reload), but there is a slim chance that we may have to go to one save game earlier, if the "damage" was done in the session prior to the last save. At the very worst, we will only be one session behind, which can actually be "fast played" in about five minutes, as the players will not have to reread the material they had in the session before (which had been more than the usual amount).
So, version 2.18 is now available, which contains the fix. It also includes a couple of other minor fixes that stop some debug feedback (left in from previous testing of this issue) ; stops the guard from interrupting a "Rallying Party" action; stops the targeting GUI from accidentally starting when there is no combat taking place; and lastly, fixes Wilf and Gavin's conversations to allow a player to ask a question again if it was aborted half way through. (These conversations are MODULE changes, requiring fresh start or added to the patch hak.)
No comments:
Post a Comment