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