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)