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

The MP save game corruption has been the bane of our gaming over the last week, preventing our group from being able to get anywhere at all. After many restarts and investigations, I finally managed to write a GUI that helped me to have some feedback when a player’s PC had become “corrupted”. In my search for the problem, I managed to discover that the playerlist.ifo file within the MP save game directory was beginning to show two entries for one of the players. It was this double entry that was giving us so many problems even after the initial problems had been clearly resolved.

Within the file, I could see that the WAN player had two player character entries for himself: one with both the first and the last name, and another with just a first name. At this stage, I had no idea what was causing the sudden dropping of the last name. However, after doing some more testing, we discovered that the problem occurred in a fairly standard way when my wife joined as a second player. I then checked the code to determine if there were any scripts firing (by her) that may have had something to do with the last name. Then I found it! I had indeed, only in the last couple of weeks, made one minor tweak to the code with respect to deleting the last name of (what I thought was) creatures other than the PCs. Sadly, I had forgotten all about this, and even on first checking, it obviously bypassed companions. However, there was no check in place to ensure another player PC did not have their last name deleted!

That error was, in fact, in two places; and once the check against deleting a PC’s last name was put in place, the save games from that point onward were no longer corrupted. Evidence that such a small innocuous fix can have devastating consequences. Thankfully, that one now in the past!


I have been working in one or two other issues that have come up while testing:-

  1. DM map fixed. (Was not opening.)
  2. DM Examine fixed. (Was causing terrible issues with memory leaks and overflows.)
  3. Companion recovery after combat (with Companion Protector feat). If a party died and the player re-spawned and went on to defeat the enemy, the companions were not recovering. They do now.
  4. Turn-Based combat button is working better, and has GAME PAUSED fixed after usage.
  5. Trickster Jewellery (some items) had failed to register in the database. A check was removed (which appeared to not do as expected anyway), and the database now fills correctly.
  6. Ensured GetAPlayer home brew function does return a valid object, even if it is a DM.


More code tightening, especially on the “On Enter” scripts with respect to areas. Some routines that duplicated work have been removed, with respect to setting up the database.

Reduced the number of weather units created to help improve performance.

Ensured newly created PCs would no longer be forced to take the default package after the player had taken time to setup as they wanted. (This is the case for 1st level PCs anyway.)

As a result of the above, I have disabled the RECOMMEND button for CLASS SELECTION when clicking on the LEVEL UP button, as it crashes the client if this is done.



Play went relatively smoothly last night, but there have been one or two issues that need addressing. In particular there are two XML files (recently added) that need removing as they are causing Level Up issues and appear to corrupt/stop level progression.

There are also some other minor issues, but one major, where a GUI cannot be closed by another player in a MP game.

All these fixes will be ready for the v2.21 release, which is essential for a stable game, be it MP or SP. (Sorry about all the updates, but it cannot be avoided at the moment. Hopefully, things will calm down in a little while.)

I am just looking at a minor “follow” issue with Main PC and Created PCs, and hope to fix that before the next release.

Full update when I can.


Our group finally managed to get a session played after the week of problems with corrupted saved games. I did manage to introduce a couple of others (while trying to improve the DM code), but after recognizing the issue, we pulled the two XML files causing the leveling problems and managed to play a full 1 hour and 17 minutes. This was slightly shorter than we set out to play, but a GUI issue, followed by a computer problem by the guy on the WAN (Windows wanted to update), brought us to an early night.

So, without more intro, here follows the fixes, updates and adventure!

The List of Fixes

1) CORRUPTING XML FILES: The first problem we encountered was shortly after Graham decided to bring on board a fighter (a dwarf called Flint) to replace Aeriol, the elf wizard companion. The process went according to plan until Graham went to level the PC, to catch up with the current level of PCs. At which point the Level Up button refused to work for the PC, and when he did manage to get a little further, the PC’s skill points were corrupted, preventing the player from taking the PC any further. To keep the game moving, I quickly decided to remove two potentially offending XML files (one that altered the DM Party Bar to show PC hit points and another to disable the Class Recommend button on the Level Up screens). Once removed from all computers and reloaded, the PC leveled fine. However, I can add that on later testing, it appears another roster PC has been corrupted, but thankfully, is an easy fix because we have the original BIC that can be re-imported into the game. Suffice to say, these two XML files were only added last week, and then only for cosmetic alterations, and so I decided to leave them out now.

2) TB COMBAT EQUIPPING: While not a show-stopper of a problem, it was an issue I wanted to fix, as this problem caused the Turn-Based combat system to unpause for longer than expected when using the 0.1 second advancement (using the Show Info GUI box) or when swapping the equipped weapon. Both of these very brief “unpause” options clashed with the point that you are not meant to pause again in a TB round after unpausing. Therefore, I needed to add some variable checks to allow these options during a TB paused moment in the game. They are now added and work well. On a side note, the TB Combat System now works very well in MP , as well as SP since I improved the code a couple of weeks back.

3) CHOICE GUI CLOSING: The bug that led to the session ending was due to a GUI that was presented to all players in the session. It was only “active” to the lead player who caused the GUI to be displayed. After taking action with the GUI, the GUI then closed for the player taking the action, but, unfortunately, I had not yet coded to close for a MP environment (even though I had coded it to open for a MP one). Therefore, the GUI remained in place and could not even be escaped (that was the correct nature of this GUI), and so the game had to be saved and reloaded. Unfortunately, my friend on the WAN who was presented with the GUI issue has been having his own issues with his computer not starting NWN properly sometimes. This happened tonight; and was probably due to the fact that Windows required an update and restart. So, we decided that would be it for the night.

4) MAIN PC FOLLOW ERROR (INTERCEPTED): While testing, I noted that the Main PC would NOT always listen to (hear) commands shouted by the player when possessing a created PC. I had to go back to an older build to help locate the issue. It appeared to be related to some “new” code I had added to help prevent another follow issue. Once I reinstated the older code, it fixed the new problem, but, thankfully, in testing to date, the old problem has not returned! Go figure.

5) OTHER MINOR FIXES: Other fixes included: A return to the DM Map failing to open, which I hope I have addressed this time; DM stats figures showing incorrectly fixed; a return of the double Party Bar after a toggle, which again, I hope to have addressed this time; and incorrect GAME PAUSE message for the DM.

Game Update

There was only one update this week (which could be called a fix I suppose): I changed one variable to ensure that every member of the party present was compared to when giving feedback on the PARTY CRAFT tab on the character sheet. Previously, the crafting scores only checked the values of the PCs that a player controlled, as opposed to those also controlled by another player. As the tab is entitled “PARTY” and already returned the best/highest feat in the party, it was only proper to do the same with party skills as well.

Catch up with the heroes in our session here (at the bottom of the blog):



Hi All,

Just a quick note for now (main post coming later today) :

The Scroll v2.22 will be uploaded later today. It has a few fixes, but my main point I wanted to note now is that I have moved around 10 MB of DLG and NCS/NSS files from the MODULE folder to the CAMPAIGN folder. This should have no negative impact as far as I have tested, but will, hopefully, give some benefit moving forward.

As all of my MODULE fixes have been around dialogue and script fixes, it seems daft to have these small number of module dialogue/scripts penalizing players who do not have access to the module hak (which only I have been doing for my play through for now). EDIT: CAMPAIGN fixes have always been available and are the core fixes.

Therefore, hopefully, anybody who downloads the CAMPAIGN folder from now (v2.22 onward) will have the benefit of these type of module fixes too!

I will upload and post again here after I have prepared everything.

Thanks, Lance.

The last session went relatively well, albeit still requiring some essential fixes along the way. However, the fact that I was able to quickly save the game, load the toolset to apply the fix and then reload a game so we could continue, should demonstrate how minimal these alterations were. Essential, but small.

The important thing to note with the next v2.22 release, however, is not just the fixes, which I will address below in a moment, but that I have now moved some dialogues and scripts that were once in the module folder, into the campaign folder. What this does, is allow me to continue to update the campaign folder alone, without having to add a hak for our session with each module update; as all the module fixes to date (as opposed to campaign fixes), has only required dialogue and script updates. This also speeds things up when it comes to overall fixes, as I do not keep having to check if the dialogue or script being fixed is a module one that required putting into the hak to check if the fix even worked! This should be a win-win for everybody. And now to this session fixes …

The List of Fixes

1) ACCUSATION GUI: At the end of the quest involving a murder, the heroes are given the results of their investigation in a GUI. Unfortunately, however, the GUI (which is offered to all players), had inadvertently been left in a state where even the player who activated the GUI could not close the GUI for themselves (and others). This may sound similar to last session’s bug, but differs in that the button selection was disabled even for the main player and so they did not even reach the point of closing it even for themselves. (This, in turn, would have closed it for the remaining players, which was the bug fixed last time).

2) RIPPED PUZZLE FEEDBACK: If a PC has the Expert Decoder feat, they are supposed to receive feedback in a ripped puzzle as to how many pieces were in the correct position after moving them around. Unfortunately, while the Notice Text was working, it was hidden behind the main puzzle GUI. (We missed that point while playing.) And the Chat Box feedback had only worked for the host, so I had to give feedback as they worked the puzzle. The feedback has now been fixed to display to all players.

3) GOLD MONEY BAG TRANSFER: I have a new GUI that allows players to much more easily be able to transfer items between the party members. A simple right click on an item, choose “Give To” option and a GUI presents a list of PCs to whom the item can be transferred, with weight allowances remaining. Items with inventories and money bags are transferred slightly differently to other items and I noticed that when one player transferred a single bag to another PC, that their remaining gold bag also disappeared. (It was destroyed.) This problem was caused if a player has a Target highlighted (in the box at the top of the screen), and then applies the transfer. In this case, a valid object was perceived because of the above targeting and caused the code to go awry. If the player did not have a target highlighted, all went well. To fix this, I ensured the object (even if targeted) was later set as an INVALID OBJECT when referring to items with inventories or gold money bags. (I refunded Myara the 500 gp that went missing this way.)

4) SCRAP SCRAPPING PCS: This was a faction problem. When the player temporarily dismissed Scraps from the party, Scraps turned and attacked the PC. (Abandonment problems I guess.) A quick edit of the script relating to the henchman removal ensured Scraps (and other henchmen) would not turn aggressive in future. How or why this had happened is not clear, as I had not had this experience in my own testing … ever.

5) PLATFORM SPEECH: A very minor issue relating to player click timing. Basically, when a player clicked on the platform to give their accusation speech, they could click again before the script had finished firing and stop the action. As their is a two second delay between click and conversation, a player may think nothing is happening and try clicking again … and so on. Now, I have made it so once clicked the first time, the player loses control of further commands until the speech is underway. As a point of interest, it was while fixing these scripts that I decided to move all the module dialogues and scripts to the campaign folder. It made it much easier to test, especially after I realised that all my alterations were for nothing because I was working with module scripts that required being placed into the hak before being able to test properly.

6) CONVERSATION TRANSITIONS: Apart from Scraps giving us aggro when leaving the party, this was probably the worst issue on the night. Whenever the heroes tried to transition via a conversation, they failed due to a check that stopped transition if anybody was in a conversation. Well, this transition was from a conversation , so that went nowhere fast! However, that was not the only issue with this path of area transition: I also discovered that the current PC rather than the Main PC was being jumped, which gave all sorts of delays and transition issues. This issue has now been fixed in both areas, and testing shows all works fine now.

Catch up with the heroes in our session here (at the bottom of the blog):


FUTURE POST UPDATES WILL BE HERE: The Scroll - v2.22 NOW AVAILABLE! (Continued Posts On MP Fixes)