Episode 89: Improving The Code!

Progress continues with Predestinated Days, alongside some final fixes and updates for the first module. The fixes required came when my wife alpha tested the second module for the fifth time using Hard Core death mode. I'll tell you all about it,if you want to read on...

Module Two Alpha Five Testing

The fifth alpha testing was actually pretty solid as far as the plot and general mechanics were concerned. What came to light, however, were a few campaign bugs that had crept in over the last few updates, which affects both the second module, and the first. Important to note, all issues noted below have now been fixed in v1.19,  unless stated otherwise.

PLOT ITEMS: In particular, an issue related to when a PC died (and the player had not chosen the Companion Protector gift that would allow a PC to fall unconscious only) and required "raising" from the dead. When this happened, an update to the way Plot Items are handled, (to prevent the Main PC potentially becoming burdened when they were transferred on a companion's death), managed to lose the plot items completely instead! It was a potential game-breaker, which was fixed in the earlier v1.18.

ITEM DESCRIPTIONS: A minor bug also came to light with respect to containers sometimes not updating the descriptions of items. So, I took another look at the container handling functions and addressed any code I found that had not traced the current container correctly. Now, if any description for an item is missing, it is updated. I also discovered that my wife used the context menu to open a container, rather than a double click (as I do), and so I had to address that area of code as well.

Other Testing (Inc Module One)

TB COMBAT: My thanks again go to Dustin_Offal for noticing this problem. Basically, when TB Combat initiated, it could (sometimes) cause a summoned creature in the party to un-summon! This was a hard bug to track down, but I eventually traced it back to an old line of code that was simply no longer required. Once I removed it, the problem was solved. However, in the two days prior to its discovery I was able to make more improvements to this area of code, especially related to its overall efficiency. Now, the TB Combat initialises a lot more smoothly, and PCs using ranged weapon, target enemies more intelligently.

SEWER ACCESS UNITS: Dustin was also the person who discovered a minor bug in the sewer access units too. Related to the container issue reported above, these units also required some extra special handling to prevent closing at the wrong time and also to prevent a PC wandering up to them, when not required.

EXAMINE & MINI-MAP GUIS: I also noticed a couple of GUI issues, which may have flown under the radar for some time. First, the Examine GUI is supposed to report the RANGE of an object in its top bar. This was missing sometimes, due to a variable not being cleared. Secondly, the Mini-Map, which can be made to appear "larger" or just as an area name bar, would lose some of its image on its largest setting. I fixed both of these GUI issues too. The latest screenshot from Module Two (below), shows the larger Mini-Map open and now displaying correctly.

BETA TESTING: Dustin is currently playing through the first Module, The First Day, so that he has a party he is satisfied with to start his run of Stage One of Predestinated Days, the second module. Subject to the time he has available, he may be in a position to start the second module at some point in the near future and, if so, he will be the first person, other than my wife, to give some feedback regarding the first stage of the second module.

Stage Two Development

My wife has started her sixth alpha test of the first stage of module two. I am not anticipating any further problems, but I would like to see if we can make it through this stage without any issues (at all), at least once. As I have reported in previous blogs, current module two scripting has moved away from the core files (apart from where fixes have been required), and I have been concentrating on completely new scripts.

As an example of how I do newer coding, I now aim to write only one or two scripts that manage the entire events for a specific area or situation. The script code manages various events subject to how it is attached to an object and to any variables passed. So, whereas I once may have used two to three scripts per object, I now try to use only a single script (or two), where possible. The same goes for conversations related to an area, event, or other object. The new scripts and conversations are better implemented and more "cohesive", rather than a mishmash of various scripts handling what only a single script now does.

This approach is a continuation of the "improvements" to the old code I have been implementing over the last few months in preparation to run alongside the second module. Multiple versions of similar scripts have been amalgamated into a single all-purpose script. Not only does that make finding a specific script easier when required, which helps speed up building, but also helps when looking for bugs in the code. The problem in the past, was my not realising that similar scripts could be easily amended to accommodate multiple approach of use, so that only a single script was necessary for multiple event hooks.

I confess that I have also recently discovered some "old" scripts that still remain (while I was improving the code in readiness for the second module)... but unless they end up having to serve any other purpose for new module work, I am just going to leave them be. My goal now is to write new scripts for the new module, and only rework older scripts when and if I have to. Hopefully, enough module-to-module transition tests have been carried out now (with the latest alpha tests), which means all the older scripts that had required any reworking has finally been done. Maybe one or two conversation scripts can still be amalgamated, but I will treat them as I come across them and if they are needed for the newer modules.

The last Module Build released was on the 1st October 2024 and unless anything comes to light, this will also be the LAST module build for the first module. The only reason for me to update that build now, will be either due to a module bug, or me just wanting to bring modules and campaign dates to a single timeline. That may happen when I have finished the campaign completely: including module three!

For those following, you will recall I was hoping to finish Bloodstone College in the last month, but due to its continued complexity, I still have some elements to finish, especially related to the latest area (related to this scenario), which has had me have to think hard with respect to MP gaming code. The good news is that I am now writing the "exit" code for that particular area, which means I am seeing light at the end of the "area" tunnel. The latest first module is now out for grabs, and if I don't have any other issues with that, I can concentrate fully on module two, and hopefully, get back to the other sections I was working on a couple of months back.

As an aside, I did find myself having to double check an area from the third stage of this second module, which shows I am still progressing in other sections related throughout the second module as well as the college section. i.e. You may not hear about everything that is going on between blog posts, but, as I have said many times before, I am still making progress.

The Heroes Find A Cave (Showing Fixed Larger Mini-Map)

New Container Direct GUI Calls (I.E. Can Avoid Inventory)

Episode 61: Mysteries Abound!

I cannot believe almost another month has passed since I last posted. I must be caught in some kind of time vortex, sucking life faster than I realise ... and talking about sucking life, (please forgive my awful textual segue), I now bring you the latest news for the campaign, which includes vampires! Read on...

VAMPIRES!

First mentioned a year ago, in this post, I recently revisited a vampire quest I am working on ... a nightmare side attraction for those that hate these undead in particular. Like all the quests designed for the next module, Predestinated Days, (the second module of The Scroll for the Althéa Campaign), I have tried to make this undead adventure more involved than the player may have initially thought it was going to be. By this, I mean including more steps to the quest as a whole, rather than a simple discovery and resolve. i.e. A backstory with repercussions that have affected the world environment beyond the player's normal expectations. Whether I pull this off or not remains to be seen. At the very least, I hope it will be one of those quests that stands out according to its own story and merit.

COFFIN SEPIA

I have also updated the original basic GUI regarding the vampire coffin information to be replaced by a new sepia style conversation. (See screenshot below.) As I have reported in the past, I have added a number of sepia style conversations that may serve to act as a means of interaction with the environment in a more "pen and paper" style interaction. The vampire coffin is the latest addition. Results can range from a peaceful backing off, an instant slaying, or a dreaded encounter!

LOOK THIS WAY PLEASE

I recently had a long struggle when trying to use a function, SetFacingPoint, to make party members face a certain way during a conversation. It turned out that any member that is "bumped" into as the conversation starts can fail to turn to face a direction when this function is called. I finally resolved the issue by ensuring another facing function was called just prior the line I needed to make the members face a direction. Here are the lines in the order required for it to work ... NOTE: The home brew NowFace function is the one that calls the SetFacingPoint function, and oNearestWP is the object to face. I post it here to help others and to remind myself should I forget.

// MUST USE SETFACING TO "UNLOCK" STUCK PCS BEFORE USING A DELAYED FACE TARGET
                DelayCommand(fDelay, AssignCommand(oFM, ClearAllActions(TRUE)));               
                DelayCommand(fDelay, AssignCommand(oFM, SetFacing(GetFacing(oNearestWP)+ iALLFACTIONCORRECTION, FALSE)));               
                DelayCommand(fDelay+0.1, AssignCommand(oFM, NowFace(oFM, vTarget)));               

MOVING FORWARD

I cannot deny that sometimes there feels like a lot left still to do. Arguably, this module should, perhaps,  have been broken down into two or more, but the structure of the quests and their execution makes doing so extremely difficult. That is, the events of the story at this stage of the campaign require the diversity of quests and their interaction with one another to give the module the depth I am seeking to achieve.

I believe it is working out as I hoped, however, because while I feel almost overwhelmed with what remains to be done, I also reflect upon what I can only call the "fullness" of the experience I feel the module, I hope, will deliver. Considering there are only a handful of key quests compared to (perhaps) many modules available, the overall depth of the module still feels satisfying to me.

This is because I am including a world map with various places to travel between and explore. Some places will not be available until a player uncovers certain paths, but even this varies according to player decisions. However, from these various world map places, areas uncover to reveal further details and plot developments. Finally, these areas break down into further events and adventures, each with unique characters and various special qualities to help them feel new. I know I could sound like I am just explaining the game in general, but I hope I have included enough new game-play mechanics, improved conversations styles, and general control improvements that will make the whole experience an exciting one.

A Vampire Coffin!

Episode 56: Being Made Aware of the Details

There have been a number of updates and additions made to the campaign over the last week or so. Hopefully, you will already be aware of the new TASK GUI, which helps reduce reliance on in-game TOKENS. Well, now I have added a few other features to the mechanics, a couple of which are to do with the default game colours, which I hope will be especially helpful for the colour blind among us. Read on ...

Continued Improvements

Split Gold GUI

As regular readers of this blog will  know, I have been reworking key campaign mechanics to improve efficiency for the multi-player (MP) game. This has ranged from area load times optimisation to general code tweaks. This week, upon request of a player, I also "fixed" the splitgold.xml, which is very frustrating to use in its default state. First, it does not provide an immediate focus to the editable text box, and secondly, it leaves old data behind that has to be deleted before a new gold amount can be entered. Not only did I fix both of these issues, but I also added functionality allowing the player to use the "return" key to complete the transaction (rather than have to return to the mouse to click the OKAY button), or use the "escape" key to back out and cancel via a keyboard shortcut too.

Enemy Counter

Affecting both SP and MP games, I have now also added a monster counter for the immediate encounter that tracks how many creatures are in the current combat. It can go both up and down, subject to whether new enemy creatures enter the fray, or the heroes kill an enemy. This week's first screen shot shows a combat where the counter is displayed. Note, in this screenshot it shows 9+, which is the highest it will show for encounters where there are more than nine creatures. Once the number drops below ten, the counter updates one for one. An encounter with more than nine creatures is a rare one.

Turn-Based Combat Showing The New Enemy Counter (Top Left)

The Important Details

Only recently was I made aware of some aspects of the game mechanics that I did not know were there. This was due to my colour-blindness and either not seeing a colour at all (positive attribute bonuses) or finding it very difficult to see (on some unidentified items). It also made me think how easy it is to pick up an item and lose it somewhere among all the other items you may be carrying.

I try to go out of my way to keep the player informed of every stage of the story and where they are in it. However, if they should miss an important scroll or book among a treasure they looted, then it is possible for the story to stall if the player forgot they had acquired such an item during the distractions of the adventurer's life. For someone like myself, who struggles to note "new" items among "old" due to the subtle colour background, it can be quite difficult to locate new items among the many items we have collected.

So, to overcome this issue and the issue of not being able to see attribute benefits on a character sheet (in a light blue apparently), I was able to track down where the  default NWN2 colours were referenced (NWN2_Colors.2da) and alter them to be a much more vibrant and obvious blue colour. Furthermore, I added a system that made important unread reading materials flash this prominent blue when opening the inventory or when switching tabs; and to remain "unidentified" with said blue colour until fully read. Note, these books and scrolls (to which the system applies) are so low in gold value that anyone can identify them and they become properly identified (normal icon) once fully read.

Additionally, I have the same vibrant colour briefly flash on unexamined items (the equivalent to newly found items) to draw attention to the player that they have not yet been examined. Unlike essential reading material, they do NOT remain blue after flashing, allowing a player to click on them as normal to clear down the "new" status. Hopefully, this second screen shot of the week helps demonstrate ...

More Vibrant Colours For The Colour Blind

 

Furthermore, if an important reading item is discovered upon opening the inventory, the player also receives some Notice Text and a small sound to indicate they have something important to look at. For someone like me, or for the player who just likes a little more clarification of items, this makes a big difference.

And Finally ...

I have continued to alter areas for both module one and two, allowing more room in areas for larger parties. One point that became clear to me as I test in a MP environment is that while the idea of tight twisting corridors sounds good on paper and may even look quite good in game, nevertheless, it does not make for easy controllable gameplay.

I have also been continuing work on module two conversations. I believe I have finally reworked all the logic to ensure conversations work correctly for both SP and MP games. Now, I am adding to them as I find the time, and continuing to make slow but sure progress plot wise.

Unfortunately, to prevent spoilers, I cannot discuss these as much as the mechanics. However, I will see if I can come up with any teasers next time.

Episode 48: Tell Me About Yourself! (PC Backgrounds.)

Predestinated Days is intending to offer more conversation options to the player subject to the various backgrounds that they allocate to their PC and companions or other created PCs. Furthermore, as I wanted to support exported PCs from other games, as much as my own first module, allowing the player to add a PC background retrospectively was important to me, so that's what I did. Read on for more details and other news ...

PC Backgrounds

One of the big areas I have been dealing with over the last week or so is building a GUI to allow players to quickly and easily work with a PC's background. Normally, this is a "feat" option that is only allowed for Created PCs from the start of play. I believe a builder could also pre-allocate a background "feat" personality for potential companions, but unless this has been done, then this "free" feat, which generally comes with pros and cons for taking it, is often not used. However, with the new GUI, a player need only right-click on their character sheet portrait and an option to add any missing background can be achieved. (See this week's screenshot below.)

In this case, I believe having a PC background to be a very useful aspect of play that both players and builders can put to good use, especially when role-playing a particular PC within conversations. For while we all generally like to play our PCs certain ways, having some background guidance can go a long way to help steer this gameplay. Take for example a PC who is a bit of a "flirt" compared to one who is more of a "bully"; they would tend to approach a conversation rather differently to one another. Therefore, while it is important for the builder to be able to provide a useful selection of options, having some stereo-typical background types can also help us to add "colour" the conversations too.

There is an argument that this may make our PCs appear rather two-dimensional, and I do understand that. However, compared to every conversation otherwise speaking with "one voice", then having a few core background types options thrown into the mix cannot help but make the conversations a little more interesting. To this end, I looked at the backgrounds and decided to set aside five core groups, of which the fourteen character types we have available to us fit within. Look at the following table ...

PC Background Types

A table showing how the fourteen background options split across the five core groups.

NB: There is an ERROR in this table. COMPITENT (sic) should be CONFIDANT.

How The Backgrounds Fit Into A Specific Group

When a player comes to play Predestinated Days, I am hoping they might select a PC background for each of the PCs they play, with at least one coming from each major group. If they do this, then when it comes to actual conversation gameplay, the player should end up with one or two different options that better reflect their PC background choice. Furthermore, and to encourage such play, I give an additional XP award every time a potential role-play option is opened, irrespective of which conversation line the player ends up taking. And now, with the new GUI, even adding a PC background that previously had not one added for one reason or another, can simply add one.

Writing the conversations and taking extra care to ensure I can include some better background type choices certainly takes more time, but I hope the end result will add some more gaming depth and personal role-play for the player. So while not every conversation will have these extra lines, I hope to include them in many, especially the more important story related ones.

PC Portrait GUI

On the back of adding a new Background GUI, I also looked into the existing portrait XML, from which the new Background GUI is associated. I found a really odd unintuitive setup for selecting a new portrait, and it was clumsy to use, and so I edited that to make the whole portrait selection much more user friendly for those that like to change their portraits for their PCs.

I was also able to write a new XML that allows builders to force update a portrait on a PC for any reason. I did this after andgalf (of the NWN forums) requested such, and as I was in that area of coding and it was something I also was looking into doing, I just went ahead and did it. The end result worked for andgalf's purposes, but it did not yet do what I was after due to requiring an XML file for every portrait. At the least, it may come in useful at a later time.

World Map Travel

I also spent some more time finishing off some world map code, especially the area of code that calculated map travel speed and related times. I wanted to give the player a "real time" feedback of passing time as they travelled the overland map. This is done now and works well enough for my liking. Furthermore, as Predestinated Days intends to use all three world map systems, arranging all the various waypoint types (WP) depending on the system the player wanted to use was a task. For example, in some places a player may choose to use a MAP and jump to a location on the map, or choose to travel overland instead. Two jump types for two different scenarios. Add to this a potential portal jump option and keeping track of WPs becomes tricky, as much to ensure overland map GUIs are on or off as much as anything else.

The First Day Updates

Updates to the first module of The Scroll campaign will now be referred to as updates to The First Day, which is the proper working title for the first module. To clarify, I may still refer to my modules as The Scroll in general, as that is the campaign name, but each of the three module of which it comprises each have their own name.

Anyway, module one, The First Day, continues to benefit from general campaign improvements, including updates to the weather system (clouds are randomly scattered now subject to weather condition); a couple of open door conversations have been made more "secure" to avoid overzealous clicking by players. All these updates, as well as others mentioned in previous posts will become available in the next v1.41E release, so be sure to download it. There will also be a new module release, as mentioned in previous posts, but will also benefit from other updates of late, including some waypoint colour changes for ease of locating. E.g Exits in cyan; important point in yellow.

Once my wife has finished her latest play through, I will likely upload v1.41E then, unless there are any other alterations I want testing prior to another release.

Missing PC Backgrounds Can Now Be Added During Play!

Episode 45: That's Enough! (Polishing Play)

It's funny how you let things slide with certain aspects of a design until you notice something for the umpteenth time and then simply say to yourself, "No! That's enough!". I had a few experiences of this over the last two weeks, and so decided to deal with them all. From a couple of subtle area transition changes to GUI text layouts, it's been a hodgepodge of stuff. Couple that with working on another area that players will learn holds more secrets than when (likely) first discovered, and you have earned another blog post with two screenshots. Read on for more info ... 

IMPORTANT: Any updates mentioned in this post will not take effect in module one until the v1.41E update.

TRANSITION CHANGES

In the last couple of weeks, I decided to jump back to another area I am working on because it links one section of play to the next. As I say in the intro, it's a key area that players will eventually learn holds a secret. In the process of working with it, I had to look at an area transition and it was while working with this area of code I determined to deal with two niggling points I had seen in my own play testing ...

1. Weather Changes: When moving from an outdoor area to another area, I originally had the timing of the weather changes occur as the game faded to black. This could be noticed if the changes were more significant, and so with a small timing adjustment, these changes are now not seen.

2. Time Changes: Similar to above, but often more noticeable, were if a rest altered the time of day from night to day. The selection would apply the change as the player faded to black, which I was not happy with. Now, the game fades to black before applying the time changes, which means the sudden light changes are not noticeable.

3. NPC Locations: On the back of these two VFX changes, I also looked at the NPC control code, which determined where NPCs will be located as a PC entered a new area. This area of code goes back to some of my very first coding ("Real Life" System) and it had been patched together with various functions throughout the years, until it reached the stage it is today. However, while it currently works for module one, it "fails" for module two. It fails because module two has more areas than module one, and the way I was currently handling area loops was not efficient enough for the number of areas module two comes with. To cut along story short, I repackaged four inefficient functions into two, which use far more efficient loops, as well as now use functions to "hide" creatures if they are not actually encountered anywhere else, but are simply absent. One of these new functions now handles the "de-populating" of NPCs if required (as a PC enters or leaves an area), while the second handles the NPC location upon a PC entering an area. The latter function had been the main issue, as loops had to consider NPCs returning to the PC's current area from any area in the module! The new system is really good, and much simpler for me to keep track of what is happening from area to area now.

NEW INVENTORY GUI TEXT

Another niggling point that I have been meaning to address for as long as I can remember is what an item's text says about its properties. I found that the so-called "unique" properties to be some of the most confusing both to use and/or have attached to an item's description. To make things clearer both for me as a builder, and for players, I edited the 2da files (itempropdef, iprp_spells, iprp_chargecost and spells with new tlk entries) to alter how the text displays when describing item properties. Whether it was simply to remove ambiguous or superfluous text, or even correct an official 2da entry (compare iprp_spells 359 with spells 386), where "Activate Item (Short Range)" would have been more appropriate had there not been two potential options that varied according to a power level. I ended up removing one option completely and reworded three to keep to a standard that I hope players can relate to more easily.

I also found the following frustrating to handle: having an item to be "Single Use", but able to be retried if "first usage" failed, without having the item used and removed from the PC's inventory due to its "single usage" activation. You could either (a) use the "Single Use" property, but code in a check to recreate the "used" item for the PC if it was used "inappropriately", or (b) use the "Unlimited" property, which allowed multiple uses until success, but could give the wrong impression about an item's usage if not clearly explained in it's description that it is actually a single use item!

Anyway, during my 2da rewording exercise, I came across iprp_chargecost entry 7, "0_Charges/Use", which at first glance, is good for nothing! However, it has a similar effect as the "Unlimited_Use" entry with respect to costs, but importantly, its useless description can be edited (as I have done) to now report "(One Use)". i.e. Like the "(Single Use)" equivalent, I now have a version of a 2da entry that allows me to say an item is a single (or one) usage item while allowing the principle of "Unlimited" attempts of that "one usage" without the need to recreate the item due to inappropriate usage! This means, I can now have "One Use" as part of the property description and even on a fail, the item is NOT recreated, meaning such an item will not be lost from a quick slot (if used). This is something I can make better use of moving forward, but I have also edited many campaign items that module one also uses. Basically, items that once read "(Unlimited)", but were actually single use items, will now read "(One Use)". I decided to stick with a subtle difference in wording from repeating "Single Use", as item usage is (in this sense) still subtly different.

New Special Properties Text Example

MODULE TWO INFLUENCES

There were a couple of other minor updates to all campaign code due to the influence of module two:-

1. Spell Book Ownership: Upon testing module two, I noticed a wizard would think their spell book (named as theirs) was not belonging to them. It was a minor glitch due to variables being lost between module change overs, and could easily be "fixed" by the player having their PC read the book again. However, this is not meant to happen, and so I changed the code to detect ownership by the name already recorded with the book rather than check a variable. As names are carried between module, this was a better format to follow, and I made a mental note to watch for similar items.

2. Walk Waypoints: Another area that required a minor code tweak was when I noticed some NPCs of module two disappearing from the area upon a PC arrival - a good result proving that the new area transition NPC checking code mentioned above was working - but nevertheless, not a good result as far as what I needed these particular NPCs to do. It turned out that this was the first time I had used Waypoints for an NPC in a different area from where they are first encountered, which they move to after said initial encounter. It was an easy enough fix, which, as I do not employ area to area waypoints walking in this way, I decided to simply check via the current area the NPC was in and keep the checks separate instead.

NEW SEPIA IMAGES

Something else I have been keen to include starting from module two are DM information sepia images. (I include one without any wording as a screenshot below.) It's something I have been looking at for a while, and being reminded of them after playing a little Pillars of Eternity (which I hasten to add reminds me a lot of my own module in some ways), worked an idea which now works flawlessly. I am considering using it in a couple of ways, subject to what opportunities arise: Firstly, and primarily, they will be used simply as a means of introducing an area or object on importance. The idea being to present the sepia image with text and a voice-over as a kind of introduction to the object in question. My first test area (image without text below) works well as it fades into play, has a voice over and then fades into gameplay again, all the while allowing a player to click out of the event if preferred, and drop out of the image and stop the voice over. It took a bit of experimentation, but I eventually managed to succeed in being able to pull off the event using the conversation facility in full cutscene mode. Secondly, as I was able to employ the conversation facility, it also means I can employ these kind of DM sepia images as interactive events like those I was reminded of in Pillars. It could (if somebody wanted to render more images) even allow the scenes to change like they do in Pillars, but that is not something I intend to do at this time of writing. I just thought it useful that should I ever wish to add player choice text, which altered both outcome (and potential images), then that was still possible too.

THE END RESULTS

All these latest changes have had quite a visual effect to overall gameplay, as well as improve its efficiency again. Thankfully, I was also able to finish my "special" area transition link that started me along this path in the first place, and it works like a charm. Of course, I cannot tell you much about it, as that would be a spoiler! However, I hope you have appreciated the work that went behind something as simple as this piece of module two update.

A Secret Way Opens Up!

New DM Information Sepia Images (Without spoiler text.)

Episode 38: Coding Monsters!

Let me say straight from the start that this post is not about actually scripting monster AI, or even a tutorial about how to design a monster in a toolset. In this case, I am simply referring to those technical "monsters" builders face when trying to produce their modules. From applying animations to writing scripts, they all seem to come at various levels of difficulty, just like those "real" monsters we face in the game itself. So while some such encounters may occasionally appear as "simple" as a goblin to beat, others feel like dragons! Even builders skills can be thought of as in classes and levels themselves, so what may appear simple to one builder becomes a real challenge to another ... and haunt them for years! Read on for my latest XP gains in building ... 

The Patrolling Guard

A couple of posts back, I described how I had been wrestling with some animations and how they may or may not work within conversations. Recently, however, the issue with animations has extended into the area of walk paths for me. In the past, the official WalkWayPoints function (and accompanying scripts) had always been a bit hit and miss for me, and so a few years back I decided to write my own version of them so that I could have more understanding and control with what was going on, especially when considering scripted waypoints: those that allow additional animations for a "walking" creature. This venture was a reasonable success, as it did allow me to ensure the creatures I setup worked as expected ... but only "most of the time".

I still continued to encounter issues where walkers would sometimes become stuck in the environment; a problem exacerbated if a PC blocked a walkers path in a limited space. Previously, I had tried to alleviate the issue by forcing the creature to try to move somewhere else before continuing their walk path. The problem with this, however, was it could cause the creature to constantly reposition themselves if the path was blocked by a PC. It looked like they had the jitters! Thankfully, in the end, I figured a way to smash that long standing monster, by using a ClearAllActions that now simply pauses the walker in their walk until the path is clear again. It was a relatively simple fix to a long time issue I had been struggling with. The only caveat I learned at this time was also to ensure any WPs laid down MUST be done in such a way as to clearly be guided around any placeables. For if a WP guide line even slightly clipped a placeable, the engine did not appear clever enough to always be able to walk around the placeable object.

XP GAINED: 100

The Random Monster

Once again, I am not talking about a random wandering monster, but the monster of trying to work with random probabilities in the game ... or with any probabilities for that matter. Twice over the last few months, I have had to face some maths to do with probabilities. As many will likely know, trying to deal with any kind of randomness on a computer is difficult. (Do some background research if need be.) My first issue was trying to determine the probability of a drop to ensure I was giving the player the right odds at acquiring certain items and the second encounter was trying to ensure treasure drops randomized their location fairly. For the latter, I learned a bit about the dangers of naivete.

XP GAINED: 100

The Persistent Monster

I have certainly had my share of these critters! Those who have been following my campaign build of the last few years will have seen some of the types I mean. I can even include The Patrolling Guard issue as one of these types of issues, but as I have already covered that above, I will give an example of a couple of others I have had to deal with recently.

An example of the kind of thing I mean is the usage of a variable string instead of a variable name. So rather than GetLocalString(OBJECT_SELF, sVariable), I will have done something like GetLocalString(OBJECT_SELF, "sVariable"). The issue with this kind of problem is that both lines of code will happily compile as neither is a compiler error. The error is purely one of my own making using "sVariable" instead of simply sVariable. The last one I had one of these, I was stuck for quite some time trying to locate why my script was not working.

Another example of an issue I can encounter of my own making, is if I should happen to change a ResRef of an item, which I have previously added to a store with its old ResRef. This again has caused me all sorts of issues when I am trying to reproduce an item from the original store bought ResRef, which fails to do anything because all that I have there now is the newer reference. Thankfully, now I have been stricter in my approach, I believe I must be near the end of any such issues moving forward.

XP GAINED: 100

The Deep Rooters

When I hit one of these issues, I can usually write off an entire session trying to get to the bottom of it - sometimes even multiple sessions. These type of issues tend to rear their ugly heads somewhat further down the coding path, and often even after a module release. The reason being, these type of coding monsters often only show themselves under unusual (or rare) situations.

For someone who has coded their module in the way I have, this means I am more likely (I believe) to hit these types of issues more than most, simply because I have a number of deeply integrated systems that allow multiple paths and diversity for the player. As an example, even the way "Death" is handled in my campaign has multiple paths. I can thank my wife who has been able to test the module a number of different ways and offer feedback in some areas of the code, which even I have not been able to fully test due to time limitations. I hasten to add this is why feedback from players is invaluable to builders, as we simply do not have enough time to do everything.

As an example of one of these deep rooted monsters, in her latest testing, my wife discovered that if she had abandoned a dead PC in the Sanctuary (while playing hard-core death mode, being abandoned meant the PC could no longer be raised from the dead), if she now brought another dead PC to the same area, the code had not yet been considering such a situation where a player (like she had done), now tried to raise another PC that was still able to be raised within the same area. I had to trawl through multiple death scripts to finally locate the one which needed a simple variable check added to fix it. A simple fix in itself, but one that required a lot of code searching.

As a final example of a recent deep rooter, my wife discovered a situation where she could return to an area and the NPCs would not be there. She quickly discovered she could work around the issue by reloading, but it was still obviously an issue for me to have to resolve. Once again, the problem was hidden among a number of functions relating to the whereabouts of creatures subject to the time of day, and if they changed locations depending upon night and day habits. Now most people probably do not even worry about this area of module coding, but for me, who wanted to design a "realistic" environment where time mattered, I had to track down why certain NPCs had refused to jump to their relevant locations upon her arrival. This monster turned out to be quite an "end of level baddy" type, even requiring me to rename some functions to help avoid misuse due to their naming. Along the way, I was able to improve the scripts (as they go back quite some years), and finally add the relevant function call to the right script to ensure these lost NPCs would now return at the appropriate time.

I hasten to add that even when trying to improve some of these scripts, simply adding a GetIsDead check for some reason would crash the toolset! Again, it was only a minor condition I considered adding to help "improve" efficiency, but the toolset was not having it. The additional problem was, having added it during the process of the overall fix, trying to locate that it was the cause when the final test crashed, added more time to resolving the initial issue.

XP GAINED: 200

Gaining A Level

Anyway, after all this monster slaying, I can safely say that I have probably gained enough experience to go up a level now ... well, at least in some way. I am still not much better in area designs and such like, but maybe I have gained a point or two in conversations and some scripting. ;) And all this is being added up to hopefully bring to you module two one day ... speaking of which, here is a screenshot.

Let's Sit Down For A Talk

Episode 33: A Confession and A Promotion!

Confession: I have not done any update on The Scroll (module 2) for two weeks now. I gave my wife time to finish play-testing the latest version (v1.33E) of module one (which uses the same core code as module two), so that I know I am in a stable position to continue moving forward. She has now finished playing the module for a tenth time with yet another mixture of PC types, and finally I can say, the first module is released as fully tested and complete. Ten times! you may exclaim, but I hope that also helps demonstrate some of the flexibility the module has as she still had one or two differences from her previous times playing. So, maybe it's time for a new group of adventurers to consider stepping in to help save the village of New Edgeton from their plight ... Is it you? If so, download The Scroll (module 1) now, safe in the knowledge that this version should be the final. In the meanwhile, what have I been doing instead .... ?

Promoting: The NWN Scripting Tutorial

I decided to spend some time trying to put together a basic NWN scripting tutorial for beginners. A number of people visit the forums asking for help with scripting (as to be expected), and I often hear the same questions asked. When I think back to when I first started writing scripts, I can empathise with those that ask the same questions as I did back then. So, with that in mind, I decided to put together a PDF that I hope helps explain some of the more basic steps required when it comes to writing scripts in NWN2 (helpful for NWN1 too).

This tutorial is now finished (at least for the time being), and is now available for download. I tried to keep it in a similar style as I did my XML tutorial, hopefully with what people may consider a more exciting layout than simple text, helping to highlight certain aspects when needed and make it easier to read. As I say in the manual, if it helps someone to achieve a result, then it has done its job.

Soul Shaker Revamp

I have also been SP play testing my newly revamped NWN1 Soul Shaker module, (with my wife doing the same now she has finished The Scroll). This has been progressing fine with me needing only to fix one or two points that got "disturbed" in the code changes. So far I have managed to complete around 75% of the module, and hope to finish it next week, with my wife finishing her play through shortly after. After this, I hope to send the files to a beta-tester, but am not expecting any further issues from their testing. Once they have completed, I will then upload Soul Shaker v2.00 for general release. At this time, SP will have been fully tested, but MP testing will come a bit later when I have the time and opportunity to play it that way later. However, I am not expecting any issues there either. Lastly, although I have managed to fix one or two points of code where a DM support can be used, this will probably have to remain untested, as (a) I will not be in a position to be able to test it with enough players and (b) I don't think there is much call for it nowadays. However, if the module is picked up by a group of players who do want to use it with a DM, then I will give as much support as they need and prioritise help for them.

The Scroll Module Two

Now that the first module of The Scroll is finalised, and once Soul Shaker v2.00 is released, I hope to return to module two of The Scroll. I am hoping the change of topic for the last few weeks and "fresh" start upon my return will help give me a push to move forward in some of the areas that had been holding me back. In particular, I have one or two areas that I need to finish furnishing, and some important conversations to write. In total, there are about four to five plot paths that need bringing together, and I want to be able to give it the attention it needs to do correctly. My concentration suffers at the best of times, and so I need to give it my fullest attention, which I hope to be able to do so knowing everything else is working as it should be. That's the plan anyway.

Can You help The Village of New Edgeton?

Episode 28: You Can Count On Vampires!

What a bit of a selection of things to tell you about in this blog! My efforts (for what they are) have been tested in a number of directions, as health permitted during this difficult time. There may be another word with "V" in it that we are all talking about of late, but for this blog, I am going to restrict its application for the monster, the vampire! (The other word was "Covid", but that's the first and last time I will mention it.) So, what's been happening ... read on ...

CLASSIC MONSTERS!

You may recall from a few months back that I managed to put together some scripts that will manage lycanthropy in my next module. Now, in a similar vein, I am trying to rework another horror classic: the vampire! However, none of my vampires will be "Count" like characters ... or at least, they will definitely not be like the caricatured beaten to death more times than even the hardiest of undead characters, "Dracula" if I can help it. I aim to have them simply be the monster that D&D has made them and try to escape the stereo-type portrayal if possible. But who am I kidding! I reckon the "Dracula" character is so embedded in our psyche that it will be impossible to escape some mental images of that persona.

New Visual Effects

So what's new? Well, I discovered that NWN2 did not support the gaseous form that we are familiar with when a vampire wants to avoid an untimely end. Therefore, I had to script a version of that. (See video link below for a demo.) On top of that, I was not happy with the way the vampire model relied on a spell to try to dominate its victim rather than use a gaze attack, so I updated that too.

I also applied some of my previously developed "undead" scripts to ensure level drains work alongside any Life Essences a PC may be carrying. In my modules, Life Essences can act as a barrier towards level draining, in that some undead will drain these from PCs before actual levels.

Other than that, most (if not all) other vampire aspects are covered, from needing magik weapons to hit, fast healing, blood (constitution) draining, damage and other resistances. They are quite a formidable foe, but one that can be overcome if the party of heroes go well prepared; normally with a cleric and accompanying spells.

In Development

I still have some scripting to do with respect to their coffins and stakes, but that is all going to tie in with other plot related stuff and so it will come together in time. And you can thank my wife for their inclusion, as she wanted me to write a story based upon the return of one of her favourite characters from The Scroll (module 1), and this is where it led to. I won't say who that character was, but some of you who have played module 1 already may well be able to guess. :)

GAME OPTIONS!

As most players will know, vampires have the power to dominate their victims. This led me to looking at the various effects that I would need to have the vampire employ, which in turn led to the game option function, GetScaledEffect. This function is basically called when some effects are used on a player to alter the overall effect according to the Game Difficulty settings. Unfortunately, this section of the NWN2 game appears a little buggy, and so I determined to look a little closer at this too, especially as vampires use the dominate effect.

I discovered a number of small issues, but enough differences to what I expected to make me decide it needed "fixing". It's still currently a work in progress, but I do now have a greater understanding of the various effects involved and hope to have an update to this section of the game not before too long. I may even consider releasing another update for module 1, subject to any requests for it or not. If no-one asks for it, then I may just leave it as an update if and when module 2 is released.

The Vampire Combat Video demonstrating new effects ....

Episode 17: Now Where Did I Put It?

What a fortnight of fixes and updates! For those following the module status, you will know that I have currently withdrawn v2.93 pending some final testing by my wife, which has helped bring my attention to a number of issues that I wanted to iron out. From the simple removal of some debug text to a rewrite of some core scripts. That's why the module has been withdrawn until I have this sorted. At the moment, my wife is replaying the campaign in "hard core" mode, where if a companion dies, then they are removed from the party and replaced by a tombstone. From there, the player must either raise the dead companion with the spell or take them to someone who can raise them. It's been during this play through I have been able to finally track down some of the old issues and even give a little bit of an update with containers. Read on for more information ...

CONTAINER FEEDBACK

Let me start with an interesting update. You may recall that I have feedback given on any recipe book a PC carries if they single left-click on it within their inventory. The code (which required a loop limitation fix) basically checks each of the individual recipe scrolls of the recipe book and gives the player basic info about every recipe the book carries without them having to open and check them individually. So now, as an extension of this idea, I decided to add a single left-click feedback to every container item the PC carries. i.e. Other containers will now (on a single left-click) give named feedback of each item within the container and how many of each there are. This saves the player having to hunt around, opening each bag looking for anything in particular. Now a chat message will simply give you the contents with a single click without having to open the container at all. (Check out this weeks screenshot to see how it looks in-game.)

HARD CORE DEATH SYSTEM

As I say above, the main hold up for v2.93 at the moment is final testing on the hard-core death system, which my wife is currently in the process of doing. So far, all has worked well with respect to companions dying and leaving tombstones since my latest rewrite of the death scripts. (I have now also made any tombstones sparkle gold to make it easier for the player to spot them.) Raising them either by spell or taking the body back to Orechin works fine. Initially there was a problem with odd duplicated items, but I changed the approach and now the system appears solid!

The last hurdle to overcome, which I believe I have now achieved was to ensure any plot items that a dead companion may have been carrying were transferred to the main PC upon the companion's death. This required a rewrite after I realised some players may have stashed an important plot item inside a container on the companion. This had also contributed towards the duplicated items issue mentioned above (with plot items), due to some plot items being left on the dead companion even after they had been transferred to the main PC. This has now been corrected too, and is the final part that requires further testing.

A slight update to the way the system works now, is that if a player chooses to abandon a fallen companion (option given when leaving the area and not picking up their body token), then items left at the tombstone will now still be left available to the player upon their return to it! The body token, however, that had been left on the tombstone will have been destroyed, meaning that companion is gone for good ... or bad. ;)

MODULE ONE UPDATED

The latest version of the campaign will also have an updated module one come out alongside the latest campaign files. This is because I went over a few of the areas that I felt needed their objects checked. Many of the areas had not been checked since their first design and I have learned a bit more about what works best since they first appeared. To this end I did things like remove oddly placed placeables (that were out of view), converted some placeables to environmental objects and removed scripts that were otherwise not being best employed. This included some heartbeat scripts that I felt may be costing more against overall performance than they were delivering in-game. e.g. Door heartbeat scripts simply to automatically close a door, even when not required. Hopefully, these alterations should go a long way to help overall performance for the player.

CAMPAIGN LATEST

So, v2.93 is sitting in the background, almost ready for release. Once again, many of the improvements that have gone into the latest campaign release have been driven by the need to get the scripting right for the addition of other modules moving forward. However, this also means I have been able to address quite a few annoying bugs that affect the first module. Example fixes ...

1. PLOT  STATUS: I discovered some plot items could accidentally lose their plot status in certain situations. Not good, but thankfully rare to never seen.

2. ENTRY SCRIPTS: I did a complete overhaul on these scripts due to the checks required for new modules, and then if SP or MP, and then if importing a PC, and then if starting afresh or coming from another module, and then if .... you get the idea I guess. In brief, I believe these scripts have been greatly improved, and I managed to tidy them up quite a bit. E.g. Before, if a player reloaded a game in a certain place, it would incorrectly assume they had just transitioned from somewhere else. Now a check is in place that stops all this kind of erroneous practice.

3. TB PAUSE COMBAT : I noticed a brief pause during my own testing when trying to unpause a TB combat round. I believe I have now removed this issue (which was rare anyway), and also tweaked the code to help the pause kick in on times when it appeared a bit reluctant to do so. Also removed GUI inhibitor to ensure combat GUI always showed when paused. Fixes here were minor and "cosmetic".

4. ITEM TRANSFER: Another nifty tool that I recommend all players to use is the right-click on an item within their inventory and use the Give To option to enable easy and fast transfer of items between their PCs. It really does make item transfer so much easier, especially alongside smaller portraits (if used). However, all this is also to point out that a minor fix was added to ensure container items did transfer on the first attempt. Previously, such items may have required more than one attempt to transfer successfully, even if told such anyway.

5. INVENTORY CLASS: A quick and simple cosmetic fix that ensured class names of a PC (as displayed within the inventory screen above the mannequin) fitted better and no longer had underscores in class names such as Spirit_Shaman > Spirit Shaman.

6. GOLD WEIGHT : An old problem that came back to haunt for a little while due to me missing an official gold script that was being used within conversations. Basically, I have to use my own gold transfer scripts rather than the official campaign ones due to the way gold works in my system.

And examples of campaign updates that module one also gains immediate benefit ...

1. REST/WAIT GUI: An improved rest/wait system that now works on direct button press (when options available) or cancel. Before a player had to potentially make a selection before confirming with OK. This was both confusing and potentially a backdoor to a rest exploit due to the cancel callback returning zero, which still means something other than cancel as it currently stood. This was required because some rest/wait options may not be available in The Scroll, meaning a proper cancel callback was required.

2. PARTY KEYS: Another small but quite useful update is the update that allows a door to be "unlocked" by any party member, as long as somebody in the party has the key required. Caveat: A PC with the Open Locks skill may still try to pick the lock first (if they do not have the key), but will immediately use any key present in the party thereafter.

3. PC SKILL BOOK: The PC skill book (which every PC receives at the start of the game) has had its look changed to help it stand out. It's a minor alteration, but I often confused it with any holy book a cleric may have been carrying too, so it just helps distinguish the book. (Of course, there is always the likelihood another book will clash in the future, but at least it will be less frequent.)

4. AUTO LIGHT : Players of The Scroll may be aware that a PC could auto-equip a light source if they entered an area that was effectively pitch black. This also used to auto enable low light or dark vision if the PC had the ability. Due to some difficulties, I decided to remove the auto-enabling of low light or dark vision, but ensured another light source was auto-equipped if the players controlled PC entered a dark area and had not got any potential low light or dark vision enabled. This is done as a check throughout the party the player controls, so if they do not have an alternative light source, but another member does, then they will auto-light the area. The code now also ensures any lantern equipped has fuel to burn so it is not quickly removed again.

Let Me Check This Container For It!

Episode 6: Having A Bad Were Day?

One of the advantages of starting a new module is being able to incorporate new ideas and concepts that are missing from the first designed module. One such idea I wanted to look at including was the Curse of Lycanthropy. For while the were creature has always been a staple from the first edition D&D, it has grown into quite the gaming element by the time it reached the third edition, which NWN2 is based upon. Sadly, although the OC appeared to include the concept of Lycanthropy in its world (and included such things as belladonna to defend against shapeshifters), the actual mechanics for a PC contracting the curse never appeared to make it into the game. That's where my latest additions come into play.

THE CURSE OF LYCANTHROPY

It is safe to say that there are quite a few interpretations of how the curse may be implemented within the game, but I like to take my lead from 3e/3.5e rules, which is quite well laid out at the D20 Resource Site. And while not every aspect of the information there may translate well for NWN2, I believe much of it can and have added the following mechanics:-

1) Any lycanthropic creature has a chance to infect a victim through its bite. (A bitten victim has a chance to save against the curse bite, and a paladin with Divine Health feat is immune.)

2) Once bitten, the victim does not know they are infected (or believe anyone telling them) unless they make another save after recovering from a transition. At which point, they gain the Change Shape feat that allows them to attempt a shape change at any time. Note, this is a chaotic and evil act, and good-aligned PCs would best avoid voluntary changes into the "beast within" or suffer class restrictions.

3) The affected PC will also involuntarily change into a were-creature on the night of a full moon (three of them in a month) or if they drop below a certain number of hit points while in combat. A PC does NOT suffer alignment changes due to involuntary changes. If the involuntary change takes place due to damage in combat, then they also suffer from "rampage confusion" until the combat is over. Fellow party members would be wise to give them a wide berth.

4) While the were-form may offer some advantages in strength and or overall constitution in a battle, the inability to access ones equipment or cast spells while in the were-form, should be a good enough incentive to try to rid themselves of the curse. That and the ever present threat of potentially killing a party member during a rampaging confusion moment of course.

5) Curing a PC from the Curse of Lycanthropy can come in a number of ways:-

• Cleric of at least 12th level with Heal or Remove Disease within 3 days of contracting it.
• Remove Curse during a full moon phase. (May take a number of attempts.)
• Use Belladonna within 3 days of curse, but reduced chance as time passes and attempts made.

Note, if the person administering the belladonna is a healer, their skills are added to the chance of curing the victim of the curse. Furthermore, belladonna is poisonous and would require further treatment to remove its own debilitating effects, even if it successfully removes the curse.

MECHANICS INVOLVED

Even though I may have veered off area design this week, the incorporation of such mechanics takes its own time to include, as I have had to write the scripts to work with the existing framework. Thankfully, I was able to use my spell hook script to work in the cure for the different spells, and even made the OC belladonna now have the ability to "cast" two different options: The original OC protection against shapeshifters ability, and now a second option of attempting to cure a person of lycanthropy when targeted by the user.

The hardest part was finding a place to include the Shape Change feat for the player to control for their PC, as the feat would "disable" if placed in a normal hotbar slot, due to the PC changing form. i.e. The feat would become greyed out when the PC transformed into a were-creature. This was unacceptable, as the player needed to have the option to click it while in beast form to voluntarily come out of the form (if they made the saves). Thankfully, the slots to the far right end of the hotbar (where the camera angles and the Althéa Main Menu are located) remain available at all times, irrespective of form, and so I was able to switch an existing (non-critical) statistics button into the Shape Change feat button all the while they had the curse. And although the button located this way does not show the "cool down" option (of five minutes between shape change attempts), I was able to add an On Mouse Enter callback that does a similar thing of displaying the time remaining as a notice text.

The various aspects also included changes to the spells and feat 2da files, as well as the TLK file, which holds the new feat texts. One of the most important changes affected the displays of the moon phases with the calendar GUI, which needed some subtle changes. Unfortunately, these changes mean the code is not going to work "properly" with older versions of the code, most likely because it does affect the timing. However, all version 2.70 and up will now have the correct code in place and be compatible with future updates. (Unless something critical ever pops up again of course.)

'WERE' TO FROM HERE?

The code now in place, I have done some basic testing, and all appears to work as expected so far. I just need to finish some belladonna item coding and the "cool down" feedback and that is done. Then all I need to do is place the were-creatures ready to infect their victims with a bite! Going forward, I intend to write a scenario based on were-creatures, and then, perhaps, maybe look into that other classic: Vampires! However, in the meanwhile, I hope to get back to area building in the weeks ahead.

Were Creature Gaming Aspects In Detail

MP Save Game Corruption Finally Resolved (v2.20 Available)

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!

DOWNLOAD v2.20 HERE: https://neverwintervault.org/project/nwn2/module/scroll

OTHER FIXES

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.

OTHER UPDATES

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.

The Adventure Continues .... 5. Freewill v Predestination. (Combat TMI)

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

The Heroes Return To The Bloated Buckle For A Night's Rest

The Adventure Continues ... 5. Freewill v Predestination

Did we choose to come here, or was it always meant to be?

NB: Contains spoilers for Option 1 background.

Tired as they were, the heroes were fascinated by the scriptures they found around the Sanctuary of Boran. They discovered four ancient texts that spoke of an old argument of the different religions that discussed whether one was in control of their own actions or had always been destined to carry them out. There were the Sovereignites who believed in predestination and the Kingdomites, who believed in freewill.

Shortly after musing over the topic of freewill versus predestination, Helden picked up yet more texts in a nearby bookcase. One spoke of the horrendous disease called The Scourge, which caused living beings to turn into what resembled the undead. The second book went into details about a substance called the Life Essence and discussed the nature of good and evil. It was yet another fascinating read and one that nearly caused division in the party, had not Threska decided that the rest of the party may be right after all, and determined to take on board a change of religion. A rare thing indeed to witness such a change of heart in a person. The heroes decided they would aim to be Channelers, an action that asserted goodness in nature. However, in the light of what they had just been reading regarding freewill versus predestination, there was more than one hero that paused just a moment to consider whether it really was their choice or something predestined?

It was approaching midnight by the time the heroes decided to return to the Bloated Buckle and turn in for the night. The group were already quite fatigued, and Orechin, who had already locked up the sanctuary for the night, had to unlock the door before seeing them out. (See item 2 fix above.)

As the heroes made their way to the inn, they heard a scream. It was a blood-curdling sound that sent their hearts racing, and they paused briefly deciding whether to investigate it or not. After all, they were truly tired and did not want to run the risk of falling foul of night crime while in such a state. Then a voice in their conscience alerted them to the fact that they were supposed to be the heroes, and maybe it was their place to investigate. Clearly, it sounded like somebody was in need of help. So, they made the decision to run towards the scene. They arrived just at the same time as one of the guards turned up and all witnessed that a male figure had been murdered! 

Helden was a little hesitant to get involved and wanted to get back to the inn, but Myara was curious and wanted to investigate a bit more. She examined the body and found a picture of a woman on it. The guard quizzed Myara about it, but said they could hang onto it if they would try to do a bit more investigating, and report back to Taloy or Orechin on their findings. The heroes agreed.

Eventually, the heroes did make it back to the inn, and Myara wasted no time in quizzing both Karl and Sandy about the girl in the picture. Karl had not recalled seeing her (after a little persuasion to talk about it), while Sandy was reasonably certain it was Sophie, the daughter of Kathy, the trader at the Apothecary. She said to check with Taloy, which when they did, appeared to confirm this was quite possible. However, Taloy was reluctant to speak about her due to the way she had only recently died herself under suspicious circumstances. He recommended that they speak with Orechin, as he dealt with her death.

So, as the heroes turned in for another night at the local inn, they had managed to gather more tasks under their belt. And as the heroes settled down for the night, Myara's thoughts went to solving the murder mystery, Karasten wondered more about the Arcaene Lore spells he had read about in the book that the heroes bought from Orechin, Helden considered and imagined himself taking up a little crafting, and Elana thought long and hard about whether she was making the decisions in her life ... or whether somebody else really was controlling her actions. In all, every party member had their own reason to start afresh the next day ... as long as their thoughts did not distract them from sleeping.

TOTAL SESSION TIME (UNPAUSED): 1 Hrs 37 Minutes. (Late start.)
QUESTS ACTIVE: 17 QUESTS COMPLETE: 1 (Ignoring Rule Info)

There were also a couple of questions raised about the mechanics, which I will answer for the record here too:-

1) When Do Henchmen Level? Henchmen level at a rate of a level or two behind the PC they follow.

2) What About the Level of Late Comers? If a companion or henchman is asked to leave the party: at the next time they are asked to join, they will level (gain experience) to a comparable level to the party average. The player can then level that character if required.

3) Automatic Storage of Keys: Every player in a MP game can own a key ring. The same is true of any auto-storage item. (Auto-storage items place items they carry automatically in them when acquired. E.g. If a player has one of their PCs pick up a key and any one of their PCs owns a key ring, the key will automatically be placed into the key ring item.) Note, however, items passed from player to player are NOT automatically placed into such containers and must be done so manually.

Sandy Speaks To the Heroes About Sophie, The Girl In The Picture