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.