Hi All,

EDIT: Scroll down the POSTS to get to the latest updates.

I have just done a couple of updates/fixes to The Scroll, which can be downloaded here:

I wanted to point out the following:-

  1. The HAK PATCH system is now being reserved for player specific or module fixes only. Now, the preferred method of “patching” is to simply download and replace the latest ALTHEA CAMPAIGN folder, which contains most fixes by default anyway.

  2. The latest version includes a fix that dealt with a heartbeat stutter that caused the game to very briefly pause every six seconds. This has now been fixed.

  3. I also made it so the Notice Board scrolls now highlight to point out they can be clicked.Also changed the colour of some journal text for easier reading. Also removed some scripts only used in building.

This latest version continues to make preparations for any potential follow up modules.

Once again, if anybody does try playing and has any feedback or finds any faults that need addressing, then please let me know.

Thanks, Lance.


Hi All,

Full multi-player testing is finally underway (delayed from June this year), as my wife and a friend form a small party of PCs to play “The Scroll”. The testing involves using the DM Client (acting as the HOST), and two connected players, one LAN, the other WAN. This play through allows me (as the DM), to monitor actions taken by the players and take notes for any fixes required.

The testing has already revealed that there are need of some fixes when playing “The Scroll” multi-player, especially when using the DM Client. As I have said before, v2.09 is (as far as I am aware), a solid single-player experience now. However, it is possible that some of these later fixes will have some benefit to a single-player experience too. E.g. Typo corrections.

Below is a list of fixes that have already been addressed and will be available in the next game files updates. (I will keep readers updated when latest file revisions become available.): -

NB: Remember that these fixes mainly affect multi-player gaming experience: -

  1. TYPO correction in “Real Life” Rule Info section - “Equivalent”.
  2. Calendar Rule Info now updates at the correct game trigger when selecting Option 1 Background.
  3. Multi-player CHAT window toggle (via Rod tool option) now keeps correct toggle between areas/loads.
  4. In the event of a player leaving a game, any plot Items are now temporarily stored on the HOST rather than a potential leader of party. This is in case it was the leader who dropped out from the game that a DM was hosting. (i.e. The leader is not necessarily the HOST in a MP game, which had been the previous assumption. Especially when there is a DM at the helm.)
  5. Area Entry code had some other fixes, especially relating to the DM Client as HOST, including: ensuring the SAVE GAME request stopped repeating between sessions; preventing combat GUI from falsely starting on first entry of DM.
  6. Campaign Welcome “sound” message fixed for SP game.

I am also currently looking into changing the default colour of the “greyed” text that a player (not directly involved in the conversation) sees when another player is in a conversation. It is “greyed” because the indirectly involved player is not able to make any selections. However, I think it would be better for these players to be able to read the options in a COOP game more easily than the grey version, to help discuss with player making the selection. I need to find a colour that will still represent their inability to directly participate, but be clearer to read that the grey currently does - and assuming I can “fix” this.

Do let me know if you have spotted any other issues that need addressing in “The Scroll”, be it in a SP or a MP game, and whether it be hosted by a DM or another player. And let me know if you need these fixes quicker than I might release them. Otherwise, I may simply keep the next file version update until I have dealt with more issues.

For a more in-depth coverage of the gameplay on the night, please go to:

Thanks all!


Hi All,

Another session was played tonight and, frustratingly, there are some more issues that need sorting … In particular, the new inventory/store system fails miserably in multi-player. :frowning: I believe it is simply a case of too much code trying to be executed across the server, thereby not updating the player’s GUI at all. It even caused the WAN player to be dropped to desktop. I am going to test a few things, but suspect that the only workaround will be to bypass the new system (that works fine in SP) and make do with the original OC XML scripts when playing MP … or at least extremely paired back versions of my own system.

I will give more feedback after some tests and looked more into it.

Thanks, Lance.


Hi All,

Well, there is some potentially good news regarding the inventory/store system in that I believe the problem stemmed from some older/poor coding, which I have hopefully now addressed. Here is a summary of the issues covered this time around. (NB: Some of these latest fixes will definitely improve SP experience too. Furthermore, there is a logical flow problem for OPTION 1 background that will also be benefited from when addressed.)

NB: These fixes are NOT yet available. They will be available in the next update or if requested.

1) PLOT ITEMS: Prior to starting the game, I took the decision to abandon/remove some code that supported maintaining plot item between sessions in the situations where a player may be absent. The code still is in place to safeguard plot items accidentally lost or left on fallen companions, but trying to support automatic drop-in/drop-out of players has been abandoned. Simply put, the game now assumes that the same group of players will be present from week to week, and any potential absences should be managed in the following way:-

A) Player who may be absent should ensure they leave plot items with another player or companion.
B) Player should then EXPORT their main PC to save any other current equipment they may have.

This allows the game play to continue in their absence (if need be), and allow them to return to the game with their exported character at a later date without disrupting the integrity of the session. The only caveat here is that the HOST must always be present for every session.

2) CONVERSATIONS: During play there were one or two conversations that behaved slightly differently, and it turned out to be due to some accidentally missing MP or PARTY CHAT ticks. This caused some conversations to be not shared, when I had hoped they would be, and even one to be “skipped”. I checked through the conversations again, and believe I have fixed them now. On a positive note, the change in the “grey” to a “dusty pink” worked well in non-participating conversations.

3) STORES: The biggest problem this time, which was critical (and game-breaking), was that the players could not retrieve the descriptions of store items. I have a new GUI system that incorporates the ability to compare items in a store with those already owned. This worked fine in a SP game, but some poor/old coding was causing an overload in GUI calls from four problematic XML scripts . In particular, these XML scripts were making rapid update calls that constantly fired the examine GUI and associated scripts, when they did not need to. Today, I managed to unravel the poor code and remove it from each of them. In testing (I was only able to test one computer on LAN), the problematic stores now appear to be fixed. Furthermore, I was able to address a couple of other related minor issues in the process. Further testing with a WAN will confirm or deny.

4) LOGICAL FLOW: There was also a problem with story logic in OPTION 1 background, which will NOT apply to many users, as OPTION 2 is the recommended background choice for those not familiar with my PnP background. However, for my own peace of mind I wish to fix this, and is the next thing to do on my list of problems to solve.

For a more in-depth coverage of the gameplay on the night, please go to:

UPDATE: As there were significant performance improvements and a logical flow fix (for option 1 background), I decided to upload the latest version to date with all fixes mentioned to date. You can get it from the normal place, here: (Version 2.11)


Hi All,

OK, there are still some other minor issues with v2.11 that I need to make people aware. The shops do appear to work OK now, but there are some glitches that can leave a player stranded and unable to control the PCs if the time causes the shops to shut while the player is still looking at stuff.

Also, there appears to be a glaring new error that prevents the RULE TAB from working in the Althea Main Menu.

I am working on fixing these issues and will be uploading the files (v2.12) in the next day or so.

I will keep you updated as normal.

Sorry for any inconvenience.

Hi All,

Well v2.12 of The Scroll is now available to download from here:

NB: All fixes I have mentioned to date and those in this post are available to download NOW.

The fixes I have made in this update address a couple of minor ones that were introduced with v2.11 and some quest logic corrections and updates that will be appreciated in both SP and MP games.

1) STORES: Importantly, the latest versions (v2.11 and v2.12) have made vast improvements in performance and fixes around the use of stores. Previously, v2.11 had removed massive memory leaks, and the latest v2.12 fixes the “direct switch” action where a player may click between vendors without going through a conversation. These fixes alone would warrant an update to this latest version whether playing SP or MP.

2) COMPANIONS IN MP: On the back of deprecating the PLOT ITEM code, I managed to fix the companion of another player being unavailable if a second player joined a server before the player who owned the companions. (The server could crash if the second player tried speaking with the companions that did not belong to them.)

3) MISSING RULE TAB: This had just been a silly mistake in the last update (v2.11), and was quickly repaired. Thankfully, nobody had downloaded v2.11 at this time and so will not be seen.

4) QUEST LOGIC: I noticed one quest (in a a rare circumstance related to stores) would return an erroneous journal entry. This has been removed. Another minor quest has had a conversation updated to allow immediate response rather than have to restart the conversation with an NPC if an item had already been found.

5) DM STUFF: I fixed a missing calendar GUI for the DM, because he did not receive it correctly at the time. Removed the risk of DM accidentally overwriting the STORED TEST of players.

6) DEBUG & OTHER: Fixed a TYPO. Reworked the CHAT toggle option for MP again, as one player was still suffering from having to repeatedly hut the window when entering a new area. Hopefully squashed now. (UPDATE: Had to do some more before this was finally squashed. Will be available in next update.) Removed some DEBUG lines related to the STORE testing.

That’s the gist of fixes with the latest update. I will continue to update as we continue MP testing. In the meanwhile, you can catch up on our latest escapades here:-

1 Like

Hi All,

30/11/18: The memory leak is resolved in v2.14, which will be uploaded later today. NB: DO NOT USE v 2.12 as it will eventually fail due to its memory leak.

29/11/18: I have discovered a MEMORY LEAK that was introduced with the latest version available. I recommend NOT using the current latest version and will upload the fixed version when done. The FIXED version will be v2.14 or above.


I believe the problem was due to a module folder change half way through a game by one of the players. i.e. They patched the campaign folder (good) and the module folder (bad). I leave the post below for the record, but I don’t think there is an issue after all. Phew!


"Just a quick update, which will have a fuller update tomorrow. (This is the third time I have updated this post, so I apologise.)

It appears that a possible quest path -breaking bug was found tonight for both SP and MP. However, I have been unable to duplicate it in testing, and it may have been due to another MP issue.

PROBLEM: The problem appears that the journal may fail to update after speaking with Frank about his ant problem. If after speaking with him your journal does not update mentioning poison, etc, then you have the problem. If it does update, then you don’t.

WORKAROUND (OR IF YOU DO EXPERIENCE THE ISSUE): Do NOT pick up the quest from the village NOTICE BOARD, but get the quest direct from talking to Frank himself. If you have already done this, then you will need to acquire the poison from Merkes, as Kathy will no longer supply it."

More later,

An interesting series of issues arose the last time we played, which although minor in themselves (as they did not stop play), did help highlight an issue that would have eventually caused the server to crash due to a memory leak!

Funny enough, this last set of fixes escalated from initial minor ones, to those that ended up taking me a little while longer than expected to finally resolve. Recall last week,when I mentioned the “COMPANIONS IN MP”? Well it was from that “simple fix” that I managed to introduce a memory leak. More detail on that in a minute. For those that want to keep up with the heroes adventures, that’s further below. I also placed this warning on the download page to stress the importance of the latest fix:-

v2.12 WARNING: If you are one of the few people to download v2.12, then please accept my apology, as that version had a memory leak, which will eventually make the module unplayable. From v2.13, the memory leak has been fixed. However, even patching will leave you with damage in the form of numerous invisible unwanted objects scattered over areas.


The List of Fixes

1) MEMORY LEAK (DISCOVERED): Let’s get this one out of the way. Basically, to help resolve an earlier companion issue, I caused a function to be called from their heartbeat (every six seconds) to do a simple check. Unfortunately, when this check was called, it caused the companion to dump all their equipment into an “invisible container” every six seconds! By the end of 43 minutes in one area, there had been 423 containers dropped, and after 54 minutes in another area, 543 containers had been dropped (all with items). This would have kept on happening until the server eventually “died” under the strain. The latest update now prevents this from happening, but does NOT resolve damage already done. I have written specific “fix” code for our own situation (which a person can check out in “alb_althea_patchscript”), but I have commented this code out for the latest update, which would not need it. I only actually discovered this issue because I was having a problem with some items NOT being cleared from an area after being exited. Investigating that issue brought to light the mass of invisible items all over the two areas in question.

2) RESILIENT ITEMS (INTERCEPTED): This problem was not experienced during the session, but while testing some code to fix a TRANSITION problem, I noticed some items remaining in an area when they should have been removed. It turned out that the general Area Clean Up code was clashing with some dedicated clean up code for these particular offending items. Once I established this, I re-timed the checks and the offending items were destroyed as expected. And once that timing issue had been resolved, it sorted the transition problem …

3) TRANSITION FAIL (INTERCEPTED): While returning to a place to test a conversation for the next session, I discovered that the transition that had worked fine before, stopped working. It would fade me to black and then fail to do the transition. This turned out to be caused by the problem above (see item 2), but this also highlighted another problem: What to do for a player left in “BLACK” after some other potential failed fade operation. To this end, I added a quick FadeFromBlack (which allows the player to see again) if they hit escape. This would be useful, as it allows the player to continue with the game at least. In this example, it would have even allowed them to do the transition again, which worked the second time around.

4) SOUND FILE FAILED (INTERCEPTED): Again, while working to resolve issue 5 (below), I discovered that a certain sound file was failing to fire as expected. I won’t go into (spoiler) details, but I ended up having to move the sound file to play from a conversation rather than the script that called for the conversation. I believe it was just a matter of timing again. Although, there was also the issue of GetFirstPC not correctly calling a player (but the DM instead), which added to the problem.

5) GetFirstPC CALLS: The issue with using GetFirstPC was highlighted in my testing this time around. I never experienced issues with it before, as I have never tested the campaign with a DM as host before. However, I believe it can be a problem because I think the function can sometimes return the DM rather than a PC player. This can be a problem when trying to then run faction member loops after using the GetFirstPC to “get” a PC. In the end I wrote a personal function to check if the first GetFirstPC was a DM, and grab the next PC if it was. It is a simple wrapper function that I call GetAPlayer . I ended up changing a number of both MODULE and CAMPAIGN scripts to use this wrapper function to be on the safe side of what was being used. The altered module files were added to the hak for our future sessions. (The latest version does not need the hak.) The NWN Lexicon says this about the function: "If you are building for multiplayer, be aware of uses of this function. You could be performing tasks on a player that was not your intended target." I think I experienced this and is why I now use my wrapper function when definitely requiring a player PC.

6) FRANK/KATHY CONVERSATIONS: Now this was the original problem (prior to all those above) that I had been aiming to “fix”. The problem with this conversation came to light when the players noticed the journal had said it updated, but when checked, had not changed. The problem was confirmed as an issue when the players duly visited the apothecary as instructed, but were unable to ask Kathy for help. (The failed journal update did not unlock the chat option.) It turned out to be due to the way GetFirstPC and the QUEST node in a conversation work, especially with respect to lower quest states overwriting higher ones in a MP game hosted by a DM. I believe I have this issue sorted now, by keeping track of the player speaker when doing the journal update. (NB: This problem required fixes to MODULE scripts and dialogues, which meant I have had to introduce a patch hak for our sessions. Furthermore, I have also had to fix journal entry via the “alb_althea_patchscript”, which is commented out in the latest public release.) There was also a second problem with Frank’s conversation related to logic flow; this was also fixed. (Although there may be a minor issue with PCs already knowing Scraps name, which I may try to address later.)

7) CHAT WINDOW (AGAIN): This version of the earlier issue was “accidentally” discovered when one of the player’s (Graham on WAN) chose to UPDATE MAP PINS by mistake. The option is quite legitimate, but had not been required at this time. However, it’s process of leaving and returning to the same area demonstrated that some code was still needed for the exit/return exercise. E.g. The CHAT WINDOW needed closing again according to the player’s setting. The missing application of some code was also the reason why the player had to now click twice to open their inventory - a variable had not been set.

As usual, there is more to read at the blog in the synopsis where you can catch up on how the heroes did in the last session …


Since the last session, I have been concentrating on streamlining the code to improve performance … again. It has come to light that what works well in a SP game does not always translate to a MP game. In particular, if a player has a GUI open that is making “Update” calls, that GUI instance may work well for one player having it open, but as soon a you have more players accessing the same GUI at the same time, the number of update calls from any such GUI requires paring back or else we end up with a Too Many Instructions (TMI) problem, railroading the server to a quick termination. We experienced this in two cases last time we played, one with the (altered) Character Sheet GUI, and the worst case with the home brew Targeting GUI, which was the last thing we tested before ending the session. Although, the TMIs with that GUI would have insisted such anyway. More on this below. On the back of this experience, I am going to look at the remaining XML scripts and try to alter/fix any remaining scripts that may cause a similar MP issue with TMIs.

Other than that, the session went reasonably smoothly for the 1 hour 37 minutes of unpaused play that we had. (We also started slightly later.) You can catch up on the heroes actions further below. Also note, there are a couple of GAME UPDATES of which to be aware.

The List of Fixes

1) CHARACTER SHEET (TMI): This was our first experience of a GUI opened by more than one player at a time causing an issue. A quick check of the characterscreen.xml showed the alteration I had made for displaying temporary hit points was the likely cause of the issue. It worked using an OnUpdate call without any restriction to that update, meaning it was making the same server call dozens, if not hundreds of time per second. Furthermore, the script it called, gui_fixtemp , had no limit set to the number of times the call would update the GUI, which meant the GUI was calling and updating many times for each player that had it open. The XML now has a limit set to a call only every 0.5 seconds. Furthermore, that call does nothing now, unless there is a need to update the GUI. This problem had escaped our attention until now, because each player was unlikely to have the same GUI open at the same time. However, the players had just leveled and so both players were now trying to look at their Character Sheets at the same time. To workaround the problem on the night, we simply did one player at a time.

2) DOOR LOCKED PCS INSIDE: This problem arose due to a door heartbeat check no longer allowing a DM presence to keep a door unlocked. However, the code was wrong in another way too, so it has now been fixed to ensure interior doors do not lock (if not locked) anyway. Workaround: As a DM was present, the DM simply unlocked the door to allow the players to exit.

3) TACTICAL GUI FEEDBACK (TMI): As the session drew to a close, I asked my players to consider performing one last action that we knew would involve combat, so that I could test that the new TARGETING GUI would work in a MP session as well as it did in SP. (I had not yet been able to test this in a MP environment.) I am glad we tried it, as the test showed there was a problem: the game stuttered and ground to a halt. At least now I could examine the issue and have it fixed before the next session. It turned out the problem was similar to the Character Sheet problem (item 1 above), but much worse. In this case, it was due to the altered noticewindow.xml that was being automatically called at the same time for all players (3 in our case) and had an OnUpdate set at maximum (no limit) to call a reasonably large script (involving multiple loops) dozens of times per second for every player. It was no wonder that the server ground to a halt and crashed. As I stated above, this kind of multiple call may work for a SP game, but it is just too much in a MP game. This is what I did to fix the problem: Firstly, as the main script call ( gui_updatetargets ) involved loops for all PCs anyway, there was little point calling the same script for every player (to do exactly the same thing each time), and so I restricted the called script to work from the host player only. Secondly, I limited the OnUpdate call to 0.1 seconds (meaning to call only every 0.1 seconds). The combination of these two fixes alone limited the instructions for the TARGETING GUI feedback by hundreds of times . Furthermore, I put in place some other checks that helped alleviate script execution when it was called anyway. The result: A smooth operation. (I have yet to test the system with the player on WAN, but testing locally has shown good results.)

4) MISSING HOLY BOOK: When Graham rested his PCs at the Bloated Buckle, one of his PCs (Elana the cleric) failed to learn any prayers, even though they had paid for expensive accommodation. It turned out that the cleric had “lost” her holy book. It was no longer in her inventory. My suspicion at this stage is that this was related to the COMPANION and their equipment bug on a player leaving the game. (See last blog post.) This was fixed with the last update, but Elana’s missing holy book may have been collateral damage with respect to that bug and the fix at the time. Now that the companion equipment bug has been fixed (and Elana was given a new book by the DM), that problem should (hopefully) be gone. On reloading with the DM only (as a test), the cleric appeared to still have her book then. Next session we will know for sure.

5) COMPANION FOLLOW (INTERCEPTED): During some testing, I discovered there was a problem with companions following the correct player if both players controlled more than one PC. This had not been noticed prior to my own testing, as my wife (up to now) had only ever been playing a single main PC, and only Graham controlled more than one companion. The problem was due to variables NOT accommodating a MP environment. I have addressed these now and will try to locate situations where variables should also be updated to accommodate a MP environment. (My own MP testing is limited to a MP environment without a DM as host, which means I do sometimes miss MP issues depending on how I am testing at the time.)

6) OTHER MINOR STUFF: A TYPO was fixed in the Death and Raising rule. The DM calendar did not update immediately from party resting, but did on the hour. A fix has been applied but not yet tested.

Game Updates

1) AUTO-PAUSE REWORDING: The Main Menu currently has “AUTO PAUSE IF ATTACKED”. This will be changed to “AUTO PAUSE IF ENEMY SENSED”. This is because it more accurately describes the situation of the game pausing on enemy contact rather than any actual attack. i.e. The game can and often does pause before the player is actually aware of what the PCs have perceived. In such situations, the player may need to allow the game to be unpaused until the beginning of another round before they can target or take any action. (See next update.)

2) NO PAUSE COMBAT ROUND: If a player uses the campaign’s Tactical Turn-Based Combat System , the game will now NOT allow additional pausing between combat rounds. i.e. Once the player has released the paused action, the game will not be able to be paused again until the six second round has completed, at which time the game will automatically pause itself. NB: This only applies when a player is using the Turn-Based system, which is automatically entered if they use the “AUTO-PAUSED IF ENEMY SENSED” option. (See above.)

As usual, there is more to read at the blog in the synopsis where you can catch up on how the heroes did in the last session …

I will also endeavour to try to upload the latest version (v2.15) as soon as I have gone over the code one more time looking for other potential GetAPlayer issues (MP variables) and OnUpdate instances (in XML code) that may potentially cause other TMI problems. Once I have uploaded it, I will update this post with the link. Here is the latest v2.15: (Very much worth the download as many improvements to the code have been made to improve performance, especially with MP game.) NB: I just had to upload v2.15 again, as the ripped scroll puzzle had broken. This is now fixed in the new version of 2.15b now uploaded. (Apologies to the one person who may have downloaded the v2.15 faulty version.)

1 Like

Hi All,

Just a little heads up for further improvements in v2.16. Again, I have been concentrating on improving performance, and to this end I have looked at reducing the number of “Weather Units” that are created in my weather system.

These units are created in outdoor areas to support the weather system that The Scroll uses. However, I have found that some computers may not cope with handling the 256 units that can be currently created when each unit has a VFX attached. To this end, I have limited the maximum number of weather units to 64 in any area. So, smaller areas may have more per tile (maximum of 1) compared to larger areas (eg. 32 x 32) will now only receive a unit every 4 tiles.

In testing, the weather system still looks good to me, and I hope this continued streamlining of effects and code will help overall improvements for both SP and MP sessions.

I will probably have v2.16 available to download some time towards the end of this week, after my own players have done some more play testing. Be assured though, the much improved performance weather system will be part of that update.

Thanks, Lance.

1 Like

Hi All,

I decided to release v2.16 now because it also fixes a second incidence of broken “Ripped Scroll” code, which is ESSENTIAL for a SP game. Without this fix, there will come a point when the puzzle (which is needed to be resolved to continue) will not work. If you have already started, you can simply replace your CAMPAIGN folder with the latest v2.16 and this will resolve the issue before you encounter it.

However, v2.16 is a good place to START the campaign from afresh, as it also contains all the latest performance issue fixes, including the weather stations that have VFX attached. It now maximizes the number of units to 64 in an outdoor area, which is 25% of previous builds. NB: These weather units build at first entry to an area and so to gain the benefits of this performance boost, you would need to start from fresh. (Although, the patch script does have some commented code to manually fix an existing game.)

Please, do give feedback if you are playing and seeing any issues that you believe may need addressing.

v2.16 HERE:


Hi All,

Well, I need to add another apology. From our own play testing, there was another problem with talking with STORE OWNERS to open the store when their conversation is exhausted. I thought the bug was squashed a few fixes back, but it was back on our last session, which did not last very long at all. More on that in a moment. So, the latest version 2.17 fixes the store issue, and also addresses some other issues that we experienced in our last play.

Basically, Graham (on WAN) wanted to bring in another PC to replace Aeriol, because he felt that another fighter would balance the party rather than with two wizards as it currently stood. After a quick mid game fix to repair skill/feat selections Graham had made for the fighter (which is also in the latest v2.17 campaign folder fix), we continued to play. However, we only got as far as leaving the Bloated Buckle Inn and talking to a store owner when we encountered the store problem, mentioned above. No problem we thought, as we could reload the game and continue without taking the conversation path until it was fixed. However, when we went to reload, Graham (on WAN) had no end of difficulties trying to rejoin the game with the latest save.

The previous save appeared to work still, but (just to be on the safe side) we decided to make sure we could save/reload again having just restarted the session. Then, even that basic step of save and reload gave the same issues as he had experienced previously. We then spent the remaining time we had trying to establish why this had happened without any successful reload for him. In the end, it looked like even Jennifer (on LAN) could not join the session either, experiencing the same error messages.

In the end we ran out of time and I had a new issue to resolve. After checking the code, I thought there were some potential issues that needed addressing (which I did) and by the time I came to test it (the following day), the problem appeared resolved. Then, just out of interest, I went back to the previous version and tried to reload the LAN character again … and it worked!

So, although I made a number of alterations that I believed may have contributed to the issue, in the end, it may have simply been some form of corrupt server data that was cleared after a computer reboot. (I know I should have tried that first, but it’s great with hindsight.) However, those additional alterations I have made did clear up some inefficient code, and (hopefully) ensured a better establishment of variables upon a reload - so that it may help towards ensuring the loaded game did not confuse some variables, including such things as who was the host. NB: The older code still looked good to me, but I am happier with the alterations I have made to help alleviate similar problems (that may have contributed) anyway.

So, no gaming news to report other than these experiences. Hopefully, we will have a decent session tonight. I will report back as usual.


Thanks, Lance


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.)


1 Like

Unfortunately, testing v2.18 still fails on GAME RELOAD, so there is a major issue somewhere in the version . We managed to test via WAN tonight and found that the stable version for relaoding games was v2.12, which has a number of issues itself.

I am going to have to rebuild the latest version working from this v2.12 and release it when done.

Sorry for the issue guys … I wil post again as soon as possible, but it will not be until Monday the earliest that v2.20 (I will start from that version) will become available.

Until then, have a good weekend all.

Hi All,

Well, after some more quick testing, I have been unable to see exactly if there is any specific error in my code. The only thing I have been able to find is that the playerlist.ifo (which appears to carry the list of players and their saved PC) shows a double entry for my player on WAN. One entry for one named PC and another with a PC with only the first name and not any second. This would imply (or looks like) that during testing the player either reloaded with a PC of a different name to the one expected … or the game engine is loading the PC, but then loading it again (and truncating the PC name in the second addition) and causing the fail.

I have yet to test my theory by chatting with the player to see if they have or have not been accidentally reloading a different named PC (e.g. Two PCs in the local vault, one named Fred and another Fred Flintstone, and if they are accidentally selecting the wrong one between reloads.) This is unlikely though, as I have stressed the importance of keeping to the one named PC. How the game is reloading the player twice though, escapes me. Although, this would seem to be the only alternative possibility.

Does anybody know if there is a playerlist.ifo “reader” that’s better than scanning through with notepad?

Has anybody else experienced a double load of a player when reloading a game?

I will continue looking at the code to see if there is anything else that stands out from my side.

Thanks, Lance.

i don’t believe there’s a reader/editor for .Ifo

you might be able to fool the engine by starting another playthrough, making a save, and copying that .Ifo over to the real playthrough.

(but again, I don’t know how MP works, what happens if player joins with a different character (or even if that’s possible…), and wouldn’t assume that the entries for “Fred” and “Fred Flintstone” are wonky – “Fred” could be a general label for the list while “Fred Flintstone” is a character, eg.)

Hi KevL,

Thankfully, I had a saved game with the “correct” number/details for the player in question, and I was able to fool my wife’s computer to think it was the WAN player and to be able to test a bic file of his character (he sent me). This allowed me to test various scenarios to see how the playerlist.ifo may have come about. The more I test, the more I think the other player simply loaded the wrong PC when testing, which threw my results and made me think the worst.

For when I check the “test” saves that gave us problems, that is where I see two different PCs for the player in question. I was able to duplicate this by creating a PC (without the second name) and loading that PC instead of the one for the previous game. Subsequent saves with this PC created the second entry for the player in question with the missing last name section. And when trying to load the old one/correct again, causes the issues we were witnessing. i.e. Which looked like the PC was a new entry (or duplicated) with a missing variable.

Version 2.20, which I hope to upload shortly, now adds a further variable test to ensure the player is loading the PC expected for the saved game in question - and causes them to have to leave if incorrect, showing them the correct name format that the PC is expected to be in compared to the one they just tried to load.

So, the bottom line is, I believe the last version 2.18 probably had resolved the issue. However, coincidental bad PC selection in testing caused the problem to appear unresolved. That said, I have made improvements to v2.20 that helps to avoid a potential INVALID OBJECT when looking for a PC, which may also help to avoid such errors.

I am hoping my friend on WAN will come back to me some time today. At the very latest, I should be speaking/testing with him next Wednesday. I want to hear him read out to me the PCs he has in his local vault to see if I hear him mention the “offending” version. If that does not exist, then I am stuck with trying to find out how and where a “second” version of this rogue PC has come from (with its first name only).

Maybe this is a problem that Persistent World builders have faced? Unfortunately, I don’t believe I know any of those people. If a PW is reading this, then maybe they could shed some light on the issue.

Bottom line … I await to test the latest code, but will upload v2.20 anyway after just a little last minute testing.

Thanks KevL, Lance.


hope springs eternal, so do bugs

You may note I was very careful not to say it is completely resolved. :blush: :wink:


1 Like

Great news - The corrupted save game bug has been resolved!

It turned out to be related to another “minor” innocuous fix to do with examining/spotting NPCs. There is a call that can blank the last name (required for another reason), and I had not carefully enough ensured it would not blank a PC name! Hence, whenever, a second player used the SHOW INFO GUI (which she often did), or a monster perceive was fired (which also often happened), the player’s Main PC last name would be blanked, meaning any saves after that would be broken.

I had written another check GUI to highlight when the problem occurred, and once my friend was able to play test across the WAN, I was able to narrow down the bug and fix it once and for all! It did need him to be online, as the bug only tended to manifest itself when at least two players were present (as well as the DM), so I am glad we had the time to do this tonight.

I will give a fuller report later. I am also doing some other fixes related to DM controls: map/examine/etc and once they are completed, I will upload the latest v2.20 that comes with the SAVE GAME fix and others.

Furthermore, the Adventure Continues … next Wednesday, and so the blog will have another update then.

Thanks, Lance.

1 Like