Episode 82: March Big Update!

If you have been following of late, you will have seen that The Scroll campaign has currently been withdrawn from downloading. Basically, I had to make some big decisions about where the campaign was heading with module two on the horizon, and how I was going to manage multiple modules moving forward. I concluded that I needed to make some big changes to some of the core files for the campaign and so rather than prolong the agony, I took the steps required. Hopefully, I will have the latest version of the campaign ready to download by the end of the month. It's still only the first module at this stage, but even that will come with a grand facelift with the changes made. Read on to hear about the big changes I have made ...

The Enhanced Is Dead! Long Live The New!

To mark these big changes, I made the decision to end the "Enhanced" version series of the campaign, and replace it with a new straightforward version system. (The enhancements will remain, of course, it's just the version tag that will be going.) Importantly, the new version system is now no longer limited to 100 iterations before having to move up its first digit. Now, it allows thousands of increments, allowing me to keep the primary digit to relate to the current module release. Therefore, I will start at v1.1, where the first digit before the period represents the modules currently available and supported, and the digit after the period is the campaign version release. When module two is released, for example, it may go to v2.162, if we are on the 162nd version of campaign updates by then.

This has also allowed me to start afresh with "backward compatibility" support, which the current version series had been covering games as far back as v1.50E (March 2022). A lot has changed in the last two years, alongside many fixes, and I believe the enhancements made are now in a far better place than when first released, and so I feel happy about starting the release version anew. This new series will only be guaranteed backward compatible with v1.41E and up to v2.60E, the last release number of the Enhanced edition. (Older versions will have varying results.) That said, this latest v1.1 does come with some module improvements too. They are minor and have less of an impact, but the cleanest experience would be starting afresh from v1.1.

Now, let me cover some of the major changes coming in v1.1, and how module two made an impact.

Even The Start Screens Have Been Updated!

DM Client Support Removed

When I first designed the campaign, I thought there would be a need for me (and others who played the campaign in a coop multiplayer style) to have to "do stuff" as the players made progress. The idea being that I could still play in the same fashion as we, as pen and paper players, had done in the past. However, the beauty of being able to script events meant that my role actually became less as a DM, whose only role was more about in-game fixing if need be. The monster AI was working well for our needs, and all I ended up doing was following the heroes around as an invisible side-kick. Put simply, the module design had no need for a DM. 

In fact, the campaign design has changed so much over the years since its first incarnation, that certain events, such as area transitions, are actually hampered by the presence of a DM. Trying to accommodate the presence of a DM, especially with the up and coming module two, that comes with more advanced events, became such a burden that I could not see any reason to continue to support the DM Client system. Instead, I decided to concentrate on making coop multiplayer a much more stable and protected way of playing. Once I pulled out the DM client code, I was able to improve the efficiency and stability of player clients joining the host's game. Furthermore, I added a number of "safety checks" to help players setup their game without running into connection issues due to joining timing errors.

Moving forward, I realised that I, (who once played as the DM), can now, instead, share their gaming experience by playing alongside them as a PC of the party too. I also recognised that it was easy enough to add a DM tool if I ever wanted to reacquire some of those gaming elements that the client once provided.

A final great benefit to this change was that it helped alleviate the multiplayer area transition times, which I appreciate, especially as module two comes with one or two slightly more involved areas than the first module. However, on the subject of loading times, it was the next update/fix that really helped here.

Database Handling Improved

I have had an "unknown" issue with the module sometimes crashing upon entering the second area after a module fresh start. This never happened on my computer, but always did on my wife's. I knew it had been related to the database somehow, but only recently did I figure out the problem. It seems that the game does not like to "destroy" a database and set one up shortly after, especially if using the same name. It turned out that somehow, this action upset the game, which then went on to cause the game to randomly crash on some computers. The solution was to, rather than destroy an existing database, to simply "reset" all the variables it contained by overwriting any existing. The end result amounts to the same as destroying and creating a new one, but the process does not cause the game to crash shortly afterwards. I was greatly relieved to have this issue (ever since first release) finally resolved.

UPDATE: The game WILL still crash shortly after the first time a new database is written. However, as the new database only happens at the start of the game, a player is encouraged to reload the auto-save made at the start of the game to prevent the risk of a crash. If the player is updating an existing database, then the game does not crash.

On the back of solving this issue, I looked closer at the way the database was handling data, and concluded that some of its operations were not required for multiplayer gaming, and so switched their operations off for such. It turned out this helped improve area transitions by a significant amount; around 3-8% for multiplayer gaming. The bottom line, when module two is finally out, it will be working from a fixed database system.

Fast Travel System Overhaul

I'm not sure how many people are aware of this system I implemented, but it's one that can be put to good use when it comes to moving around the World of Althéa. Whether your PC is encumbered or not, if you have a valid waypoint available (and you can set your own too), you can use the system to move rapidly to the waypoint you choose. No more slowly dragging your party back to a location to do something, as it's as simple as left-clicking on the map and selecting the way point to move to. It's the closest thing I can achieve to the likes of clicking on a map and have the party to move rapidly to that location.

There were some teething issues with the initial system, as sometimes the PC could be left in an unusually fast speed even after the fast travel had finished. However, I am hoping they have all been sorted now. If any others are discovered, they should be reasonably straightforward to fix now too.

However, one of the things I have wanted to address with it for some time now, was to incorporate the Fast Travel GUI into the area map GUI itself. The system prior this latest would open a second GUI that opened somewhere else on the screen, from which the player made their selection. However, this latest version now keeps the Map Pin selection incorporated into the Area Map GUI itself, making the whole system feel more natural and intuitive. Take a look at the image below. A player need only left click on the area map to bring out (or close) the list of waypoints, and then select a waypoint to move rapidly to it. The player can leave the pop-in panel open if they wish to (in case they change the current waypoint in mind), of left click on the area map again to close this pop-in to watch their PC icons move rapidly across the map to the waypoint in question. To cancel any rapid movement, the player simply closes the area map, either by clicking on the area map exit cross, or pressing escape. The rapid movement has been designed to auto-stop if required, such as a conversation starting, or combat encountered. Basically, play is unaffected apart from the speed at which the party moves to the selected location.

Area Map With Fast Travel Pop-In Open

Persistent Skill Bonus Fix

For some time now, as long as the Adventure Skills system has been in place, a bug has been lurking in plain sight, basically going unnoticed. Thankfully, its impact has been relatively "minor", albeit frustratingly unfair when required by the PC. The problem is associated with Skill Bonuses gained by items that sit in a PCs inventory, which fail to reinitiate their bonuses on a game reload if they had been stowed away in a container the PC carried, such as a Bounty Bag. As PCs had the potential to gain campaign feats that awarded such Skill Bonuses, which were then stowed in their Adventuring Skills Book, then it meant any such benefits would have disappeared on a reload, and likely gone unnoticed.

Addressing this particular bug has been one of the issues that has contributed to the longer delay of the campaign's next release.I wanted to make sure this bug was also made backward compatible, alongside the other final list of bug fixes for the Enhanced version releases. The upside to this latest fix, is that some good has come from it, in that I have improved the operation of party feats that can be acquired in the campaign, as well as fix the Skill Bonus container issue.

First and foremost, new campaign feats now alter skills in a permanent manner. They no longer rely on Adventure Skill pages. I could have still done it this way, but now wanted to reserve the Adventure Skills book to bonuses from items carried by the PC only. So, campaign feats with skill bonuses are handled via script rather than items, and are permanent alterations either way. The new fun changes come with the skill bonuses that are benefitted from items that sit in a PCs inventory. For now, the Adventure Skills Book keeps an overview of all the benefits gained from such items, and is the item that ensures these benefits are not lost between reloads. Importantly, these skill bonus items can now be stowed away in containers and their benefits will no longer be lost between reloads!

Now, whenever a PC acquires a skill bonus item that sits in their inventory to gain the benefit (as opposed to an item that can be equipped for such), the Adventure Skill Book tracks the benefit by adding it to its own list of beneficial skill properties, as well as keeping a page copy of the real benefitting item within its contents. So, if a player wanted to see what benefits they were gaining from items in their inventory, they need only check the Adventure Skills Book properties for a full list. If they wanted a breakdown of which items were providing these benefits, then they need only open the Adventure Skills Book and examine each page therein to learn where the benefit is coming from. This new approach actually gives the Adventure Skills Book a more active role for feedback in the game than previously. Take a look at the image below for a quick overview of the kind of thing I am talking about here.

• 1 - 3: These are the three real items collected by the PC that are giving them skill bonuses.
• 4: The Adventure Skills Book (ASB), the current description is up and showing all benefits.
• 5: The ASB contents. Each page can be clicked to see its own description instead of the ASB.
  

The New Adventure Skills Book Information

There's A Lot More!

The above differences are just some of the bigger ones that impact the campaign and module two moving forward. However, there are also a lot of other fixes and updates coming to address some niggly problems and gameplay from previous versions. From logical flow issues, combat activation (including auto-pause), creature issues, launder bench usage to name just a few. Take a look at the full list here.

TLK & UI Updated!

With all these updates, and being a NEW version, starting from v1.1, there will also come new TLK and UI folders that will need to replace any existing Althéa versions that you have. If starting afresh, you will also need to grab the latest module folder, which now also starts to be noted by release date rather than version number release. This is done to help prevent players downloading a newer module than campaign in error, which can lead to a broken game. There is also additional file checks in the new code to help prevent this, and a "silent" version number will be kept with any module upload to help maintain this. As far as the player is concerned though, the release date for the module folder should be the governing guideline for them now as to whether there is anything significant about its changes that affects them.

I recognise that this month's blog is a lot to take in, but I wanted to let you all know that I have been busy preparing the campaign for the second module, and this is the result. My wife is currently play-testing all these changes, and still helping to find any remaining bugs that can be fixed prior release, and as soon as she is done, I'll upload for all to benefit from.

Episode 73: Upping The Ante!

With a new module comes new challenges... It's a time to "up the ante", and to introduce new monsters and puzzles for the party of heroes to face and overcome. However, creating such new challenges for the player's band of heroes also translates into creating new obstacles for the builder to overcome. Let me explain ...

New Monsters!

It is said that there is actually "nothing new under the sun" (Ecclesiastes 1:9 KJV), which is something I happen to agree with. However, for each of us, there are certainly new things to experience, even if it has been around before in one format or another. I mean I believe it is safe to say that most of us know what a vampire is, and what to expect it to be like, but... It's true to say that not all vampires (and any creature for that matter) fall from the same mould. Yet, it is these small variations in the monster template that can make the encounter a bit more "exciting", or perhaps I should say "dangerous", upon encountering one such creature in a new campaign world.

This is because not every builder will include certain aspects of a creature's design in their specific version of the creature in question. Sometimes this is due to the limitations of the NWN game engine that we use, or more likely most of the time, due to lack of time to script in all those lovely AI updates we could employ for the various creatures. That said, when we have been able to add a slight nuance to a creature that may not have been experienced before, it can add another level of depth to the module being played in question. Therefore, with this in mind, I hope, on the odd occasion, to add just a little bit more to any new creatures encountered in module two. Let me be clear on this matter, it will only be the odd one or two, as some creature variants can be quite complex. One such creature to have undergone such treatment is in this week's screenshot (see below).

My normal approach when dealing with this sort of thing, is to gather as much information about the creature I have in mind to use as possible, and then create a version that supports as many of its known features as possible. This is where the "ante" builds up for me, as even adding just one unique property for a creature takes time. If a creature has two or three properties that differ from the original template provided, then it takes me longer to include them in the final build. The end result, however, is a more rounded adversary, which, I hope, will also "up the ante" for their encounter. Whether players will thank me for that, I'm not so sure. I guess time will tell.

New Puzzles!

I've reported on these before, but I would like to touch on them again. For The Althéa Campaign, puzzles range from simple mini-games to more complex situational puzzles. Those that have played my first module will be quite familiar with the mini-puzzles I refer to, and so hopefully, will feel quite a home with the new variants that come with Predestinated Days, my second module. These sorts of puzzles can occur multiple times through the adventure, and can normally be solved in various ways. That said, I am making a concerted effort with this second module to expand on the more elaborate situational puzzles.

Again, players of my first module will be familiar with the sort of thing I mean. However, when it comes to these "situational" puzzles, I have decided to try to "up the ante" in these too. By "situational" puzzle, I mean those that PCs can encounter in an area rather than on any one specific object. I consider them multi-object puzzles, which a player may need to take notes on, or, more importantly, consider a bigger picture when working with them. One such example from module one, was repairing the sewer units. Here, the player had to understand a process and consider the long term goal or what it was they were trying to achieve. It is this kind of "puzzle" or "task" I hope to take to a new level of interest or, from my perspective, presentation. It's currently an idea in progress, but I already have a couple of these task-like puzzles in place, and I think they play quite well ... I just hope players think the same.

More Challenging!

Basically, as to be expected for an experienced party, I guess, the next module is aiming to be more of a challenge for both the heroes and by default, the player too. That said, I aim to try to include the normal alternative ways of playing in place, to allow players a different approach if they struggle to progress, even if it means altering the game difficulty setting, or a frugal use of Life Essences at the right time.

Perhaps A Little Too Challenging, Alone?

Episode 58: Rotation Matching Puzzles

Time has flown past since my last report, and so I thought another quick update was due. Recently, I have found myself making use of the extremely powerful tool MDBConfig by rjshae. Basically, I have needed certain placeable objects slightly altered for my own needs, and this has been a really excellent tool to help me with the process. Read on to hear what I have done lately ...

Rotating Puzzles

As many of my regular readers will know, I enjoy interesting puzzles in my D&D games, and so I suppose it's obvious I wanted to include them in my own module. The first module comes with around half a dozen puzzles already and you may recall reading I have some new designs coming along in module two. However, I finally decided to also include some I had in mind that work by "moving objects". Think either the mirror puzzle in MotB or like those found in Skyrim.

In this case, I wanted to add puzzles where the player may discover a specific sequence, which can then be applied to a set of rotating objects to unlock a path to somewhere else. Thankfully, NWN2 already has some code related to this, but I adapted it (made clearer) to suit my own needs. I still need to add the code to check the sequence and return a result of some kind, but that should be the "easier" part for me. In my case, it was making the placeable objects I needed to be able to provide the clues and for the player to interact with in the first place that was the hardest. Check out this weeks screenshot from the toolset showing my latest puzzle object additions. I hope to make use of these in the second module moving forward.

Growing Conversations

This stage of module building is otherwise being taken up with writing the conversations ... again. One of the largest ones is growing close to 10,000 words! This conversation is not even finished! I would like to point out that this amount of words is not about a large text dump, but due to multiple paths through the conversation subject to player PC choices and situation ability rolls, or character trait. Furthermore, in this particular conversation, the text is also affected by the player's background, which continues from module one (if played), or of that chosen at the start of module two.

Multiple Paths

On the theme of multiple paths, I wanted to report that I have also been coding a new means the PCs can travel, which led to a potential logical flow issue where the player could approach the same quest from multiple angles. Don't get too excited, it's not full blown flying, nor animated swimming, (or anything like that), but is a new approach which will allow the player to choose a different travel path. The point is, however, is that this new means of potential travel involved quite a bit of planning on my part, and only now do I think I have covered all the angles.

For me, allowing the player to be able to approach a problem from more than one "literal" path (as well as a skill path) is what will tempt players to play the module more than once to see how it played via a different approach. i.e. Think pen and paper where players may discuss which way to approach the game before declaring their actions to the DM ... I hope to pull off a similar approach in this module too. It does require triple checking things, which all adds time, but I am pleased with the results to date.

That said, I don't want to put players off, by suggesting the module appeared too "open world". Far from it! Like module one, the second module follows a very clear cut main quest, but also leads the player to explore other areas they may also find interesting ... with some areas seemingly more involved with the main plot than others may first appear to offer.

Continued Testing

Finally, just a quick update to say module one is going through another final SP testing after I decided to make some more changes to the code. It was mostly to do with the container code again and improvements to the way items are collected. As soon as my wife has finished this play through, the latest version 1.50E of module 1 will be uploaded.

Elemental My Dear Friend!

Episode 57: From Paper To Computer!

I have to confess that while I have done a reasonable amount of coding since I last reported, it's still hard for me to say exactly what I have done that will sound exciting to you, as the reader. That's the reason I have not posted anything earlier this year. However, I do have some information, so treat this post as a general update with a couple of screenshots thrown in rather than anything with much specific detail. Read on ...

And Yet Still More Areas

Even though I said there was not much to report, I can quickly add that I recently added three new areas (all interiors). One was a rehash of an official campaign area, which I believe I have altered enough to give it a fresh feel. The NPCs encountered and the objects to be found there are obviously new. The other two areas are being built afresh, as their design demands it. I knew these areas were needed, but I only started them a week ago and they still have quite a bit of work to do. These are all areas I need for the conversion of my PnP scenario I wrote about three decades ago!

The PnP Conversion

I am starting to realise that there are both pros and cons when converting an old PnP scenario into an adventure in NWN2. PROS: The plot is already written and comes with map designs, encounters and gameplay ideas all ready to implement. CONS: Making the design match the original with the toolset is difficult. Also, in my case, my old notes are verbose (I wrote more back in PnP days), and they require "tightening" for the new medium. Puzzles from the PnP have to be coded into NWN2 script and XML, and "paper handouts" need to be converted to "readable" books and scrolls in the module.

This PnP scenario currently being translated into a NWN2 module is called Bloodstone College and is one of three I am converting from my original PnP material. This one is by far the largest of the three, and requires the most work. For instance, I have managed to incorporate most of the material of the other two scenarios into the second module already (with some final scripts to finish off), but this one is complex enough that it could stand alone as a separate module. For those who have played my first module, I would say it is as complex as The Halls of the Goblin Kings. That is, the quest should last a few gaming sessions alone, but should be rewarding for the player who enjoys a mystery involving undead. Now I've said too much already!

Code Improvements

I know this is an ongoing exercise for me as I write the second module, but I still think it's worth reporting to potential players. For instance, improvements to old code this time around has included, automatons and containers. Automaton code: This now works more efficiently alongside the core monster AI code, after I managed to remove the need to recreate the automatons. Basically, as I have understood NWN script more, so the old code is fixed to work more efficiently. Container code: This is an interesting development (at least as I see it), because I was finally able to remove the area of official code that spammed the window upon acquiring a new item. Due to the way I allocated items to special containers, a broken NWN function duplicated "acquired new item" when it was not meant to. In the past, I just put up with this and minimised it wherever possible. However, recently, I finally worked out how I could bypass the official function in one area of the code and bypass the broken function in another area, thereby removing all references to acquiring an item. It involved an XML edit, and writing a new callback, but the end result is that I now control when the player is told they have received a new item. UPDATE: Changed again to use existing xml and new function.

Module 1 v1.50E Coming Soon!

As a final comment for this post, I can report that the latest v1.50E version of module one is in last stages of SP testing. MP testing is already completed, and load times improved. The final testing stages are also making sure all the latest gameplay updates reported in the last few posts are working without any glitches. I am particularly pleased with the combined results of the latest journal/task update alongside the container update (mentioned above), which now means chat window text spamming has been totally eliminated. This latest version also benefits from all the other updates reported in previous posts, including the "fast map travel" and the "enemy counter", as well as the new task GUI and new container code. Add that to a couple of improved area designs (made larger in places) and a general overall improvement to area designs for load times efficiency and v1.50E should be something special and definitely prepares the way for module two!

Now the two screenshots ... The first is one my wife wanted me to include (which she found amusing) showing a combat she had in the first module where one of her party was enlarged and was fighting next to her other much smaller halfling. The second is a screenshot from module two showing a new banner I managed to include.

The Little & Large Show!

The Sanctuary of Narmor (Night Sun)!

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 55: The Snowball Effect

It seems to be a repeating theme of late: I have an idea for module two, which then snowballs into a campaign idea that I want to make available for module one too. This obviously refers to the game mechanics than any new plot device, but the point is, it ends up taking me longer than I first realise. Read on for the latest month's updates.

Efficiency & Polish

The problem is, whenever I see an issue with the existing code, no matter how small, I prefer to try to do something about it rather than let it ride. Sure, I could let it go and try to concentrate on new plot only, but when I then try to implement new material, it can then reveal the weaknesses of areas of the code that can do with an overhaul. This is what happened when I tried to play a MP game of my module. Some of the areas were taking too long to load and some conversations went awry. This forced me to redesign some of the areas and rework conversations, but the efficiency of area load times or logical flow were not the only things I felt obliged to address.

The Journal Tasks

The above issues aside, lately I have also found myself irritated by some journal notes spamming the window on an update. I knew exactly what was causing it: Sometimes my journal entries update information pertaining to items required for a specific task. For example, when collecting the prayer rods in module one, the journal title also updates with the number of rods collected for ease of reference. However, to do this, I have to remove the journal entry each time before I can update the TOKEN that refers to the new quantity information. The result is a journal update double spam to the chat window. So, I could either remove this additional information, or, as I decided to do, add a new TASK menu list. (See this weeks screen shot from the new module two below.)

Outside The Toothrot Tavern Showing The New (Empty) Task List

The idea is this new small Task List GUI window will now list all tasks that involve item collections for quick reference, rather than keep the information with the journal entry. The player has the option to open or close this Task List GUI as they like by a simple left click on a new small button. Furthermore, I added a simple right-click option to the same button for the player to change the background of the task list from this default shown in the image, to have a black smudge behind the text or just plain text list without any background. The button also highlights when a task list is available. It all works well, and now allows me to remove extra tokens used within the journal entries and avoid journal update spam messages. Sadly, it does not allow me to remove every TOKEN reference, and so some double entries will remain, but hopefully, they will be far fewer. I still have a little work left to finalize the Task List GUI, but hopefully will have that done by the next post. (i.e. Rewrite the code to update the GUI text rather than journal TOKENS.)

The Journal Updates

As I worked on the new task list GUI, I also looked at the way journal entries were delivered in general, looking at rewriting the system to improve its delivery. I have always liked the way games like The Witcher have presented them and so looked at designing a similar system. Shortly after this, Andgalf (at the Vault forums) posted a link to a similar idea I was working on, and this cemented my desire to polish this area of the campaign. The following image shows the new journal update style.

Opening Scene Showing New Journal Format

Other Game Mechanics

The journal was not the only area where I updated and polished the code this month. Other areas include:

(i) The inventory, where further improvements have been made to help alleviate a rare issue where a player may flick quickly between new items and confuse an item description. Now, clicking on an item will always update the description (unless paused). 

(ii) The action queue GUI has had its queue size increased, and for those that even want to stop their Main PC from retaliating when attacked, the small sword now acts as a button to toggle auto-retaliation on or off. WARNING: Unless you really want to, keep this on its default value to retaliate.

(iii) The Show Info GUI has undergone additional updates and polish, as well as the new Task List GUI button. It now also has another Broadcast command added: Attack Nearest. Like its two complementary broadcast buttons (Follow and Stand Ground), it removes the need for the player to do multiple clicks to reach the command buried in a right-click menu.

(iv) The follow AI logic has been improved, or corrected, depending upon your point of view. In particular, associates are now more correctly associated with their masters, but without compromising the overall Main PC orders where possible.

(v) Faster PC movement has been implemented from an area map (if the map can be opened in the first place). It has been improved to include keeping encumbered PCs up with the accelerated movement rates. Think open map and click on it to fast travel PCs to a point on the map. The only difference is that when the area map is clicked, a GUI with a list of waypoints is presented for the player to select the destination. NB: The player can add their own waypoints at their current location.

(vi) A door had to be fixed because it was missing a collision skeleton. My thanks to rjshae (at the Vault forums) for the fix! NB: This means the large hak had to be updated and will also require downloading again when I update the new v1.50E version of it.

(vii) Removed the ugly "chat" option from the menu presented when right-clicking in an area. Added new options for individual and group options for "Rally" (jumps controlled PCs to your side) and "AI" (to toggle AI on or off), alongside the existing portrait double right-click or brain icon options.

Showing New Right-Click Menus

The Final Snowball

The end result of all these updates and changes is that they have an impact on the way "libraries" of code are structured for the campaign. Functions that once worked in one library had to be move to another and recompiled to prevent any sort of conflicts from occurring. One library ended up being removed completely and amalgamated with another! This level of knock on effect means, as I have already stated, that previous module versions will NOT be compatible with the next release (v1.50E). However, players of the next version (onwards) will benefit from all these gaming improvements. Once MP and SP testing of these changes is complete, the new files will be uploaded for download. CAVEAT: You will be able to load a FINAL SAVE from any previous game you may have played. However, make sure the save is located in New Edgeton from where you can continue your adventure where you have the option to continue to module two.

Module Two

All these updates and changes are, of course, in anticipation of module two adventures that I am working on. The new adventures require specific conditions, which started the whole mishmash of changes ready for the player feedback. The end result, however, is that the campaign (all modules) once again all benefit (and are more polished) for it.

As for module two plot, it continues to have conversations written and journal entries updated, but of those, I cannot speak ..... ;)

Episode 49: Traditionally Different. (PnP Conversion.)

It always seems to happen: Just when I think I have all the areas I need, or think I know what remains, another area requirement arises! It all started when I was looking at adding a couple of small scenarios to do with a city the PCs will find themselves travelling to. I had my core storyline ready, but the city was not quite spacious enough to cater for the two old PnP conversions I wanted to add. Read on below ...

Pen and Paper (PnP) Conversions

I have some PnP modules that I wrote over 20 years ago, which I have always wanted to preserve by including them in my NWN2 campaign. Strictly speaking, these modules have already been "played" in the timeline where the player can first encounter my campaign in NWN, but because these modules are so far in the past for the campaign (and especially my players' memories), I can add a little poetic licence and repurpose them in this latest module. The modules original location, (the city of Southstrong), and plots (one an undead mystery and another a murder case) will remain relatively unchanged, but will be modernized to be included within NWN2. 

To this end, I recognised that I needed to add another outside area. To save time I managed to find an official  NWN2 area that with some tweaking fitted my purposes well. (I will keep it secret and see if anyone recognises it at the time.) A couple of this weeks screenshots show some of the new parts. Of course, the issue now, however, is that now that I have made a new outdoor area, it's going to require some new interiors too. I reckon it will be worth the extra time though! It's been great reading over old notes and trying to see how I can integrate them into the module with improvements. Most of all, I hope they will be fun for a new and larger audience too.

Reworked Scripts

As I am currently working with city environments, it means I have been able to take another look at some of my very earliest scripts that are used when players interact with NPCs that duplicate some of the things I have already coded. Again, I find myself improving some of these old scripts to be able to better cater for the gaming environment. A simple example is when catering for a bard who may wish to perform at a tavern to earn a few gold coins. In my first module, the player had to manually switch between PCs to reach the bard to make the request to perform. Now, as long as the player has a bard in the party, the option will become available. This appears a minor detail, but has a knock-on effect, as it means I can now use a cutscene conversation style with the conversation in question, which in turn, means I can switch from a MP cutscene to a SP one seamlessly. This is a great improvement to the conversation style that helps accommodate both a SP and MP environment when a conversation needs to be seen by all players, but only for some aspects of that conversation.

New Objects

To go along with the new areas, I have also found myself designing new signs and notices, based upon great work already in the community, including that done by RDS and Topoun. The signs and notices are my first steps towards my PnP conversion. So, alongside new NPCs and areas, replete with their own new adventures, all I can really say without giving too much away at this stage, is that I have (at last) started to fill a large section that fell between two sections I had already made large headways into. Admittedly, I still have many areas that have been started with work remaining, but completely untouched areas are becoming fewer, and the plot lines are starting to bind together at last. It is a satisfying feeling and one that arguably suggests the beginning of the end is in sight. But, I don't want to get ahead of myself, as there is still much left to do. I just wanted to share my latest projection with you.

Bloodstone College

Something Has Broken Out!

Southstrong Market -  Demonstrating NPC Detection Facility

Episode 41: Moving Forward?

As I write this, a hammer drill echoes through the house as workmen sort an issue for my wife and I. Furthermore, this noise and distraction may last some time, meaning all production of the module will be compromised. Don't worry, once the house work is complete, I hope to regain my pace, but for now, progress may be slower, and this will also be reflected in fewer blogs until things are back to normal. Read on for latest ...

Latest Area

Recently, I have been writing conversations which handle a number of key quests surrounding a location, which the players will encounter nearer the end of the module. I have now sorted much of the initial stages of these quests, but am now working on one of the areas where the action takes place. Progress is slow, simply because I find area design difficult. Also, I have the added consideration of balancing some new game mechanics that take place in this area. It's hard to explain exactly what I mean, but this part of the module plays with some added game mechanics, which require careful application while designing the areas that use them. It all takes time.

The Journal Notes

Another gaming aspect I have been making good use of of late is my Journal Note System, which I first wrote about around this time last year. It has become a very useful tool, not only to help give players a gentle reminder of certain gaming points, but is also useful when keeping track of what players should know at any given time. It acts as a dynamic notebook, with updated notes that players may or may not act upon, but also allows me to observe different variable states that these journal notes may represent. As an example, a player may have a conversation with an NPC and learn of a clue about something the NPC mentions. This will update the journal note system, allowing the player to refer to it, to remind them of some useful piece of information, without incrementing a quest stage. It is also useful for me to observe in testing various variables.

There is not much else to report at this stage, and so leave you with another screenshot from the area I am working on. It may be a little while before I write Episode 42, but hopefully, by the time I do, I will have more to report.

 

Unusual Objects!

Episode 31: The Plot Thickens!

I continue to write more material for module two as time and health permits, and am still applying the odd small fix to module one as I receive feedback from a couple of players currently playing it. For the record, I have just uploaded v1.27E (2nd Edition), which updates my new Animal Companion system to ensure the Animal Companions of companions are also handled by the new system as well as any belonging to a Main PC. I have also made a couple of minor GUI changes. Read on ...

Companions' Animal Companions

This was a quick update to the campaign to take into account a couple of things: (1) If the player had companions that had Animal Companions and (2) If the player had the behaviour setup to allow their companions to summon them automatically. It's a minor change, as previously, the default code was used for when companions did this (automatically), which meant nothing had altered. However, as a player may have more than one PC that could have animal companions, this update now makes sure each named Animal Companion is recorded with its associated master rather than just assume the player only changed the names of their own animal companions. It's an important update for those that have more than one PC that can summon Animal Companions, and like to rename them all for all.

Campaign GUI Updates

After some player feedback, I also updated two GUIs:

LOOT CONTAINER GUI: Previously, left clicking on an item within a loot pile (other than gold) would bring up the current PCs inventory and display the clicked item's examined information in the inventory GUI for the player to read about. However, this could become annoying if the player was trying to pick up individual items from a loot pile, which would force open the inventory even if they had no intention of reading the examine info for the item. So now, the inventory only opens and gives an items examine information if the player right-clicks on the loot item text within the container. If the player decided to right-click on the loot item image icon instead, they will now get both the inventory description and a second GUI offering to transfer the selected loot item to a different PC. This allows immediate distribution to another PC without having to go via the PC doing the looting.

SPELL SCROLL INFO GUI: Previously, subject to one of its two settings in the Althéa Main menu, this small scroll would pop-up with spell duration remaining information for the PC that had spells remaining of them, either (1) If the player possessed the PC on whom the duration spell was cast, or (2) If automatic pop-up was selected for the PC, then whenever the player possessed this PC, it would automatically pop-up if they had any durations spells information remaining on them. By request, I have now added a third state toggle that completely disables any scroll GUI, even if a duration spell is cast upon the PC being possessed. So now, the new "NEVER SHOW" toggle state will prevent any information popping up at any time.

Module Two: More Plot!

As far as module two is concerned, I have simply been writing more conversations. In particular at the moment, companion responses at certain trigger points. These are more involved than they might first sound, as I use my own system to do a number of checks before they start with respect to (a) if there is a specific PC in the party, or (b) if there is a particular PC type in the party, or (c) if we are simply using a default comment or (d) sometimes even if the PC is alone. The system ensures it gives the most intelligent response a party companion can give subject to who is in the party, whether the player has had companions join them from the module, or if they created their own party! i.e. It is particularly flexible and "intelligent" enough to cater for almost any party combination, but, as a consequence, does require more preparation in the conversation responses available.

I am also still in the section that requires me to have to comment or prepare feedback for both conversation and quest stages according to whether the player has selected background one or two at the start of the campaign. Hopefully, it won't be much longer before I can put this difference aside, as the two background choices eventually come together.

Module Two: More Books & Scrolls!

Alongside the conversations, I have been putting together more readable scrolls and books; the types where clicking on a placeable book or scroll (or sometimes activating a book or scroll item) will provide the player with an actual full view of the styled text inside a scroll or book GUI rather than the basic examine text. Without doubt, this offers some great immersion, and is something I hope to fully utilize in module two and moving forward.

Module two is where players who don't know about the main story will learn much about the background of the main plot, which my PnP (D&D pen and paper) players already know. Of course, all players will be able to view these texts, the new player for the first time, and my PnP players in a new light - and in game rather than as a hand-out as in times past.

The Heroes Locate An Important Library!

Episode 23: Most Puzzling My Dear Halfling ...

One of the things I like most about D&D as a whole is its variety of play. We have exploration, we have encounters, we have combat ... and we have puzzles! Furthermore, NWN2 is a great platform for all of them. Where else can you create an entire party of adventurers by yourself or with friends and play a D&D campaign of a home brew design sporting its own unique new GUI puzzles? Personally, I like a campaign that provides puzzles, and this post is about some of the new ones that I am hoping to bring to supporting players when it is finally released. Read on ...

NEW PUZZLES

Players of The Scroll (module one) will have experienced quite a number of puzzles in my campaign already. From "ripped scrolls" to "combination chests" and from "chameleon stones" to "cryptic puzzles". It has a fair number for the player who likes the occasional change of pace and a chance to flex their "thinking caps". And let us not forget the "rune puzzles"! For those who prefer not to tackle puzzles though, there is also the option to bypass many of them, with the exception of one or two game important ones.

The puzzles of the second module will, I hope, be of similar design. The three I show in the video below are actually part of a main dungeon design, and so are designed specifically with that dungeon in mind. However, with minor alterations, I may be able to use them in other areas of the module too. Anyway, here is the video ...

THE JOURNAL REMINDER

While on the topic of new GUIs, I also decided to update one of my other GUI designs to act as a JOURNAL REMINDER. Basically, if the player receives a journal update (maybe even in the middle of a conversation), then my SHOW GUI now keeps a worded reminder that the entry needs checking and remains present until the entry is accessed via the journal. 

Furthermore, the player needs only HOVER over the SHOW GUI (when the reminder is present) to open the journal to read the latest entry. The new system also works alongside the new JOURNAL NOTES system, whereupon a slightly different worded reminder is presented in the SHOW GUI alongside a sound file informing the player that the journal NOTES section has been updated. The reminder is cleared after the player HOVERS to open the journal and enters the NOTES tab section of the journal for such entries. This weeks screen shots image show the update in action. (See below.) And for those that would like to have access to this update now, then you will be pleased to know that The Scroll (module one) supports this from v1.09E.

AREA BUILDING

The last couple of weeks has also seen me going over some of the areas, gradually filling them with objects and creating a "lived in" environment. From a scripting perspective, progress is smooth as I am able to use scripts that are now quite stable and work well for my needs. e.g. I have dedicated encounter triggers that are more flexible to use than those officially provided ... and I have been making good use of them.

As I have continued to develop the areas, I have also been able to consider various side quests and various plot twists that come to mind. How many will make it into the final, only time will tell. It involves more conversation writing, of which I already have quite a bit still left to do.

CONTINUED IMPROVEMENTS

As I continue to design the second module, I find myself being able to improve older scripts, which continue to have improvements on module one. This is why module one has also had an update to v1.09E. However, this is bound to slow down sooner or later, as many of these updates are mostly cosmetic now. So unless further improvements have a reasonably significant impact on module one, they may not be seen until the second module is released, at which point all the other minor campaign improvements will be added then.

ALTHEA WEATHER SYSTEM

For those who may be interested, I also managed to update the Althéa Weather System to v2.0, which is basically the same system I use in the latest version of The Scroll. So, if you want a fully implemented weather system for your NWN2 campaign, then maybe it's worth considering. Version 2.0 basically runs more efficiently than earlier versions.

New Journal Update Reminder System

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

Episode 3: Mapping The Way Ahead

Some of you may have noticed that v2.65 has not yet been released, as I had originally hoped to do last week .... latest early this week. However, because of the approach I have taken to module two, I decided to take a bold step and do some fairly "major" design changes, to make moving forward easier. This meant making some important code changes to the existing campaign files, including the following: (a) Inventory/Store Access, (b) Transitions and (c) Conversations. I know, it's nothing small is it! So before I explain what steps I did for module two last week, I want to say a little more why I made these other changes.

CAMPAIGN UPDATES

1) INVENTORY/STORE CONTROL: To be frank, this code was a bit messy, having already undergone some changes in the last beta testing to make sure it worked in a multi-player environment. Basically, it had become quite bloated with a good deal of irrelevant code, and contained an annoying "glitch", which I  wanted to be rid of: One had to click twice to compare an item in a store with existing equipment. So, the bottom line was I stripped the functions and rewrote the routine to now produce a reasonably slick system. In truth, it could (perhaps) be made slicker still, but I am quite content with the latest rendition for now ... and that glitch is gone!

2) TRANSITIONS: In the process of preparing module two, which involves transitioning on and off a world map (more on that below), I found that I also have "messy" areas of duplicated code that I wanted to streamline again. After all, transitions are a key feature of a module, and I'd rather ensure a clean set of scripts for the job going forward. Basically, many duplicated routines and checks have now been moved to dedicated functions, streamlining the code .. and, in theory, making any bug-hunting easier.

3) CONVERSATIONS: Pretty much for the same reasons as the rewriting transitions above, I wanted to make the code surrounding handling conversations tidier and more streamlined for future use. Also, I finally got around to simply placing some humanoids with the various "conversation" settings on them to try to learn how the different settings affected players in a SP and MP game. Before, it was a little hazy - even hit and miss for me. Now, I am fairly confident I know when and where to use the various options. Most interesting, I learned we can send a cutscene type conversation to a single player in a MP game, without it affecting any other players. I had always assumed all cutscenes were for all players. After learning that  ... and a few other conversation tricks, I decided to rewrite the core companion/created PC conversations, and ensure all in-game conversations could no longer be "interrupted". I also rewrote them incorporating a system that enabled all "new" interaction to switch to cutscene for all players, but remained for a single player when not required.

So, that is a lot of core changes .. and as you can imagine, is why I thought it prudent to put the campaign under another short testing period to ensure these core changes remain working for any imminent release. While these changes affect nearly every aspect of the module, I hope I know enough of the key core areas to be able to do some testing that won't take overly long ... That said, I'd rather make sure before release so players have the best experience!

MODULE UPDATES

I can also add that due to the changes I made to the campaign files, I found I needed to change some of the module elements too, be it simply adding or removing a "tick" from an object, or renaming a tag of an object. Suffice to say, the module has undergone some important changes as well in preparation to adding modules.

MODULE TWO

Apart from those important updates to the existing campaign code and module one, last week was about ensuring module one linked into one of the two potential entry areas of module two. One area of entry is a lobby (if bypassing module one completely), while the other is the Overland World Map if playing straight from module one into module two. It was when I was testing the transition to the Overland World Map that I discovered some of the "inconsistencies" of the tag requirements depending upon whether a player is using their own map (for quick travel) or moving straight to the Overland Map for slower movement. (Yes, there is even more than one way that this travel can start too.) Basically, the different number of options at the start for the player are what I am putting together at this stage and hence, the need to clean up those transition scripts. After much investigation, for instance, I discovered one of my tags being search for had an extra "OMWP" in front of it, meaning the transition kept failing. This opened up the can of worms that led me to tidy up the transition code!

Anyway, here is a screenshot of the overland map in operation .... Some explanation is below.

World Map To Explore!

You may be asking what is going on in the screenshot above? What is being shown? Well, a key feature of my world map system is the "Travel Information" feedback GUI. Basically, as the party move around (controlled by the lead player in a MP game), the Travel Information GUI updates as you move with all pertinent travel info, from terrain being traversed, speed of travel, and (importantly) time, as this affects your vigour levels. i.e. Travelling this way has to be managed. Note, there are other ways to circumvent these factors, such as using a map (quick travel) or a nexus (alternative quick travel), but that is up to the player whether they choose to employ them, or even have the means to do so. The "advantage" of travelling the Overland Map, however, will be the chance to encounter monsters for combat and find many locations that may not be found by the direct paths. (Note: Some direct paths may not be available from the start anyway.)

So, if you are able to zoom in on the image above, you will also be able to see some feedback in the chat window giving an indication on how the party is fairing in their current travel with respect to their vigour and how tired and hungry they may be.

Hopefully, (am I always saying this?), I will be able to announce a release of module one v2.65 in the coming days. All I want to do now is make sure I can at least play through the first few areas, conversations, store transactions, etc to be sure all is still fine and I have not done any unknown damage. Of course, I hope if after release you do find anything, you would let me know. :)