EDIT: I had to start a new post because I could no longer edit the TITLE of the last set of posts. I will keep making this the main post from now until I hit the same “Titling” problem again.

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


1 Like

Apart from a few relatively minor issues (akin to those we encountered before), the latest session played well, and we managed to play a good 1 hour 29 minutes (after starting later). Here is the latest report …

The List of Fixes

1) CONVERSATION TRANSITIONS: We were troubled by a different version of the conversation transition we experienced last time we played. Again, it was a simple quick trip to the toolset to apply the fix and reload in under five minutes. Later, I went through the module searching for any other conversations that may suffer from the same problem and found two others. These have also been fixed now.

2) COMPANION DISAPPEAR ON LOADING: A strange one this one, in that it had not manifested itself before tonight, even though circumstances appeared unchanged. Basically, the companions would disappear the moment a player entered the game. A quick search revealed the “area clean-up” code “tidied away” the companions too. The link was that it happened in a new area, and that somehow, the companions faction had changed, probably not unlike Scraps did in the last report. So, the fix was similar: I had to ensure the companions were allocated a faction (when left behind on session exit), that would allow them to be preserved when the player entered again. Sorted!

3) GRIST NAME: This required a MODULE fix, which means the fix will NOT show on just the campaign being patched. Only games starting with Module v2.23 will be fixed. (However, it is a minor fault and does not affect gameplay.) I had obviously forgotten to remove the default string for GRIST in the area designed in the module, which meant Grist’s name was showing as the default (“Axle”).

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


1 Like

Just a quick notification to say that v2.24 CAMPAIGN PATCH is now available, which deals with changes in a feedback function that broke one or two functions. E.g. The Accommodation GUI did not count the correct number of PCs and failed to rest them properly.

The problem came about after a change in a feedback function. I have now checked the rest of the module for where this may have affected scripts and updated/fixed.

Download v2.24 here:

Thanks, Lance.

We pretty much had an error free session last night. Everything went relatively smoothly, with only a few extremely minor issues, all very easily updated in the latest v2.25 fix. And although we only had a play time recorded of 1 hour 7 minutes, this was mainly due to one player having to be called away for half an hour (combat was in TB pause mode anyway) and we did a fair share of paused TB combat, which does not record time.

As for the latest version, the important thing to note this time around is that there was an update to the TLK file. (Cure Minor Wounds heals 1-4 and not 4, which it currently states. This is the only change, but something I still wanted to fix for the latest file downloads.)

Strictly speaking, there was only one fix that needed addressing, which is explained below, and the rest of the alterations are to do with tweaking/balancing, or updates to do with the TB Combat system, all explained below.

The List of Fixes

1) JOURNAL TB PAUSE: This only affects players using the auto-pause TB Combat System. If, while paused, the player views their journal and looks at a creature entry from the bestiary, the game requires a very brief (0.1 sec) unpause to allow the GUI to update. If the game is paused, the system needed to be updated to ensure the game paused after this update, or else the round would play for the six seconds before pausing again.

2) CURE MINOR WOUNDS TLK ENTRY: The description Cure Minor Wounds spell was incorrect. I have made the cantrip now cure between 1-4 HPs and not 4, as the description said. The latest TLK file addresses the description entry.

3) OTHER (MINOR): A TYPO in the TIME WARP rule description. Target GUI auto open for the DM too.

The List of Updates

1) VIGOUR DRAIN: I have updated the speed of vigour drain according to some types of activity. Previously, the vigour drained at a steady rate, but after some player feedback, I decided to slow down/prevent decay if some sedentary activities are being carried out, like being in a conversation or playing a puzzle, etc. This is so a player’s ability to read or take time in some aspects of gaming does not penalise their PCs ability to continue adventuring in a day. (See additional note on TIME below.)

2) GUARD SEARCH: Again, after some player feedback, I decided to alter the algorithm related to the guards that may try to search PCs for stolen goods. The search now depends upon if stolen goods have been reported, and a reduced random chance search roll.

3) CREATURE CR FEEDBACK: When encountering a creature, the PCs are given an indication of how tough an adversary may be (a Challenge Rating or CR) according to the heroes own levels. I have altered the algorithm, as the encounters were giving a CR feedback slightly too high for the creature encountered. i.e. A creature may have been labelled “HARD” instead of “NORMAL”. The algorithm governing this may have other slight tweaks if needed, but as it is only a guide, further alterations may not be required.

4) TB PAUSE FUNCTIONS: For those that use the Althéa auto-pause TB Combat System, there has now been an additional 0.5 second “move forward” option added to the SHOW GUI (small square in the top left corner). To activate the 0.5 second forward time, the player now RIGHT-CLICKS in the box. Doing so will move combat forward by 0.5 seconds with each additional right-click. This allows the player to determine if their PCs are doing what they want to in a round, or take additional reactionary steps within the round in question. E.g. The 0.5 second is used and the player notices a creature move somewhere they had not expected, the player may then change the current action of their PC or PCs to accommodate it. This is in addition to the 0.1 second “move forward” that the player can use by simply entering the small GUI at the top left of the page. NB: In a MP game, only the leader can now do the 0.1 step, but all are still able to right-click for 0.5 sec.


MP RESTING MECHANICS REASONING: Because The Scroll is not based in real time, and it caters for more than one player (i.e. Multi-Player) something has to be done with respect to TIME, especially when RESTING. A key point being that the default REST function (R Button) would normally automatically pass time for everyone , regardless of their individual needs. In The Scroll, the players now have the option to pass time or not, according to the party needs (for every players’ PCs). For example, if player 1 plays a wizard who uses all their spells before player 2 does (who also plays a wizard), then the following options are available, based upon the following D&D rule:-

It takes a minimum of 8 hours REST before a wizard can regain spells. Or to put it another way: Resting to regain spells is available every eight hours game time. So, if a wizard uses all their spells prior to this time frame, then eight hours must pass (in rest) to allow any to be regained. Options available are:-

A) If a wizard of player 1 uses all their spells in 4 hours of game time, but a wizard of player 2 does not, then player 1 can either play the further 4 hours game time, which means playing a further 1 hour real time before resting to recover spells (One hour game time equates to 15 minutes real time.), or …

B) Request of other players that the party stop and rest (pass time) to allow player 1 to have enough time to recover the spells that they have lost. If agreed , then TIME must be made to pass before the final result of that REST can be applied using the REST function to recover spells and HPs.

A player, as a member of a MP party, could (of course) simply NOT seek the go ahead to PASS TIME from other players if they wish to force the rest, but as time constraints may be an important issue in some situations of play, then it is generally considered good etiquette to consult with other players before forcing the passage of time. The important point to note, however, is that if eight hours game time has passed and there is NO NEED to pass time, then a player can rest (to recover spells and/or HPs) without having any impact on another player! (In a SP game, this is not an issue as they simply pass time and then recover for their party as they see fit.)

Further reading: Here are some links to past blog posts on the topic:-

  1. TIME …

THE VIGOUR SYSTEM: In relation to time is the need to rest and recover due to fatigue and exhaustion (and not just for spells and HPs). The rules behind these conditions are fairly varied (as a variant rule) and can appear harsh to the unaware player. However, The Scroll has implemented its own version of the variant rule, which is more generous to the PCs.

From the D20 Resource website, we know the following:-

FATIGUED: A fatigued character can neither run nor charge and takes a -2 penalty to Strength and Dexterity. Doing anything that would normally cause fatigue causes the fatigued character to become exhausted. After 8 hours of complete rest, fatigued characters are no longer fatigued.

EXHAUSTED: An exhausted character moves at half speed and takes a -6 penalty to Strength and Dexterity. After 1 hour of complete rest, an exhausted character becomes fatigued. A fatigued character becomes exhausted by doing something else that would normally cause fatigue.

FORCED MARCH: In a day of normal walking, a character walks for 8 hours. The rest of the daylight time is spent making and breaking camp, resting, and eating. A character can walk for more than 8 hours in a day by making a forced march. For each hour of marching beyond 8 hours, a Constitution check (DC 10, +2 per extra hour) is required. If the check fails, the character takes 1d6 points of non-lethal damage. A character who takes any non-lethal damage from a forced march becomes fatigued. Eliminating the non-lethal damage also eliminates the fatigue. It’s possible for a character to march into unconsciousness by pushing himself too hard.

In The Scroll, however, a system is put in place to indicate when an adventurer has been on their feet for more than 8 hours , in that they begin to suffer from lower vigour than they had at the start of a day. The more their vigour score drops through continued adventuring (and not resting), the more they begin to suffer from fatigue and exhaustion. The most a PC can suffer in The Scroll is -3 to strength and -3 dexterity and slower movement (when famished ). If they push themselves without eating beyond this, then they also suffer further penalties to attack and damage due to hunger. The PC does not need to make a constitution check, as HPs are NOT removed in this system. Furthermore, the heroes never fall unconscious as a result, no matter how sorry a state they become.

NB: It is also worth noting that just because one PC has a higher constitution than another, these detrimental effects due to fatigue and exhaustion are personal and relative. i.e. A fighter with 18 strength may drop to 15 if they go without rest and food, but this is still very strong compared to an accompanying wizard who may have started with 10 strength and has now dropped to 7.

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

Download v2.25 here: (NB: The “OTHERS” has also been updated with a updated TLK file.)



You said it! :slight_smile:


These error free sessions are rare and a cause for celebration :).

1 Like

I am being cautious not to celebrate too soon, as we have a long way to go yet. However, we have enough sessions under our MP belt now, to suggest it should be a smoother ride from here onward. It will be good to have the module fully MP tested, and that I can then say with more confidence that the module would be MP compatible.

A few sessions left yet though,

Out of curiosity, what make MP implementation so different? Is it your customizations that require extra care, or does it generally require more effort?

Hi Andysks,

Basically both my own implementations and general coding. A lot depends upon how much you want to keep all players up to date and in harmony with one another. I wrote a blog a few years back that covered many of the more common problems:-

Needless to say, I have encountered more issues when it comes to sharing various aspects of the game too, including my various GUIs, mainly to do with combat and puzzles.

Cheers, Lance.


Another successful session this time around, with very few issues. In fact, the worst issue was due to the player on WAN suffering some broadband bandwidth limitations, which was quickly resolved after a computer reboot and a stop of some background activities. Here are the lists:-

The List of Fixes

1) MAP PIN DEBUG FEEDBACK: There was some debug feedback that needed commenting out relating to Map Pins. Now commented out. (Did not affect play.)

2) AREA MAP BUTTON: In a MP game the ability to jump areas to update map pins should be disabled for all players always. This briefly showed on first load. This has now been removed. (Did not affect play.)

3) CREATURE ITEMS DROP: The chieftain lizard folk in the sewers had some creature items set as “Droppable”. These have now been fixed. (This fix requires a module update.) (Did not affect play.)

The List of Updates

1) VIGOUR TWEAK: (Another slight vigour tweak, that actually took place in v2.26.

2) SEARCH DEACTIVATION: If a player uses auto-pause TB Combat, and is currently in search mode, the auto-pause will now also remove search mode from all companions (or uncontrolled PCs) when auto-pause is activated.

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

Download v2.27 here:


This report is two sided: First off in that we did manage to play something of a session, but, frustratingly for the second, it will have to be repeated! This is all due to a corrupted save game from the session before last. So, although this report addresses some issues I have fixed since the last session, all of tonight’s storyline will have to be repeated in a catch up session. This is because while I managed to get the session up and running by using a “new” DM to replace the broken DM version, the problem turned out to be in the actual “module” section of the saved game, which contains the “state” of the module, including monsters either dead or alive. This meant that when testing a load from a newly saved game of the latest session, the DM was still broken.

I concluded that the corrupted save came after the player on WAN started to suffer lag on his broadband. I remember we had to save and reload a couple of times, and we started to experience some strange occurrences then. After checking, the last good save position was at 14 Hours 4 Minutes. Bearing in mind that our last recorded session time was 16 Hours 35 minutes, this means we will have to replay about 2.5 hours, which will probably actually equate to around 1-2 hours tops. So, hopefully, by the end of the next session, we should have caught up and done a little more than what I record here today.

The List of Fixes

1) TODD NAME FIX: Todd’s name (the blacksmith) had a default value “dwarf”, which displayed. This has now been removed and the MODULE has been updated. (The fix only shows when started from this module.)

2) TODD CONVERSATION LOGIC: There was an illogical flow towards the end of Todd’s conversation if the heroes killed Joss and Billy prior to speaking with Todd. This has now been fixed.

3) DM BUTTON OPTIONS: Prevented the DM from clicking on some buttons not relevant to them.

4) DEATH SCREEN (MP): Stopped the “Load” prompt from keep showing in a loop when trying to reload after a MP death. (SP has to keep looping because they can re-spawn.)

5) PATCH INFO: The patch information now only gives update info if the player is updating/patching. i.e. It does not show from a fresh started game.

6) SPELL CAST AI LOGIC: Updated the AI feedback to work better with TB auto-pause function. Now only updates when character sheet closes if TB auto-pause active. Clearer feedback.

7) LOAD GAME CHECKS: Placed more stringent stop checks when a player loads a game to help prevent spurious events and feedback (inc combat auto starting, equip feedback, etc). I also added a new GUI that tells a loading DM if the DM/Game no longer recognises the DM as a DM. This is what happened to our game and gives a heads up that the host needs to load an earlier, non-corrupt, game.

8) PARTY ITEM CHECKS (MP): Expanded the “party” check for items when playing a MP game. i.e. Some items can be checked from all players rather than just one player’s PCs. E.g. If player one holds an item that player 2 can make use of with a placeable, they no longer have to pass the item to that player for the player to be able to continue interaction as if they had the item too.

To reiterate, NONE of the above fixes stopped play, but all of them should clarify or make play easier.

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

Download v2.28 here:

1 Like

First things first: We managed to catch up on the game-play after having to restart from an earlier save, when I discovered the latest save game had been corrupted. It took around two hours to catch up, and we had another hour new play. Some player feedback also said that this had been the most flowing game for them, and the most free from any issues they had noticed. This post will only cover the gameplay points from after the point of catch up

Also note, that there are some important changes/fixes this time around, after some gameplay experiences. In particular, when relating to certain transitions. (More on that below in the Update Section.) This update also fixes the Show GUI that was accidentally broken in v2.28, and addresses a number of other minor issues, and some return fixes related to disappearing companions and gold (money pouches).

The List of Fixes

1) SHOW GUI: I managed to break this in v2.28, by basically placing it inside a check that prevented it from opening. I hastily restored it (on the night) and have left it restored in v2.29.

2) NPC NAMES (MODULE FIX): We noticed yet another NPC name that was not showing their correct name via the SHOW GUI (once fixed). This time it was “Billy” who showed as “Dwarf”. This time around, I have gone through the module checking the names, and found a few more, which have now had the default reference removed, which should restore the names I have given the NPCs. Note that these fixes will only show on a freshly started game. (i.e. Campaign patching does NOT fix this.)

3) MONEY POUCH (GOLD): There was another instance where the gold was not being correctly set after transferring a gold pouch to another player. I believe I have finally fixed this issue. It works in all testing I can do, but have yet to finally test in our DM MP game. (I am hopeful though.)

4) MISSING COMPANION: A return of the “missing companion” bug on a game reload. This relates to a companion not recognising the player’s entry to a game and returning to a default wait location. A faction set and check now stops them from disappearing on a player load.

5) ITEM DESCRIPTIONS: On rare occasions, some items descriptions may appear incorrect or relate to another item the PC carries. I have now added an extra line to help prevent this from occurring. If this should happen to anyone, a quick workaround is to drop the item to the floor (if possible) and pick it up again.

6) DM AREA ENTRY FEEDBACK: The DM was getting the patch info on every area entry. I have now placed a check to make sure it is only on first entering the game.

The Transitions Update (SP/MP)

The biggest change this time around is related to some types of area transitions. I made the alterations to help avoid confusion for players, especially in a MP game. Basically, some transitions, which only moved the PCs to somewhere within the same area , could be traversed independently by players and even their individual PCs.

For example, the stairs at the Bloated Buckle, and many transitions in the sewers are examples of the type of transition I am referring to. Originally with such transitions, the player had a choice NOT to have certain PCs follow their active PC if they had told them to “stand ground”. Furthermore, in a MP game, every player is responsible for their own transition, rather than have the leader of the party initiate it.

However, these transitions could cause confusion or difficulty in play, especially if there was an encounter shortly after the transition, and definitely if turn-based combat would also initiate an auto-pause. E.g. Player 1 makes the transition with only some PCs, and combat starts, causing automatic pause. Thereafter, trying to bring PCs from the other side of the transition (or more importantly in a MP game, trying to bring a second player and their PCs), became quite difficult to manage - and did not really work.

Therefore, for the minor tactical difference that this type of selectional transition offered, I decided to abandon that working and simply make them the same as any normal area to area transition, which moves all PCs at once, regardless of their current follow status. In a MP game, this also means the lead player must “Gather The Party” as normal, prior to everyone transitioning.

On top of that, I have also improved the Fade To Black timing with respect to auto-pausing a combat after a transition. Previously, a check was in place to ensure the player would not be left “in the black” of a fade if an encounter paused the game. However, the latest version now allows the fade to finish before any potential encounter can perceive the party and take place. It’s a subtle difference, but one that means PCs that are supposed to go into puppet mode prior pausing now do so, and there is no automatic spell casting, which was the problem experienced in the original method.

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

Download v2.29 here:


We had a very stable and productive session this time around. There was only the need to reload the once, when my wife’s area map corrupted. This is the first and only time I have ever seen this happen, and I suspect it relates solely to being in a MP game where network data is being used. It was fine on a reload, and for the rest of the night. Other than that, the heroes managed to complete four of the journal entries with very few issues. Most of these following fix SP games as well…

The List of Fixes

1) TB AUTO-PAUSE TIMING: Another tweak to the timing of combat auto-pause subject to the PCs actions with respect to just having transitioned or coming out of a conversation. Sometimes the auto-pause could be slightly off and PCs would start to cast spells in these situations, which is supposed to be automatically disabled when allowing auto-pause to pause at the start of combat. These situations are few and far between, but I believe I have caught the remaining few. If we discover more in the future, I will update them then.

2) NPC NAMES (AGAIN): Frustratingly, even after going through the module last time, looking for other instances where the NPC default name had not been removed, we still encountered another NPC with a default name left attached. (Kerres in the Guildhall.) As most builders will probably know, even though we replace the first name of a template with our own name for an NPC, if the default tool set string is not also removed, then the code will refer to the default name rather than the one we give them. It is one of the more annoying issues that we can come across, and something I did not know until quite late in the building. I will continue to update any more we find and release in MODULE fixes. (i.e. Module fixes only make a difference when playing a fresh game.)

3) MELICAMP CONVERSATION/JOURNAL: This was the biggest issue of the night, although very minor compared to others in the past weeks, and was to do with logical flow and conversation options and did NOT stop play or prevent concluding the quest. Basically, there were two issues:

First, a variable was one out when it came to allowing the heroes to ask about the barrier problem: The option to ask about the barrier is based upon the heroes quest state with respect to locating the rods for Orechin. The option is supposed to be open if the PCs have not yet found all the rods. However, in this case, it had been excluded due to the variable check being out. This has now been fixed.

The second issue was the journal entry after the heroes had finished speaking with Melicamp. The main problem was that the code to update the quest state was at the end of the conversation. However, I had forgotten the fact that the conversation would be held twice, and the script that fired at the end would only be valid after the second time of speaking. Therefore, when it ended the first time around, the wrong journal entry was set, causing the illogical flow. This has now been fixed.

4) STORE TEST (MP): I have now added a quick check to ensure that only the party leader actually stores the variables on a STORE TEST, otherwise a second player could clear the variables if they had not written anything, or even change them if they had written anything different to the leader.

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

Download v2.30 here:

1 Like

We had another productive session, with very minor issues, which were not too dissimilar to last time, but with different objects. Thankfully, all issues encountered were easily overcome and did not impact play at all. There was one instance on an area transition at the start of the game when a player (WAN) dropped to desktop, but this was more likely due to the computer not having had a fresh reboot before joining the session. However, I have added some more area enter code checks that prevent over-activity on acquire/un-acquire, equip/un-equip checks when entering a new area. (See fix info below.)

The List of Fixes

Useful for both SP and MP games.

1) AREA ENTER UPDATES: There were some situations (e.g. Entering a dark place with a lantern or torch), when the on area enter code did more repetitive checks than it needed to. This has now been trimmed to minimise checks, making for more stable area transitions.

2) NPC NAMES (AGAIN): I am still being caught by these module only fixes. This time the “Scourge Victims” that can be encountered had the default of “Zombie” overriding my names. These have now been fixed. I will continue to update these as I come across them. (Again: These are only noticed as fixed when starting from a fresh module.)

3) HENCHMEN/SUMMONED AI: I noticed that a PC’s summoned creature appeared to be ignoring a combat situation and calls to fight, unless attacked itself. I checked the code and I believe I had the wrong function call in the section that mattered, and changed it to what I believe it should be. This should have fixed the problem. I will only report back if the creature (summoned or henchman) fails to obey calls to battle when next used by the players; otherwise assume fixed. UPDATE: Code has now been tested and confirmed working in the newer v2.32, which is now available for download.

4) RED LEADER CONVERSATION LOGIC: Another logical flow issue with respect to the conversation that can be had with the Red Leader at the end of the Shoreline Road. This occurred if the PCs had acquired a permit before speaking to the Red Guard leader. A conversation node that should not have been available was. (It covered a similar conversation that the players would have already experienced for presenting the permit.) This has now been fixed. Furthermore, I have added a “Nothing Thanks” to allow players to drop from the conversation immediately, rather than have to ask about the store and then drop out.

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

Download v2.32 here:


Another successful session with minor interference. (My favourite session to date.) In fact there was only a single hiccup in the last session to do with the Rune Lock puzzle, which has been fixed for future encounters with such. In any event, the problem was so minor it did not inhibit the heroes progress. Apart from that and the odd typo, everything else went smoothly, and we had an enjoyable and relaxing experience.

The List of Fixes

1) RUNE LOCK PUZZLE: During the adventure, the PCs will encounter Rune Locks, which the player resolves as a puzzle. This appeared to work fine at first, but when a second player used the puzzle (to attempt it instead of the first player), it thereafter appeared to lock the first player from trying again if the second player handed the process back. I addressed a localint that allowed the lock worker to be stored and returned more easily, and now the lock works fine in a MP environment. Furthermore, in testing the lock to ensure it worked, I noticed a memory leak when it started (related to an XML call), which I have now also fixed. Also adjusted the vigour penalty. (NOTE: v2.33b also allows slightly quicker clicking on the runes.)

2) SEBASTION RELATED TYPOS: There were a couple of conversations surrounding the Sebastion conversations that have now been fixed. i.e Bewilder > Rewilder. Heroin > Heroine and Sword > Axe (when Sebastion offers to ID the weapon found).

3) GAME BALANCING: I adjusted some of the encounter levels to help balance the game.

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

Download v2.33b here:


UPDATE v2.35 fixes a database fault introduced in v2.31 - v 2.34 (3 Jan 2019 - 6 Jan 209)

ALSO (For v2.35) …

Just a quick update to prevent accidental trial exit of module via transition from New Edgeton to Module 2 (which is not available yet). I had the checks disabled as I was testing for module to module transfer with future modules in mind. And I had not re-enabled the checks for quite a few versions. The check has now be turned back on so the player has the correct response when clicking on the transition south of the village where the barrier currently blocks the way.

There are also some minor module check updates for future modules in this update, and a minor update to do with a DM presence.

Normal updates will resume after we play some more, or if I encounter anything that requires another update.

Download v2.35 here:

1 Like


This is just a quick note about how to download and patch my module for those that may be doing so, as the terminology used may be misleading to some players …

There are a number of ESSENTIAL files that a player needs to play The Scroll. Two of these essential files (of those required) relate to the MODULE and CAMPAIGN folders. If you download and begin to play my campaign, then it is CRITICAL to keep the CAMPAIGN folder up to date, as this is the means by which the module you are currently playing is patched.

i.e. Replacing the MODULE folder does not patch the game you are playing. Any newer MODULE folder can only be made use of if starting the game/module from anew. (It’s a “nice to have” for full benefits, but will not prevent anyone from finishing the module if using an older version.)

Therefore, to reiterate, if you have already started the module, then it is the CAMPAIGN folder that you need to download and is a CRITICAL replacement to the existing one when keeping your game patched and up to date. This is the folder that FIXES game-breaking bugs.

Starting from v2.36 of The Scroll, (which will be for both the module and campaign folders), I will include (in-game) information about the module version being used as well as the campaign version. The module information will be purely for your information and NOT an indication to replace or update … UNLESS, you are prepared to start the game again. The game will continue to report if you have “patched” to the latest campaign version at the beginning of a session.

Hopefully that helps explain the procedure for those who may not be fully aware of the patching process.

Thanks, Lance.

1 Like

Another successful session, allowing me the opportunity to refine some of the existing code, improve MP performance & gameplay, and continue to prepare for any future modules. Basically, this latest report is less about fixes (I fixed one typo in a conversation with Sebastion) and more about new beneficial code. Check out the news below and catch up with the heroes adventures as normal.

The List of Updates

1) MECHANISM PUZZLE MP SUPPORT: My player on the WAN asked if I could include the “mechanism” puzzle in the MP puzzle support. I have already made the “Ripped” and “Cypher” puzzles MP compatible (in that they are viewed by all players at the same time), and now I have managed to add the “Mechanism” to that list. As usual, the observing player can “cancel” out of observing if they wish, but can otherwise be part of the puzzle by default. I have kept a number of the puzzles to be one player at a time, simply due to the complexity and potential pitfuls of coding such for MP.

2) MP LOADING: Although most won’t see the benefits (if playing SP), I have managed to improve the way a MP session loads depending upon whether the host is a DM or not. Basically, if a DM is present as the host, the code now ensures the companions are ready to be taken back on board by any player who enters the game after the DM has first connected. Alternatively, if there is no DM, then the designated player leader (host) loads as normal and all PCs now reattach themselves to the appropriate player.

3) BETWEEN MODULE VARIABLE SUPPORT: I have managed to add some code that enables me to bring across variables from one module into any later modules. I used the “items in container” method, that works behind the scenes as the player moves from one module to another. It works fine, and now just awaits full usage as I continue to prepare the new module for the players who either play the first mod (including having a final save game if present), as well as those players who wish to start the later modules without having to go through the first again. It’s fairly stable now, but I need to tidy up what I intend to allow to bring across and what is removed … and then start the plot lines proper. (NOTE: The current module version is also now shown in the Main Menu.)

4) SHOW GUI TOOL: I decided to rework the SHOW GUI tool to be able to provide a quick way for players to have all their PCs “follow” or “stand ground” . (An ability not unlike the Dragon Age 1 GUI offered under the player portraits.) Check out my instruction scroll screenshot for the updated GUI, with all that it now encompasses (Go to the blog link for an image of the new GUI and instructions):-

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

Download v2.36 here: EDIT: The v2.36b simply addresses a TYPO that says “NOW” instead of “NOT”, as in “NOT AVAILABLE IN COMBAT”.

1 Like


before disco usurped the epithet

(the mood + lyrics of the earlier version still give me a chill)

and so it goes …

1 Like