Patching A Module

After reading that Amraphael is close to releasing his Zork module for testing and enquiring about haks, I thought I would share this information again about my "Empty Hak" idea. It is a simple idea that allows builders to release haks of any size, and then continue to support their module with a much smaller manageable hak if need be. Not only that, but there is the added bonus that the hak allows the player to patch the module and continue playing within the same game without having to start again. Here is an edited copy of my original post that I made on the Bioware forums 13th July 2007.

THE PURPOSE: To allow players to simply update the module they are playing with latest fixes without having to start the module again.

THE CONCEPT: Use the hak facility to update code in a module that may require fixing.Using a hak to update code is possible because anything in a hak takes priority over the code that is within a module.

PREPARATION: The only real preparation for the builder is to have an "empty" hak (containing nothing apart from a readme.txt explaining what the hak is there for) that is separate from any other hak, which is associated with the module at build time, and that can easily be updated as patches are required. This hak MUST contain this readme file as the hak must contain a file to work.

PATCHING PROCEDURE: Should the builder have the need to change a script or a conversation, or even add items, then all they need to do, is have access to the "temp" folder within the modules directory while they make the alterations. Inside this temp directory are all the files that *can* be added to the hak to make alterations to original mod. For example, if you alter a script (and compile it), *before* saving the module, you can go to the temp directory (alter view by latest files updated) and notice the NCS and NSS files have been updated when last compiled. In this case, it is the NCS (compiled script) that we need to add to the hak that will take priority over the current one in the module. This could just have easily been a DLG (conversation) that had just been altered in some way.

CONSIDERATIONS: Sometimes, resolving the exact problem may not always be obvious, and the builder may have to use other scripts to help resolve the problem in the module. Here is an example of a problem I had with Soul Shaker that helps demonstrate the patching facility at work:

MODULE PROBLEM EXAMPLE

A situation was reported where someone could get themselves locked inside a room without the key to get out.

PATCHING PLAN OF ACTION: I had to find a way of doing the following:a) Check if the player was in this situation.b) Work out a way of adding the key to somewhere in the room if this was the case.

THE PATCH: This problem also required the need for a new item (the key), so in the toolset I built a new key blueprint (that would fit the door) and grabbed that from the temp folder (it was a UTI file). Then I did the following: There was a trigger in the room and so I altered its Onenter script to check if the player fell in the “patch required” category (did they need the key!). If they did, then the new script now created the new key on a nearby humanoid corpse placeable, which I located in the script with GetNearestObjectByTag, which was in the room.

THE PATCH AT WORK: So, I added the new UTI (key item) and NCS (trigger Onenter) files to the “unique” hak that I reserved for this purpose and uploaded it for people to use instead of the previously empty one. Now, when the module plays, it will refer to the scripts in the hak as priority over the “older” ones in the module and play out as explained above. NB: I imagine there may be *some* situations where there is no easy way to "disguise" a patch at work. In other words, if this room in the example above had no access to any nearby objects with scripts, then there may be no other solution than to add the "patch" as an alteration to the players OnEnter script if they meet the "patching" requirements and simply give them the item as they enter the game. Of course, if it is just a variable or other simple scripting process that needs fixing, then this should be very simple to do.

LATER PATCHES: Later patches simply continue to add to this hak as changes are made. I recommend you keep altered scripts in the newer module (even if you resolve the problem by simply changing the module - like placing a key in the room in the example above) because your altered scripts will then still be available for those who are playing an older version of the module and still *require* the altered code.

Designing - Closer To Home

Just a quick note to say that I have not been able to do much on the module this week, as the house has been in disarray as my wife (along with other family help) have been decorating the hall, landing and stairs. What was supposed to be a quick lick of paint and a bit of a tidy up appears to have turned into a full-blown saga! Not only that, but now the bathroom has been included and I know the lounge and dining-room have been scheduled to be done during my wife's next holiday. I have been helping out where I can, but my lack of energy as the day progresses (due to M.E.) slows me down somewhat and obviously leaves me in no condition to work on the module at all.

I have penciled in a few notes to come back to the mapping system and am pleased to see that the poll has already had eleven votes. From the results and comments so far, I have the impression that most players (nearly 55%) are happy with any of the OC map systems as long as the one used complements the module in some way. Nearly 28% of voters show interest in using the new SoZ system solely, but I am not sure whether this is a result of just player votes or includes some builders responses who have chosen this option as the version they have decided to use (if you see what I mean). And finally, over 18% of the voters (to date) appear to be saying the original map system is their preferred system. There are still 21 days left on the poll, so I will wait to see if any more votes swing the results.

It now looks like the decorating will take until the end of the week. Hopefully, I will be able to catch up with the module at the weekend. However, we now have carpets coming!

The World Map (POLL: Which Map System Do You Prefer?)

Last time I posted I thought I might be starting to write the first side-quest for the module. However, I was side-tracked when I decided I needed to finish working on my world map system and also after reading Wyrin's Blog and a post about his own world map. In particular, check out his great tutorial on tracing maps in the toolset.

Now, after giving the SoZ system a little thought, I am wondering if this system is going to be right for my own campaign. The problem is, my module has a unique calendar system (already implemented) that gives days and dates according to my own world setting. I want to be able to mark the passage of time as the player chooses to travel overland using the world map, and I am not sure how this is handled in the SoZ system. The passing of time also checks for food rations and updates the PCs vigour condition according to time, distance and supplies. In the last week, I have been successful in implementing this system using a modified version of the MotB world map, but wonder if it would be possible in the SoZ system?

World Map Poll

On the back of this, I wanted to do a poll (check side panel) to ask people their "mapping preference" and if they have a favourite system or not? I am not saying whether I can make any changes, but hearing peoples comments and opinions on the matter may help me coordinate my own system.

Working Template

Here is a screen shot of a working map system using a version of the MotB map system. (Click on image for a closer view.) Unfortunately, the compression makes the text harder to read, but you may be able to see that the bottom box (which is currently labelled "OTHER INFORMATION") has some of the extra information I coded for the travelling system.

You will notice that the text is currently in red to denote that the party has too few rations to meet the needs of the journey they are querying. The "TRAVEL TO SELECTED LOCATION" button is also disabled because of this. The system does allow the player to try the journey on fewer rations than normally required (by sharing food rations between the party), but the PCs vigour level will be penalised for the journey if they try it, based on how much rationing they had to do. The system also allows for the new Arcaene Spell: Create Food & Water to allow the PCs to be able to create rations magically during their journey.

This mapping system still supports the Map Within Maps system that I designed in the early days of development. The top icon in the above map links to a second world map that opens if clicked upon. And if this is done, the data of the last selection (even if made on the previous map) is still maintained on the second map until a new selection is made.

Other Map Considerations

In case it's not obvious, I like maps. To me, they are one of the core features of a good D&D adventure and the use of them adds a level of excitement (in my opinion). To this end, I have developed this system to allow the player to find maps that also open the world map (but disables travel). When opened, the map opens for all players in a multi-player game so that the group can discuss a route as if talking around the map.

There is also another use of this system, the details of which I am keeping quiet about for the time being, except to say it is part of something called the "Nexus System" and is something players will soon learn about when they start to play. On a last note: This system was rewritten by me to avoid using 2da files. Now, a builder only needs to add location descriptions and add travel day time entries to one script and the code does the rest.

Background Information: I also spent some time checking out two great SoZ Map Systems that use ships as well: Realms of Ultima: Overland Map Land and Sea Travel System by JasonNH and Sea of Stars Proof of Concept mod (WIP) by loudent2. If you are interested in mapping systems and want to involve ships as well, then these two are definitely worth a looking at. My personal favourite (as it stands at the moment) is the system by JasonNH. However, whether I will actually have the need to use either of these systems, it's too early to tell. Maybe in time ...

Gods, Altars & Holy Books

Let me start with some personal news ... snow! Yes, we had snow here this week and two of our house bunnies were out enjoying it for a while before they got cold and decided to come in again. Although, I think Honey (who lives upstairs) had the best idea and stayed in the warmth. Daisy (left), Bunny "Bud" (bottom left) and Honey (bottom right). All public albums found here.

As for myself, I have been finishing off playing Hellgate: London with my friend before the server closed at the end of January. We have now loaded up LOKI to play. After that, we intend to play Titan Quest and finally get around to SoZ, which should be fully patched by then (hopefully).


























Sacred Texts

The Althéa Campaign uses a system that tries to emulate PnP D&D rules as much as possible. One set of rules this includes is how clerics (and wizards) acquire their spells from day to day. For those that don't know, these two classes must carry their holy books (or spell books) to be able to study prayers (or spells) ahead of time. Without these texts, these two classes do not acquire their spells. To this end, I have coded the game to check if the PC carries their text or not. If they are without it, then the PC will lose all spells except orisons (or cantrips) after a rest period. This ensures the player takes good care of these texts for their PCs.

In the case of the cleric, the holy book must be of the same faith as the god they follow. For a wizard, I have designated that a single personal spell book is required. In both cases, the requirement is only one text, which takes up one inventory slot. Both classes start the game with the appropriate text, but if they should lose them during the course of their adventure, then they would need to replace it. For the cleric, it is a simple case of finding a replacement holy book of the god they serve. For a wizard, they would need to acquire an empty tome and personalise it to themselves. (Personalising a book is a simple one click process.)

It is the coding behind the holy books that I have been working on over the last week or two. I made the decision that I will be including all 22 of the Althéa human-worshipped gods, and that a human cleric MUST worship one of these gods only. If the cleric is non-human, then I have left the original chosen deity that the player chose for their PC at character build time (and that come with NWN2). If a PC joins the campaign with a human cleric whose deity is not one of those found in Althéa, then the deity will be changed to one of the common two found in the starting area for either good or evil alignments.

As alignments and a PC's good or evil standing play a part in the campaign, then I needed to make these decisions early on to ensure other alignment and good/evil based aspects of the game can be worked correctly. And having the unique Althéa gods in the campaign help give the campaign its unique flavour.

Party Alignment

I believe I have touched upon this before, but will mention it again now: The actions of any party member impact on the party as a whole. In other words, if a player causes one of their PCs to have an alignment shift towards evil, then all PCs in the party of the offending PC will also have the alignment shift. The idea is that the party are "of one mind" when it comes to their basic beliefs. A player can play their PCs as a good or evil alignment, but will not be able to play a mixed party of both good and evil PCs. This, in my opinion, constitutes a conflict of interest in the group and the party would not exist as such if this was the case.

Worldly Interaction

There will be occasions when a PC can interact with objects that may affect their alignment, such as altars. These are another object I have coded over the last week that can benefit the PCs of the correct alignment. Note: Altars will mostly be alignment (and not god) specific. Therefore, as long as the altar used is in agreement with the PCs alignment, then benefits can be gained. If not, alignment shifts will occur, possibly resulting in the cleric falling out of favour with their deity and losing their holy book until their alignment is restored.

Captured Spell Books

Also over the last week, I was drawn back again to fixing the Captured Spell Book system, which I discovered had developed a caching fault with the main caching function for all the spells in the game. After a day or so at messing around with the code, I managed to fix this and the spell books now function properly again (and I took the time and trouble to update them to work with the new spells from SoZ as well). These will be an important item in the Althéa Campaign, as wizards (and possibly others) will desire them as a source of new spells, and other classes would like the gold they can fetch in the right places. Writing a conversation to handle the offers made subject to the PCs knowledge was more involved than I first thought it was going to be, and I made a few more cost altering functions to cover this.

First Quest?

I believe I have reached a stage of coding where I can start putting some of these system ideas together and start working on the side-quest I outlined last year some time. That's the plan anyway. However, if I come across a situation where I need another "system" put in place first, then it will have to be put back again. The problem is always dependant upon how I want the quest to unravel, which in turn determines other "systems" that I may need to put in place first.