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.

Custom Crafting With NWNX2

UPDATED (13th April): In the light of this forum post, I did some further experimentation with kinc_crafting (which I eventually found) and can now recommend the following structure for basic crafting. i.e. When not requiring TRADE ITEMS.

First of all locate kinc_crafting.NSS in the SoZ expansion campaign folder. Open this with a basic text editor (like notepad) and copy the script into the toolset as a new script and name it the same. i.e. kinc_crafting (without the NSS suffix). The only other file you require (to make this script compile correctly) is kinc_trade_constants, which can be located in the same way as described above for the previous script. Again, copy and paste the script into your own module, keeping the same name.

Open your kinc_crafting script and add the include line for the kinc_trade_constants file. i.e. Add the line #include "kinc_trade_constants" just below the other include files mentioned in the kinc_crafting script. Lastly, add the #include "kinc_crafting" include line inside your own On Module Activate script, which will also contain the modified script as mentioned below.

ORIGINAL POST

I have started to take a look at the new crafting system that comes with SoZ. For those that don't know, Obsidian released a tutorial on the subject that can be downloaded from the Vault here. However, what I have discovered (as well as a few others) is that the information it contains is inaccurate and not very helpful, especially with regards to include scripts.

After some time experimenting with the scripts, however, I did manage to discover which files do matter when it comes to the new crafting system and made a post at the forums explaining what I had found. I will now repeat that information here for those who might be considering doing something similar in the future.

The important include file that is wrongly named in the tutorial is kinc_trade and it is this include file that is required for the On Activate and On Acquire scripts when using recipes or incantations. However, this include file also makes reference to three other include files that the tutorial does not mention at all, which are: kinc_trade_constants, kinc_trade_crafting and kinc_trade_system. All four of these include files need to be copied across from the SoZ campaign directory to your own campaign directory if you wish your scripts to compile when using the code from the SoZ On Activate and On Acquire scripts.

The official On Acquire code, however, does not (as far as I can see) do much more than set a variable on every party member and force the item onto the Main PC independent of who picked up the recipe or incantation. This, in my opinion, is not how I want the game to work, and so I did not use the On Acquire code in the end and simply applied the variable (that was set in the On Acquire script) at the same time as the PC who activates the recipe or incantation. This then allows the recipe or incantation to stay on the PC who actually picked up the item.

Here is the edited part of the code I use in my On Activate script:

//////////////////////////////////////////////////////////////////////////////////////
// SOZ CRAFTING SYSTEM (v1.21) ///////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////
// This code is used to support NX2's crafting system.

if(GetBaseItemType(oItem) == 145) //Recipes are itemtype 145
{
//object oPC = GetItemActivator();
string sTag = GetTag(oItem);
SetLocalInt(oPC, sTag, TRUE); // ADDED FROM ACQUIRED

int nRecipeIndex = Search2DA(NX2_CRAFTING_2DA, "RECIPE_TAG", sTag, 1);

if(CheckCanCraft(nRecipeIndex, oPC, NX2_CRAFTING_2DA) )
CraftItem(nRecipeIndex, oPC, NX2_CRAFTING_2DA);
}

if(GetBaseItemType(oItem) == 146) //Incantations are itemtype 146
{
//object oPC = GetItemActivator();
object oItemToEnchant = GetItemActivatedTarget();
if(GetObjectType(oItemToEnchant) == OBJECT_TYPE_ITEM)
{
string sTag = GetTag(oItem);
SetLocalInt(oPC, sTag, TRUE); // ADDED FROM ACQUIRED

int nIncantIndex = Search2DA(NX2_ENCHANTING_2DA, "INCANTATION_TAG", sTag, 1);

if( CheckCanEnchant(nIncantIndex, oItemToEnchant, oPC, NX2_ENCHANTING_2DA) )
EnchantItem(nIncantIndex, oItemToEnchant, oPC, NX2_ENCHANTING_2DA);
}
}

You do also have to copy the two 2da files across (as explained in the tutorial), but the builder must also be aware that the 2da files may not make reference to the same tag as the blueprints the toolset has available. E.g. I had to change the tag of an alchemy table to match the tag reference in the crafting 2da file. (By the way, the crafting 2da file does not open properly in the toolset, so it may need some careful attention if the builder intends to add more recipes as I do.)

For testing, I also copied across the recipe items into my override folder, so that I could reference them inside my own module. I did a quick test on a Perfected Acid Flask, and the crafting worked fine: It checked my party to see if I had someone who had a high enough skill, checked the amount of gold, and also checked if an alchemy bench was nearby. And although I have not tested an incantation yet (for enchanting), I expect it will work just fine as well, as it uses a similar format to the crafting system.

Now it should just be a case of me adding my own recipes and the new system should be up and running for my campaign.

Raising PCs & Selling Spell Books

Raising PCs

The code for raising PCs is now done ... but once again, there were a few more complications than I first thought there would be. Part of the problem is trying to make a system that is intuitive as possible and take into account all the combinations a player may encounter with the system.

In this case, if a PC dies, it can happen to either the Main PC or one of the PC's companions/party members. (Since SoZ, I will refer to "party members" as synonymous with "companions" from now on. When I mention one, I also mean the other.) In the case of a companion's death, a headstone appears and their equipment goes into its inventory (as I explained in my last post). In the case of the Main PC, however, no headstone is created as the player can still access the equipment (apart from that worn).

The player can take an object representing the fallen companion from the headstone, which has an estimated weight according to race and equipment on the companion at time of death. This weight figure does not change and carrying the body object only is the easiest way for a player to move the body (and all equipment) in one go. I have coded it so that if either the "original corpse" of the companion has a raise dead/resurrect spell cast on it or the "body object" has, then the companion is brought back to life with all the equipment that has been left on the headstone - and even equipped items will be re-equipped. However, if the player decides to take one or two items from the headstone prior to the raising, then these items will no longer be given back to the risen companion.

The other advantage of having a body object that can be carried by another PC, is that it can be taken to an NPC who can cast the spell if none of the player's PCs currently can. I have tested this and it works fine. I had a PC carry the weighty body to an NPC cleric, and after paying the cost of the Raise Dead spell (500 gp), the cleric cast the spell on the body object and the PC was raised. I decided not to use an altar for the target of the raising PC (see last post), but simply made it the closest dead PC to the cleric, with a dead Main PC taking priority over any companion body objects.

In the case of a Main PC body, they do not require a body object, as the Main PC corpse follows possessed companions whenever they change areas ... as if the body and equipment were being brought along anyway. The player has a slight advantage if the Main PC is the dead body, as I have not coded anything for the Main PC weight. I don't think this to be a major issue in this case though as there is the pay-off that they cannot access equipped items.

Selling Spell Books

I have been updating my Captured Spell Books hak over the last couple of days, as I have also been coding the wizard NPCs who will offer gold for any spell books with spells in them. This is not finished yet, but I have a working prototype that shows all is well. In fact, I had to spend more time updating this hak for the Vault than on my own module, as there were some other changes that I had missed since the release of SoZ.

Moving Forward

I am nearing the end of my systems for the campaign now. The idea is that with these core systems in place, I will be able to write the story and adventures around them, incorporating some of these ideas into the story as I go. How much they will be a focus of the adventure or just a flavouring, only time will tell. Here is a list of those systems I want to get done over the coming weeks/months before I can will feel comfortable about doing more story writing. I mention them here as much to remind myself as for information:

1) Finish the ambient system. (Environmental activity.)
2) World Veins. (Part of a mapping system.) (*)
3) Chameleon Puzzle Interface. (Using GUI instead of previous designs.) (*)
4) Finish off Holy Book system. (Clerics require Holy Books to study prayers.)
5) Develop crafting system from new SoZ code.
6) Finish off player introduction into new campaign. (*)

(*) Keeping details vague to prevent spoilers.

Any one of these could take time, or (hopefully) be a lot easier than I first think. On the other hand, I may consider taking a break from these and start that story I had in mind a few posts back. I did go to start it and got distracted by another system I needed. Doh!

Wii Have Been Occupied

Just before the New Year, my wife and I had the chance to have a go on a Wii machine ... and we were both surprised at just how entertaining the unit is. I really did not expect much from it, but having had a go at the Sports and the Fit packages, both my wife and I were hooked on the prospect of (possibly) being able to get a little fitter at the same time of being entertained. So, we went out and bought one, and for the past week have been entertaining ourselves with both of these packages, plus a couple of games: House of the Dead (2 & 3) and Metroid Prime 3: Corruption. I always enjoyed playing HotD at the arcades many years ago, and the Metroid Prime 3 is a very entertaining sci-fi adventure that is better than I thought it would be on a device of this type.

Anyway, now that the Wii unit has been in the house for more than a week, I hope to get back to the computer and continuing modding. Another reason I have been putting it off, is because the new 24" screen I bought had to go back because of a dead pixel and the replacement was also faulty. I am awaiting a 3rd unit now and so am having to resort to a smaller older screen, which is not as relaxing to use having been spoilt by the larger one for a week or two.

Dead Characters

Just before I had to send the screen back, I was coding the scripts to handle death of characters. What happens now, is when a character dies, a headstone appears at their body and all equipment goes into it, allowing a player to take any equipment they wish from the fallen character. This is not possible otherwise. The main problem had been when a character held a container with items inside. Coding it so the container would drop into the headstone with the items still in it was quite difficult, but I achieved it in the end by using a variable to leave a check if an item had already been moved to the headstone.

At the same time, a body item is also placed inside the headstone, allowing a player to take the body to a cleric to raise if they don't have the ability themselves. And this is the stage I am at ... I need to write the code and conversations if the player takes a body item back to a cleric. I will probably use an altar in the method, and have the player place the dead body item in the altar to allow a cleric to do the raising.

UPDATE: 12/01/09: Just to clarify the above. The headstone only appears for party PCs/companions and not the Main PC with which the player joins the game. If the Main PC dies, then the player has the normal death penalties and the opportunity to raise the dead PC with another character. If a raising is not possible by surviving PCs, then the player can still see and interact with the Main PC's equipment (even when dead) and the Main PC is always brought along by any surviving PCs who leave an area. In this case, an NPC cleric will be made to target any nearby corpses instead of those upon an altar.

Hopefully, I will have this done by the next blog and start to get writing again. Wii will have to wait and sii. ;)

Auto-Pause Combat (LB) Released For NWN2 Campaigns

UPDATE (06/01/09): This code has now been updated to work for all NWN2 official campaigns.

A reader to this blog read about my combat auto-pause facility that I have coded for my own module and asked if I could do something similar for SoZ. And so, this evening, I decided to take a look at my scripts and managed to put something together. It is not quite as refined as the one used in my own module, as I did not want to add a tlk file and had to rely on changing only one script within SoZ. However, after testing it, I have found it works fine and so uploaded it to the Vault. It is awaiting approval, but I hope other players (who like my group enjoy turn-based combat), will find it a useful addition. As soon as the Vault has approved its entry, I will add a link to it on my blog sidebar.

Hopefully, my friend and I will be able to make use of the code for our own SoZ gaming experience as well now. ;)

Combat Auto-Pause - SoZ can now be downloaded ....

14 FEB 2025: The site hosting the files no longer exists, and so I have made them available to Download from my Dropbox account. Please note, these are old files and I have not checked them for many years, and so use with care. They are NOT compatible with my own campaign, which uses a much more enhanced version of the system.

Mass

Mass ... Effect

I managed to order this game for under £10.00 a few weeks ago. I did not want to pay more than this because of the DRM software that limits usage. It still has not turned up yet, but I'm in no hurry. There is so much else to do.

Mass ... & Weight For Gold

I finally managed to get my system in place that means gold now weighs something and takes up a slot in the inventory, in the way of money pouches that carry 500 gold coins each and weigh 10 lb. If a PC carries less than 500 gold coins, then no pouches are created. I believe the system is flexible enough to work in a multi player environment as well, and allows a player to divide the weight of the gold among all his or her PCs. Furthermore, the money pouches that are created work dynamically, meaning the player does not need to do anything with regards to handing over gold. The testing is certainly more complicated than I first thought it would be, but I believe I have a working combination now.

Mass ... of Christ ("Christmass")

Readers may be surprised that my wife and I do not celebrate this time, or Easter for that matter. We are Christians, and it is because of this and through various points of study, that we came to the conclusion that these celebrations do not edify God. Furthermore, they have the potential to mislead others about their faith. Therefore, taken in the light of 1 Corinthians Chapter 8 verse 13, my wife and I do not take part in such. There are also some very good sermons to support this, including a sermon (in three parts) by Greg Price, which can be found here: Part 1, Part 2, and Part 3. (These link to multi-media pages.)

Now, even though we do not celebrate these particular times, I would like to make clear that my wife and I do celebrate the birth, death and resurrection of Christ every day of the year, and in this respect, dear reader, you have our warmest welcome and hope you are walking with us along the narrow path that leads to Him in glory. God Bless.

I Think I've Done It! (DLGPartySwap)

I believe I have done it! (See yesterday's post.) I was struggling with one last issue where the PCs of the party would keep swapping back to the main PC during any conversation. Then I had a sudden thought to check the Campaign Editor and voila! I discovered what DLGPartySwap now does. :) It does exactly what I hoped for and when FALSE, it stops the dialogue returning focus to the main PC. Once this was set, it solved all my remaining problems that I have tested to date. Although, I am quietly confident that by doing this I have resolved all my issues.

And so, the bottom line is, I believe I have managed to allow players to add a party at the start (or not, as is their choice) and still have all my systems work OK. Just to reiterate what I had to do to get this to work, in a basic outline was this:

1) Swap the original created PCs for copies with new Tags. (Unspawn originals.)
2) Edit 2da script and attach companion type scripts to them using SetCreatureScriptsToSet. (See Script below.)
3) Set DLGPartySwap to FALSE in the Campaign Editor section.

SoZ Party Function Incompatible (Now Fixed!)

After spending the last couple of hours trying to work out if I can include the new party function from SoZ to allow players to make a party prior playing my latest module, I have had to come to the conclusion that it is not going to be possible. :( UPDATE: See post dated 18/12/08.

It is easy enough to add the function and allow the player to create a party, but many of my scripts that then work with the "party" (which includes companions as the player finds them) do not work with the Althéa PC Menu, which is a critical part of my module and the way it plays. Part of the problem is any additional PCs created are difficult to work with as objects. In particular, if it is not the "main PC" (first created) that I wish to work with, I have used the Tag of the companion in many of the scripts to ascertain which character is being played. Unfortunately, I cannot alter the Tag to what I need for the additional PCs and so many aspects of my module fail because of this.

I had wondered if I can "copy" the additional PCs, retag them and use the copies in the form of "companion" style access rather than PCs, but I don't think this will work. (I don't think I can copy a player's creature objects.) I will look at this angle a little longer, but I have my doubts. UPDATE: I am able to copy the PC and give it a new Tag. I now think I need to work with the SetCreatureScriptsToSet function, as the PCs need to use companion scripts. I will look at this angle for a while longer and give an update if I solve my issues.

On a positive note, I believe I will still be able to use the new party conversation system alongside my own.

MODULE UPDATES

In other news, I am now at peace with myself regarding a "logical flow" issue for a side-quest I had in mind and so I hope to go ahead writing this soon. The story hook did not feel right to me at first and so I could not get started until I had it all working properly in my mind.

I have also done some more work to the Real Life System, which now checks if an NPC sees a PC trying to work with a chest that does not belong to them. A PC will not be able to work with any chest while an NPC can see them and they have not had permission to do so. Of course, the same system allows the PCs to "do away" with nearby NPCs if they are that way inclined, but there will be consequences to this kind of action in the form of other NPCs coming to the defence of the first if they do. On the back of this, attempting to pick locks on chests that do not belong to the PC will also now affect alignment for the whole party involved. So, a paladin will not be happy with an out of control thief in the same party.

100th Post - Winter Slow Down

This is my 100th post since starting this blog. Unfortunately, I do not have a great deal to say as I have been very run down again and not been up to using the toolset or anything really. :( More "coughing and sneezing" than "design and creation".

I did manage to code most of the Enhance Life section of the campaign, and as a consequence, I have decided that this ability will also be usable at any level rather than from 4th upwards. Of course, the player will have to discover how this is achieved first and so it may be they won't know how to make use of this until later levels anyway.

I did also manage to write down my first proper side-quest today. Without going into detail, I can say that it's a small mystery that will hopefully grab the imagination of a few detective type players. If I can write it as I hope, it could make an interesting little story itself.

As a side note, I have decided to sell off one of my 20" monitors and upgrade to a 24" one instead. That should arrive in the week, which may help to boost my enthusiasm to do more with the toolset. I also sold my existing printer and upgraded to an All-In-One. Sometimes, having a couple of new things like that help to give me enthusiasm to carry on through the low times. And even if they don't you can rest-assured that I will continue in the future, even if I take a bit of another break.

Auto-Pause Combat

This week I have been looking over some of the new things that come with "Storm of Zehir". This includes the new scripting command SetPause, which allowed me to add a simple bit of script that supports auto-pausing combat every 6 seconds - on a module heartbeat. As some may know, my group of players and I have a preference towards turn-based combat - probably because we stem from the "very" old school of PnP playing. And while auto-pausing every 6 seconds is not exactly turn-based combat in the sense we like to play, it is a welcomed compromise that allows the game to accurately pause every 6 seconds somewhere between a combat round. Rest assured though, this feature is fully toggable for those who want to keep their combats free from any such facility.

Sorry Feat - Cooldown

I have finally managed to get the "cooldown" feature to work with feats, many thanks to Kaedrin who helped me to pin down where my problem was. As it turned out, the issue was nothing to do with the actual information I was trying to add to the feat.2da file, but the fact that it was not always saving between my tests - and so settings I was making were simply not there! I required this feature for a "Althéa Feat" that allowed a player to say "Sorry" to a neutral that they may have attacked. It is part of the "Life System" where a player will be permitted to attack any creature they can see. However, on the off-chance an attack was made in error, then I needed a way to allow a player to prevent the neutral remaining hostile with them. This is where the "Sorry" feat comes into play. By clicking this option, any neutrals (now made hostile) will return to being non-hostile. However, I decided to give this feature a 30 second cooldown usage so that players could not exploit the situation by hitting every few seconds between saying sorry.

Party Conversations

My friend and I finished MotB the other day, with the cutscene conversation bug unfortunately, which was introduced with the SoZ add-on. So, we had to play the last section again with me pausing between lines so we could actually read the ending.

With that over, we started to play SoZ, and were pleasantly surprised at the way the new party conversations worked in a multi-player game. The ability to allow both players a chance to speak or ignore and do their own thing was a great joy. It did remind us more of good old traditional PnP style play where anybody in the group of players could join in.

So, coupled with my own party conversation code, this will be a welcome addition to the campaign and future adventures I intend to build.

Storm of Zehir

My first impressions of this game are very good. I already enjoy the facilities introduced as mentioned above, and I look forward to delving more into the "recipe collecting" system, which was an area I felt needed improving. To me, SoZ has been a big step towards actual gameplay with respects to the spirit of the game. While I can see this will compromise some companion interaction (that the players build themselves), I thoroughly welcome all the great advantages that the game brings instead.

So, even though I am not even off the first beach (we only just started the game), I give SoZ a high score already simply because of the feel it has given me and the added benefits I can already see. In fact, I would even go as far to say that SoZ is probably one of the biggest improvements to the NWN franchise since its release. Good stuff!

Actually, there is some bad stuff that I forgot to mention: There appears to be a bug with the AI since the update and I have heard there are one or two other issues with the latest add-on that require fixing. I have encountered the AI bug myself, in that NPCs do not appear to arm themselves properly and they like to run away from a target before they use ranged weapons. This is most annoying, but something I can fix if Obsidian do not fix it first - which I obviously hope will be the case.

Another Small Step Forward ...

At the end of last year I gave an outline of some of the ideas I had in mind for the Life Essence in this post. At the time I mentioned the following:

• 1st Level (All PCs) - Soul Protection. (The PC is protected against untimely death.)
• 2nd Level (Craft Skill PCs) - Maintain Equipment. (The PC with the crafting skills can also maintain their equipment if they are damaged.)
• 2nd Level (Wizard PCs) - Arcaene Lore. (PC can create "Arcaene Lore Scrolls" enabling powers similar to earlier Colour Magik.)
• 3rd Level (All PCs) - Empower Attributes. (PC can recover lost or increase attributes. Scaling cost per point.)
• 4th Level (All PCs) - Enhance Life. (PC can trade Life Essence for real experiences - Increase XP.)

Well, since then I have managed to code nearly all these aspects ... and a few more. In particular, Soul Protection was coded very early on when I coded the Death System. Readers who have been following the blog closely may already have an idea how this will work. If not, you will know all about it by the time it comes to play.

The Maintain Equipment is almost complete. There is one small change here to the original plan, however, and that is to allow PC's of any level maintain their equipment, as long as they have the appropriate crafting skill. More details of this will be given in the game and on the website, which I hope will be ready to upload at some point in the future, even if it has to coincide with the release of the module itself.

The Arcaene Lore code was established quite early on, but continues to be a work in progress. It has grown as an idea since its first conception and will, hopefully, continue to develop further as I get the time. One off-shoot of this system was the announcement at the time that most material components for spells would no longer be required. Well, I can now add that I have decided that the new era will not require any spell components for the standard spells. I will still have the player meet certain requirements for special case spells, but this will be made clear as part of an adventure.

Over the last few days I have been coding the system that handles the ability to Empower Attributes. I won't go into details about how this is done, as the astute player will learn more about this when they get the chance to play. What I can say, however, is the coding was a bit trickier than I first thought it was going to be. (Isn't it always!) My first idea of using XML code to do the job did not work out, and in the end I was left with two alternatives: The first involved allowing the player to increase attributes in a similar fashion to the equivalent Epic Feats that do a similar thing, or, alternatively, have attributes altered that would still be affected by what the PC had in the way of other attribute altering magik. The main difference is that the former would allow attributes to stack with magik items, where the latter would not.

In the end, I went with the latter, as it fitted in better with the idea I had in mind, and left the Epic Feats untouched as another goal for the player at later levels. As my idea was to allow the player a way to have more control over their PC's very soul, then having a system that was still affected in some way by other items made for a more interesting/tactical gaming experience. For example, when this method is discovered, the player will not only be able to raise some attributes, but also have the ability to lower some. If the PC who is doing the altering of their attributes finds and uses a magik item that duplicates the same attribute benefit, then they may chose to drop the said attribute and increase another instead (because the two benefits on the same attribute do not stack). There are costs involved of course, and there are other reasons why the player may chose to play this part of the game differently. After all, this particular method of increasing an attribute will not be tied to an object that could theoretically be lost at some time.

In the coming weeks, I hope to write the code for the last idea in the list: Enhance Life. I already know how to do this, and is fairly straight forward. And once this part has been done, the core ideas for the Life Essence (which should carry between each module) will be finished, leaving me more time to continue with the story itself.

Ranges

One other aspect I have been looking at today was to do with the range of vision, spells and weapons. I have always preferred to give both the player and monsters a bigger range with respect to all these aspects, as it can allow for some interesting long range combats, as well as help prevent the player's PC creeping forward to cast a spell or use a weapon, just because they are "not in range".

Having altered some of the figures in the ranges.2da, I have managed to improve the distance of vision, and I believe spells work better (I have only tested a couple), but I do not see a great improvement in ranged weapons, like bows.

I even tried altering some of the figures in the baseitems.2da, where it makes reference to minimum and maximum ranges of weapons and ammo, but even this did not appear to make any difference. So, if anybody has any other ideas, then please let me know. :)

Updated Games Menu

I just thought I would give an update on some of the additions I have made to the player's in-game options menu. There are two, and they both appear on the front menu option panel: Adding Map Pins and Renaming A Weapon.

Adding Map Pins

Adding Map Pins is as simple as pressing the Add Map Pin button. This will then add a map pin directly in-game, which also updates on the map (in the traditional manner) after the player exits and enters the area again. This can also be updated manually by the player selecting the Update Map Pins button, which becomes available when there are map pins to update. The third button, Edit Map Pin, selects the nearest pin to the player and allows them to edit the comment from another GUI that pops up. Again, this only becomes selectable when there is a map pin to edit. I have also taken care to ensure players can only edit their own map pins.

There is a small chance that Obsidian may add some code in a later patch that will replace the need for this menu option. However, as I have now finished it, I will leave it in place just in case.



Renaming A Weapon

The second new GUI option is the ability for a player to rename a weapon that they carry in their right hand, up to a maximum of 24 characters. I needed this function for the players as some weapons in the new era can deteriorate (Dead Weapons), meaning the player may wish to reflect this in the name of the weapon.

I have currently disabled the ability to write in numbers as part of the name, as this is not in keeping with the spirit of the campaign. In other words, there is no ability to write Longsword +4. Although, I suppose a player could call it Longsword Four if they really wanted to. However, I am trying to help players avoid naming a weapon to something that may mislead them in the future if their weapon deteriorates.

E.g. A weapon that is +4 enhanced and has 2d4 fire damage may have traditionally been called a Flametongue +4. However, if this weapon deteriorates with use, then it may lose the +4 enhancement or the flaming damage, and so it would be wiser to call it something along the lines of Flametongue only ... unless it loses its flaming damage as well over time.

UPDATE: Due to popular demand, I have allowed numbers to be used in the naming process. Just don't forget that the name may not reflect the ability of the weapon if it changes and you fail to notice. ;)

Map Pins Have A Future?

In the last post you may recall that I managed to work a system that enabled a player to use my own version of "map pins" within NWN2. As I built this system, I was in contact with Sunjammer via the Bioware forums (website added to the website links), who gave this response when I asked him about the possibility of using existing NWN code for map pins in NWN2:

"It isn't possible at this point. In NWN1 when you clicked on the map the client sent the information to the server so the map pin was displayed immediately. In NWN2 all we are doing is creating the underlying variables and there is no message being sent to the server that tells it to create the corresponding map pin ... until the client enters the new area. However I have it on good authority that a) the code still exists in NWN2 and b) it would be very easy to create a UI callback to send the appropriate message to the server. Consequently I'm submitting a feature request to Rob & Rich.Hopefully it can be included in v1.22 (v1.20 is SoZ, v1.21 is the "day 1" patch for SoZ, v1.22 will be the first normal patch after SoZ)."

So, basically, if Obsidian are able to make this UI callback available to us, then I guess the idea of including map pins for area maps will become available to us once again. And if they do, then it would be a great honour to say that it all started here, and thanks to Sunjammer, may become a salvaged system to replace the method I currently have in place. Here's hoping ...

Show Me The Way

I have been busy sorting out buying a new car this week, which has distracted me somewhat from working with the toolset. However, in the time I have had, I have been trying to work on a system that would enable players to use their own map pins with NWN2. But, after a few hours trial and error, I have failed to produce anything that works. (SEE UPDATE BELOW.)

I thought I might be able to add waypoints at the player's location and use an input GUI to alter the text used for the map pin description. However, you cannot (a) Add map text after a pin has been added, and more importantly (b) You cannot see newly created waypoints (as map pins) that are added dynamically during the game. I had a couple of other ideas, but both fail in a big way: For the first idea I was hoping I might be able to "copy" existing waypoints already placed on a map to the players location, but you can only copy creatures or items. The second idea involved placing a number of waypoints to form a kind of matrix across the map and then use code to locate the closest one when searched for by the player who would then be able to enable it. Unfortunately, both of these ideas also fail to be able to update the map text in any way. I also wondered if it was possible to add a small "pin texture" somehow that could be hovered over and allow a tool tip to be displayed. Unfortunately, I don't believe my knowledge of XML coding is up to the job, nor do I know if it is even possible. And so .... I ask any readers if they have any idea how I might be able to approach this problem, or if they know the problem has already been solved by someone else or can confirm if it is a fruitless task.

The new car ... A Kia Rio 1.4 Chill in Midnight Black.

UPDATE (31/10/08):

I managed to build a system that I believe works well enough! :) After researching earlier work done with map pins back in NWN1, I found this by Mad Andrew and this by Jassper. After trying similar code in my module for NWN2, I was able to create map pins that (a) Showed as small placeables immediately, but also (b) Recorded "proper" map pins that would be updated whenever the player left and re-entered the area. To help with this, I added a button to the PC Options menu that allows the Main PC to quickly exit and re-enter the area if they wish to recall the location of their map pins. As the area I jump the player to is very small, the transition is only as long as it takes to load the area they are currently in, which in most cases is only a few seconds. However, as the player already has immediate "placeable" pins within the area, then this procedure to update the "proper" pins is only required on rare occasions.

Stormy Considerations: Zehir Style

I have finally started to get some energy again and back into the mood for using the toolset. It's a bit of a slow return, but at least I have returned! Part of the encouragement came from hearing how many aspects of Storm of Zehir expansion actually reflects quite a few of my own ideas, and may mean I will have less coding (or coding made easier) in the future.

In particular, it seems they may have made customised crafting easier to include, which was going to be one of those headaches that I was not looking forward to. And while they have included a means for different PCs of a party to take part in a conversation, I had already coded that part for my module, and so it will be interesting to see if the two are interchangeable.

I have also been doing more work on the "map system", including designing an item for players to be able to examine the world map without actually being able to travel anywhere. The idea is so a player or players can make reference to the world map if they find something mentioned that might be worth looking up. It is still a work in progress at the moment, and I may adjust it slightly to show "destination icons" rather than not (which it does at the moment), but simply disable the travel function for them. Everything works well, including the ability to switch world maps, which I specifically designed early in the process, and so I am quite pleased with this new map item to date. And then there is, of course, the question of how the new map system will also interact with this one. I think a number of these map ideas may have to wait to see exactly how the new map system works, and whether I wish to adapt a number of the older ones to work in different ways to my first plan.

Another section of the module I have decided to look at now is "ambient life" for things like villages, towns and cities. Originally, I was not going to do as much in this area, and simply place the odd NPC around the place. However, even though I still think this should be something that would be sufficient in principle, when it comes to playing the mod, it just seems lacking. Now, I still don't want to spend too much time with an ambient life system with respect to locals (commoners, nobles and peasants sort of thing), but have decided to spend some time looking at it, but in a way that may work as a generic system for any future settings as well. Then any work I now put into it will be worthwhile for future projects as well.

I have already discovered that, unfortunately, there is no easy way to change the "appearance" between human types (as I thought was possible) because the NWN2 constants don't work; the constants are a leftover from NWN1 code. However, I have managed to find a way to help randomize their clothing. The plan is to make generic waypoints that will logically handle spawn points and then randomly produce appropriate NPCs. This is in the early stages as of yet, but if I can knock something up that will handle the situation to make it look reasonably intelligent, then I will do so.

Finally, another area I want to look at is how players will interact with fallen (killed) companions. At the moment, the fallen companion can be raised, but the part I need to address is whether a surviving PC can pick up their body and/or equipment as well. I need to consider this as a PC may not have the power to raise the PC themselves, and may, therefore, decide to take the companion's dead body (and/or equipment) to the nearest healer who can. I could not find any easy combination of tick boxes in the properties to manage this; therefore it looks like another coding issue to ensure a killed companion can be interacted with in a number of ways. Unless, of course, anybody who is reading this knows any better way to handle it. :)

As Sweet As Honey (Yet Another Family Member!)

I am still going through a rough patch with M.E. at the moment and have been unable to do anything constructive at all for the last few weeks. It's hard to shake anxieties and easy to slip into depression when I am like this, so I have to take it easy and not overdo it.

However, some good things have happened during this time, which have helped me to remain relatively optimistic. For instance, my wife and I have adopted a third rabbit! She is a female lop, named Honey and we took her in when a neighbour admitted that they were not looking after her properly.

Initially, we had intended to simply "foster" her for a short while as we tried to find her a new home, but she has become so attached to us since her "rescue", that it would be too difficult for us to part with her now. Within a day of her coming to stay with us, she became a "new" rabbit, jumping into the air and running circles around us with pure joy. Find more photos of Honey here.

I have told my wife, however, that this really must be the last one we have, as we now have three rabbits, and we had not intended to have any more after we lost Anakin earlier this year. At the moment, Honey appears to have a sneezing issue. It does not appear to be anything serious (she has seen the vet), and she is full of life and eats well. However, to be on the safe side, she stays in our third bedroom away from Bunny and Daisy for the time being, and may well stay that way as bonding three rabbits can be difficult.

As far as any modding, that is having to take a bit of a back seat for the time being as I try to recuperate some energies.

Building New Website

I have not been too well over the last week or so, and consequently have not been very motivated with the tool set. (It requires all my concentration at the best of times.) Instead, I was able to attend a couple of IRC for the NWCon4, which were fun. And, over the last day or so, I have been putting together the first few pages of my new website to complement the next set of modules for the Althéa Campaign.

Its Home Page will now link to this blog, but there will be a header with various links to different sections explaining various aspects of the campaign, including a History section, a House Rule section and an Adventure section. Each of these sections follow a similar colour format to the Blog page, and each has its own contents bar for easy navigation when trying to find information regarding the campaign. Basically, the web pages will have further information about the campaign as a whole and will help give the player a greater background about the World of Althéa and any modules they eventually play.

I felt this was the best time for a face lift to the website, as all new modules are being written in NWN2 (as opposed to NWN1) and they start in a new era from 1st level. Therefore, players can choose to research some background from the History and/or Adventure sections if they wish to enhance their gaming experience. Or, they may find the House Rules section beneficial to help explain some of the unique aspects of the campaign.

There is still quite a bit to transfer from pages that go back many years (from PnP), as well as information from old and recent posts alike. Hopefully, however, it will be something that I can continue to work on in between designing modules. As soon as there is sufficient material to make the website worth uploading, I will do so. I will announce it when done.