Fixing The World's Economy

By the title, I mean the World of Althéa of course and not ours, unfortunately. ;) How did I get into this and end up avoiding plot writing again you may ask? It was as I was working on the first conversations where a player can try to start to get different equipment for their PCs when I was reminded of the horrible economic values placed on items in NWN universe. Some may not mind seeing figures run into the hundreds and thousands of gold pieces, but I find the figures somewhat distasteful. For those who may have played PnP (pen and paper) D&D, the idea of having a shop full of magic items was never heard of, and the best the player could hope for was the chance of buying scrolls and potions, or possibly a few very low magic items like arrows and bolts if they happened to be in the right place at the right time.

In NWN, however, it is not uncommon to see in a store a plethora of magic items starting from a few hundred and run into the many hundreds of thousands of gold. Wheel in my cart-load of gold as I want the set of plus five swords third row from the left please. ;) Now, I know this has been done to simply help the running of a world where a certain balance must be maintained while still offering the player choices, but I sill cannot swallow the idea for my own world, and is why I have been altering many of the cost elements within the game. And even then, limiting the stores to minor magic items only.

From experimentation, I have found that altering the baseitems, iprp_meleecost, iprp_skillcost (and yet to be tested iprp_feats) 2da files appears to do what I hoped for by reducing the costs of items considerably. Of course, this then adds the problem of ensuring balance is maintained for players who wish to craft items (hopefully a little cheaper) and potentially even selling them to make a little gold. To this end, I have had to go through nearly every item that can be crafted to see if its final base price is not too high compared to other items and manually edit every item where needed. It is a very boring job and I still have a way to go. :( But, at the end of things, I hope the economy structure will look a lot less "unrealistic" and more in line with old PnP style gaming than the amazing rich world of the CRPG.

On the back of this, I altered some of the XML code that displays the store GUI to show the store's name (if added) and any limit to their gold (so that players can see how much the store has in gold left to buy items from them). The code is dynamic, meaning it updates as the store buys or sells items reflecting their current gold remaining. (See image to the left.) In the same image you can see how the prices of some of those items will be a lot lower than you may be used to paying. Note, however, the world economy reflects this in that treasures found will be more reasonable to the same scale. This is important because gold does weigh something in Althéa! Therefore, if you are playing a weak character, you may even consider a strong companion simply to help carry the treasure found. :)

Another aspect of this is that I want the player to be encouraged to craft (and enchant) their own items as much as possible. As I have said before, items will be available to purchase, but part of becoming a successful adventurer in the world will be to acquire rarer materials and craft items for themselves.

A Beginning ... (Part Two)

I feel like I am back to the point I was when I wrote A Beginning ... last March. Once again I have just finished doing some decorating this week and feel like I can finally get back to the module ... and again, at the point of actually writing the plot! To this end, I have made a design decision to stop working on other ideas (i.e. Holy Books) and get back to the side-quests themselves. After all, it's all well and good having an "interactive" world, but no good if there is not much to actually do in it in the way of a story. And considering the results of the poll are starting to shift in the direction of "action" over "reading", then I thought I would go with the flow. ;) Don't worry, I intend to keep the conversations and reading material in place, but simply decided to start coding for the quests for now rather than any more books that can be found.

Basically, the campaign journal and conversations are starting to get more attention, and I have currently picked out one path that the player will be playing at the start of the game that helps determine the background to which they approach the module (which is also why the plot progress has increased to 3%). As regular readers may recall, the player has a choice of backgrounds at the start of the game: Do they start as if familiar with the story so far (if they played Soul Shaker) or are they starting completely afresh? Each path requires careful attention in the early conversations to ensure the player is made familiar with the story without implying the wrong background. Hopefully, once the start of the game has been done, the conversation paths should get a little easier as the choice of path becomes less intrusive to the new plot.

The Current Poll

The poll still has 17 days to run and I am still interested in any outstanding results and comments. The "action" choice currently leads roughly 58% to 42% (in one translation), and even this result has helped me to reconsider not spending too much time on creating "books" that take quite some time to do if they are not going to serve much purpose in game. I am trying to be careful what I say here, because I do not want to suggest that those who like books will be disappointed, because I hope they won't be. I have simply decided that I will concentrate on placing reading material that may be of benefit to everyone rather than one or two players, and will instead be designed to appeal in other ways.

Real Life Interaction

On a final note, I have finished the code that handles "bashing" of doors when there are witnesses around. Witnesses can be those NPCs in earshot as well as visual range. Of course, if players have the ability to cast silence on the area and are out of sight of witnesses, then they can still bash the door. :) Some doors bashed this way will move the party one point towards chaotic, and so those who prefer to stay within the law will prefer to find alternative ways to get past a door, even if it is as simple as getting permission. ;)

Deities & Holy Books

I have been involved with some decorating this week, which has tired me out somewhat and caused me to have little to do with the toolset. However, the little I have done has had me involved with looking again at the deities and creation of their Holy Books for my world. This was one of those areas I was not going to go into so much detail, but as the results of the current poll (at the moment) suggest around 50% quite like reading and background, then I thought adding a little more depth about the deities in the form of Holy Books might be worthwhile. Furthermore, as these are the same books that clerics use to study for their prayers, then players can determine for themselves just how much they want to pay attention to them.

(POLL: 24 days to go. Please keep your votes and comments coming!)

I have also added a new dimension to the current method of displaying pictures in my Readable Books by making the background texture have pictures already embedded, which means players will be able to see the deity icons inside the books. The picture below shows what I mean, although I have not added any text beyond the god name at this stage. I have also been editing the nwn2_deities.2da to ensure only the correct gods and/or alignment choices are available that match my world's ethos. For instance, clerics must follow a path of good or evil. Only non-clerics (or druids in particular) can choose one of the neutral aligned deities available.

You may also see in the picture above that a player can have their PC start to follow the faith of a new book they find. Taking up a faith (or possibly changing in rare circumstances) means more to a cleric than any other class and is governed by their alignment and so players of clerics should make sure they find a faith and stick to it if they want to keep their cleric's prayers being answered. However, I am also considering what following a certain faith means to classes other than clerics. And this is where you, the reader, can have some input if you like: If you can think of any benefits that a PC could have when following a faith, then let me know. It cannot be anything too extravagant, but something that may add a small benefit of some kind that would make you want to consider taking up a faith. Please comment.

Hey You!

I have also been working more on some of the Real Life responses that will come in the game. Regular readers will know that this system is my attempt to try to make the world feel as though a PCs actions bring about real responses from surrounding NPCs. Not every action is easily coded for, but my latest idea was to ensure PCs cannot simply bash down doors if other NPCs are nearby and act as witnesses to the PCs chaotic actions. And yes, bashing down a door does move a PC 1 point towards chaotic. :) Like trying to open a chest without permission of the owner, the PC will now have to consider the responses of nearby locals before they simply try to knock down the door to "Ye Old Curiosity Shoppe of Magick". Of course, if there are no witnesses nearby that can see or hear the PC's actions, then they can continue to bash away at the door to their heart's content.

My wife goes back to work next week and I should be able to get back to more coding then, and hopefully back to some of the conversations of NPCs that I have been trying to get down for the last month or so. ;)

POLL: What Gaming Style Do You Like?

Now and then I come to a point in design when I question what would be the best way to go for players' enjoyment. I know that ultimately the module will mainly be governed by what I want it to play like, but, at the same time I still want to appeal to gamers as I guess most builders want to. Having started to prepare the conversations for the main quest, I found I was writing quite a lot of text to help fill in the background of the story, which may be tedious for some gamers? I know there is always the option to allow players to skip past the "verbose" path, but at the same time, it got me thinking what the current feel is from other players out there.

For this reason, I thought I would offer another poll to readers who may be able to help me focus on the style of game they might like to play with respect to the quantity of text to read as background to the story. Once again, I am not saying that anything will fundamentally be changed, but feedback may have an impact on options and gaming styles available. So, please take a look at the poll and let me know what you feel about NWN1/2 modules.

In the meanwhile, I have also been helping to play test ZORK by Ampraphael. This is an amazing adaptation of the original Zork text adventure, and for those players with a fondness for the old generation text adventures, I don't think you will be disappointed with what he has done. Amraphael (a.k.a. Ronnie) has done some great custom content for his version and his area designs are second to none, really bringing to life the text of the old game. While ZORK is not a D&D adventure, it certainly has enough challenges and interesting design to keep an avid explorer interested and should be approached as such. I am sure that when released, it should attract a number of fans of the old game who (I would have thought) will be delighted at the chance to revisit this fantasy world.

Scripting Nitty-Gritty (Party AI)

I have been busy looking at the finer details of some scripting aspects for Better The Demon and NWN2 in general. I don't know about the rest of you builders out there, but I have found a few of the functions a bit confusing as to what they actually do at times. It may be because I am trying to code from a multi-player aspect that causes some of the confusion, but here are a few I am referring to (with their descriptions rewritten by me to help explain them better for those who may also benefit from the rewording):-

GetIsOwnedByPlayer() - This returns TRUE for a player's Main PC (*) object regardless of whether the player is currently possessing it or not.
GetIsPC() - This returns TRUE on a PC or creature object if the player is possessing it at the time.
GetOwnedCharacter() - This will return the Main PC (*) of a player who is controlling the tested creature at the time. (Returns OBJECT_INVALID if creature is not being controlled.)
GetControlledCharacter() - If this is used on a PC or creature that the player can control, then it will return the object that the player is currently controlling. (Returns OBJECT_INVALID if creature is not one that can be controlled.) After more testing with this function, I am not sure I have this right even now.

(*) For those that don't know, the term Main PC (or Owned) is used to differentiate the PC that the player joins the module with as opposed to any others they may add either through party creation or as companions.

Multi-Player PC Control In A Single Party

Even with all these functions available, the confusion arose because there was a time when I needed to GET the Main PC of a creature whether it was currently possessed or not. At the time, I thought that GetOwnedCharacter() would do the trick, but this function is limited to checking when the object tested is possessed. I considered a couple of options to get around this problem, but as I also wanted to differentiate between the possibility of more than one player playing in the same party (in Single Party Mode), each one representing a Main PC, then I also needed to be able to determine which Main PC was allocated to each PC in the same party: My idea being that each player could bring along their own PCs and control them by the standard commands that can be given without affecting each others PCs. (E.g. Using the Follow Me command would make only those PCs a player currently controlled follow them and not attract another player's PCs/companions at the same time.)

In the end I wrote my own function GetMainPC(), which I now share for those who may find it of any use. For this function to work, however, it does require some extra work by the coder to ensure a variable is correctly kept up to date whenever a PC or companion joins or leaves a player's "team" within the single party. Hopefully, the following script will help explain its reason:




All this function revision was a prelude to ensuring I could give players the most flexibility when playing their PCs in a party. Whether playing SP or MP, I like to be able to give the player as much versatility with their PCs and how to control them as possible. In a MP game, however, where more than one player controls the same party (even if each player controls their own "team" within that party), extra coding is required to ensure everything plays as it should. And what if the players want to rearrange the teams?

To give players more autonomy over their selected PCs I had to edit my own companion conversation script and include within it an edited version of the #include "hench_i0_hensho" script to ensure the correct "team leader" was listened to with respect to shouted commands. It was as I was testing this and began swapping between the different PCs when I discovered the problem that companions would revert to following the original party leader rather than the team leader whenever a player changed the PC they were possessing. This problem is what led me to learn more about the possession/unpossession hooks of which I will explain in more detail next.

Possession & Unpossession

By default, the companions and the player's Main PC are assigned the same scripts. You can check this out by examining the nwn2_scriptsets.2da. Note though, the scripts do not fire for the Main PC until the player possesses another creature, so no player HB shortcut there. ;) However, this is useful information to know, and editing the nwn2_scriptsets.2da can be a very powerful tool. Add to this knowledge that you can also assign a new set of scripts to a creature using the SetCreatureScriptsToSet function and you have started along a path of interesting AI possibilities.

I mentioned all this to draw attention to the nwn2_scriptsets.2da. If you look at it closely, you will notice two scripts in particular in the ScriptUserDefine column for when a player is possessing a companion (gb_player_ud) or not (gb_comp_usrdef). And when these two scripts are used correctly, we can tell when a player has possessed or unpossessed a PC. By experimentation, I found the gb_comp_usrdef fires when a player unpossesses a PC and the gb_player_ud fires when a player possesses a PC. If you remember this, you can use OBJECT_SELF in each script for the creature it refers to.

E.g. If a player changes possession from their Main PC to a companion called Fred, then gb_comp_usrdef fires on the Main PC and any reference to OBJECT_SELF within it is to the Main PC and gb_player_ud fires on Fred, and OBJECT_SELF within this script will refer to Fred. (NB: I have found that you can refer to both possessed and unpossessed PCs just from the gb_comp_usrdef at the time of unpossession by using GetFirstPC(FALSE) to get the newly controlled PC within the gb_comp_usrdef script. However, I am not sure how reliable this will be, as it may be affected by timing. I tried the same thing by using GetControlledCharacter(OBJECT_SELF), which you would have thought did a similar thing and it only worked sometimes.)

Practical Uses

For me, this newly discovered knowledge will serve me in a couple of ways. (I say will, as I still have to make use of it in some of the things I mention next.) Firstly, it will allow me to quickly change the player who is controlling a PC. For instance, I can now easily change the object variable representing the player who now possesses a PC. i.e. The moment a player switches to another PC, this player will now be the one whose commands the PC will respond to. Currently, the player controls this by a conversation with the PC. Secondly, and for me a performance saver, I can use these scripts to determine if the Main PC Menu (GUI) requires its data updating for viewing a different PC. Previously, I was relying on a function's internal heartbeat to keep checking the PC state while the GUI was open. Now, the same function no longer has to loop through itself making the check, as the hook is now intercepted with this new possession/unpossession function discovery.

Auto-Pause Added Toggle

On a final note related to nwn2_scriptsets.2da, I updated the Main PC Menu to have a toggle switch that allowes the game to auto-pause when a PC is attacked. This works in tandem with the Auto-Pause (Turn-Based Combat Simulator) facility, in that when it is triggered it turns the Auto-Pause facility on at the same time. NB: If players don't want this facility, then it need never be toggled on and is off by default. If, however, they turn it on and then decide they do not want the Auto-Pause facility turned on for the remaining combat, then they can simply switch it off with the new feat that every PC acquires. Below is a screenshot showing the location of the switch:

Multi-Player Considerations (Cutscenes)

Coding for multi-player is definitely a pain. You may recall my experiences in my last post on the matter. It has been a while since then, but once again its complications have returned in the form of interactive cutscenes. Hopefully, my own testings will be if use to others who may be considering MP coding.

I started to write a cutscene conversation for a side-quest (at last!) and wondered what would happen if one player should activate a cutscene in one area, while another player was in a different area (and the conversation was set to multi-player cutscene in its properties). Thankfully, (and it may have been obvious to some), testing showed the cutscene does not fire for those in a different area to where the cutscene takes place. This means it is possible for one player to see a cutscene that other players will have to learn about afterwards. Thankfully (at least for my purposes), the journal does update for all players. The point is, I like the idea that one player may witness something another may not, simply because the were elsewhere at the time. E.g. One player is buying equipment at a store, while another player stumbles into a cutscene as they were making their way to another location.

In fact, there were only a couple of minor difficulties that I have encountered when coding for multi-player gaming at the moment:

Don't 'Follow My Leader' Question

First, any companions (or extra PCs added to the game at party creation time) always follow the leader of the party between area changes even if it was a non-leader player who had originally asked the companion to join the party. In other words, if Player A had asked companion Janice to join the party, and Player B had asked Frank to join the party, then both Janice and Frank would leave the area with the leader (Player A in this case), if Player A moved to a different area to Player B.

As I say, it is a minor issue, and I have already written some code that prevents this when jumping players within the same area. So, maybe I can adapt this code to do the same thing for between areas. I mention it, just in case anybody knows a quick and easy way around the problem. I can tell you that it is not as simple as removing the tick from the Party Transition box, as this simply prevents any other players from jumping at the same time as the exiting player, but does not prevent all companions following them.

At the moment, the simplest workaround is for the players to change leadership between the players involved if one of them wanted to take the group to a different area. However, this still operates as an all or nothing affair at the moment and I would be interested if this can be coded for, without resorting to allowing more than one party in the module. I know the situation where the likelihood of such splits in the group is highly unlikely, but I would like to know if it is even possible. If it not possible, then I will simply ensure the situation where a split is required does not rely on an area change over. ;)

Cutscene Camera Question

The second minor issue occurred when I ended a multi-player cutscene conversation for all players. After choosing "Goodbye" and ending the cutscene, the player making the conversation choices has a "clean ending" and the camera returns to a pleasant viewing angle. However, (in my own testing), as the conversation comes to an end for the second player who is viewing the conversation, the camera suddenly jumps above their head looking down. Again, it is a minor nuisance, but is one that I hoped someone else may have encountered and know how to "fix".

Fixing The Small Things

Not too much to report this week. I managed to get through most of the outstanding crafting points I wanted to get done this week (all but completing the second tome) and managed to fix a couple of other things along the way: (1) Alignment issues of companions when the player might perform an act opposite to their own ideology; (2) Stolen Goods text colour when the player had the chance to rename their items.

I know I have said it before, but I really am closer to getting into writing the plot now, and I hope I can start doing so with more frequency in the coming weeks. In fact, I can only foresee one more mechanics issue that may take some of my time, and that relates to the mapping system.

A Trip To Queensdown Warren

On a personal note, my wife and I took a trip out last Sunday to a local warren close to where we live, called Queensdown Warren. The weather was definitely on the plus side for the time of year and the bluebells were in full bloom, allowing me the chance to take some photos with the new digital camera we bought last year. The photo to the left is of a tree I thought was quite interesting, as it appeared to have a face in it that reminded me of the classic Treants of fantasy.

If you like to see some of the other shots I took (and even get to see what my wife and I look like), then feel free to check out the slide show at this link, which also shows off the bluebells. Unfortunately, a few of the shots are more blurry than I would have liked, but at least I am getting the practice now. :)

Stolen Goods!

Crafting Tome Screenshots

As requested by Frank Perez, I am including a few more screenshots of the crafting tomes this week. The first couple of shots show the original tome, complete with contents guide. This shot is different from before, as I have altered the contents guide slightly. The second shot shows where I have used the contents guide to jump to the Armour section, which then shows the first few formulae that a crafter can use at lower levels. After that is another page showing the Boots section. This tome is now complete.

Screenshots:

This last screenshot shows the beginning pages for the second (and final?) crafting tome that gives details of formulae used with the greater essences: Brilliant and Pristine. Like the previous tome, the beginning gives some basic information and the later pages contain the formulae (which I still have to do for this tome). Note that the contents guide in the screenshot is not finalised as it is using the previous tomes contents guide as a template. For instance, the second guide will not contain the same appendices.

Looting Chests (Real Life System)

Readers of this blog may recall that I am working at trying to allow players to interact with the module in such a way that will induce a reasonable "real life" response where applicable. Complementing this idea, I have made any form of stealing (i.e. acquiring goods without permission of the owner) more difficult than it may be in previous games and such actions will have an affect on alignment of the party. Should a player play their PC this way, however, then they will most likely get to see the items they steal being written in red text. The text will (in most circumstances) remain red throughout the rest of the game as a clear indication of the fact that it is a stolen item. Such items may or may not be recognised by NPCs in the game, but almost certainly, only black market merchants will consider entertaining such items for purchase.

Weapons In Crafting

During my coding of the crafting system, I had to consider the affect of Dead Weapons: Weapons that can deteriorate over time if not maintained and Exotic Weapons: Weapons made from a material other than iron. Both have an impact on crafting and I have finished working the code for Dead Weapons, but I have to wait for a new function in patch v1.23 before I can finish the task for the Exotic ones. However, what I can say, even from what I have done to date, is that I am finding the crafting features I have implemented (especially for weapons) do now appear to be having an impact on how the game plays, which I hope players will find an interesting difference when playing this module.

Crafting Remains

I only have a few things left to implement before I can turn aside form crafting and return to quest writing again:

1) Write new code to determine how and when volatile essences will drop to allow players to craft with the greater essences. NB: I have decided that players will have to create all the brilliant and pristine essences from volatile ones. i.e. Creatures will not automatically drop brilliant or pristine essences, thereby making their acquisition much more of an achievement and advancement towards enchanting items than the norm.

2) Add the new SoZ creature parts to the monster drop possibilities. In this campaign, monster parts can be acquired directly from the creature itself rather than being bought at a shop. Whether I choose to have such ingredients accessible at a shop or not yet, I have not fully decided, but even if I do, their quantities will not be limitless.

3) Finish writing the second tome with all the formulae for creating items using the greater essences. This is a more laborious task and requires concentration to ensure the tome layout is comfortable on the eye. I expect at least another week's work here.

On the quest writing front, I have been inspired since sorting the crafting system out with a couple of quests that revolve around recipes, molds or general formulae. In this way, I hope the player will be gently, but decidedly involved with the system from an early stage of the game. As I have said before, it would pay the player to become involved if possible, but is not essential if they really want to bypass it altogether.

By the way, I fixed my second computer and can test multiplayer code once more. :)

Carry On Crafting!

What a week! I have finally finished the tome entitled, Enchanting Recipes of the Past and am at last seeing the light at the end of the tunnel of this quite long stage. This 70 page tome is clearly laid out and has a quick access contents guide to help every player manage their crafting needs. No longer will they have to rummage through many tomes just to find the one recipe to check if they meet the requirements. Set out by both category and level, the player will know if they are able to craft a given item in seconds, and easily spot what else they may be able to do as they increase in level.

What has slowed me down a bit has been the number of alterations (and some corrections) I have had to make to the 2da's along the way. It was simple enough to do, but just a bit boring. Along with adding all the TIMBERS and INGOTS to the COST column, I also did the following:

NX2_CRAFTING.2DA ALTERATIONS:

Recipe 11 - Capitalised Gold Necklace tag in 2da and added DIAMOND to recipe description.
Recipe 94 - Corrected Craft Alchemy to 3 to match description.
Recipe 100 - Corrected tag of item made to match 2da: nx2_r_w_bolt_poison
Recipe 110 - Still needs silver weapon adding. (Work In Progress.)
Recipe 116 - Added Silver Battleaxe recipe.
Recipe 122 - Still needs silver weapon adding. (Work In Progress.)
Recipe 128 - Still needs silver weapon adding. (Work In Progress.)
Recipe 146 - Added Silver Dagger recipe.

NX2_ENCHANTING.2DA ALTERATIONS:

Added sfx_conj_magic to sound for all Incantations.

Incantation 10 appears to be Profane Weapon. (Recipe Removed)
Incantation 11 appears to be Sacred Weapon. (Recipe Removed)
Incantation 24 - Made level required 6 as per recipe description.

CRAFTING.2DA LEVEL REQUIREMENT ALTERATIONS:

811 - Leather Armour 2
812 - Leather Armour Salamander 14
813 - Studded Leather 3
814 - Studded Leather Salamander 15
826 - Hide Armour 3
827 - Hide Armour Salamander 15
828 - Padded Armour 1

NB: Let me know of any other "errors" that would be worth knowing about!

Renaming Equipment

I have also been working with the code around the crafting of these items, including reworking the renaming facility that I originally had in place for just the weapon held in the right hand. Now, I have extended a fourth tab on the Main Menu that allows the player to rename any equipment that they can equip. One of the reasons for this, is because it is easy to make a mistake when finishing the crafting process and name the finished product with an error in it. This system allows the player to rename the item at any time. (See the screenshots.) UPDATE: I just discovered that there is a variable that can be set on the module that allows the smith hammer to be used on items to rename them. Checking the smith hammer script, you will see:

int bSmithHammerRenameItem = GetGlobalInt(CAMPAIGN_SWITCH_SMITH_HAMMER_RENAME_ITEM);


If this variable is set to true, then the hammer can be used to touch an item and the rename GUI text box appears. I am in two minds as to whether to include this option or not though, as it could be dangerous if a player was to rename an item that I have set script to check. It's ability to rename items is indiscriminate at the moment, but I may change it to check for items worn, like my own script currently does. This would then allow a player to rename items a couple of ways.

Enchanter's Satchel

As most players will probably know, the Enchanter's Satchel allows the PC to craft items in the field without the need to have access to a workbench. However, in the Althéa Campaign, this item requires the PC to use one more item in the process: Life Essences. Regular readers of this blog will know that the Life Essence will play a prominent part in the campaign and is an item that can be used in many ways and so it will be up to the player if they want to take advantage of crafting in the field using the Enchanter's Satchel and expending Life Essences. Alternatively, they can just wait until they have access to a magician's workbench where they can craft without any Life Essence requirements.


Mold Information

On the back of a previous post, I also took the trouble to rename all the molds to show at a glance what the minimum Craft Armour or Craft Weapon skill had to be to use them. E.g. Mold(CA1): Light Shield and Mold(CW2): Club, require a Craft Armour skill of 1 and a Craft Weapon skill of 2 respectively to create these items with the most basic of materials.

(*) ADDITION: I will also be adding a level indication for all newer (SoZ) recipes as an indicator of what minimum level is required to craft an item. The figure will either represent the lowest rank in the appropriate skill or the lowest caster level for the catalyst spell used in the recipe description. E.g. Recipe(8): Amulet of Health +2 means the lowest caster level is 8th level as a catalyst spell is used here. Recipe(8): Acid Flask means the lowest Craft Alchemy skill rank required is 8 points.

Another Craft Tome

I am now looking at writing at least one more book for crafting. This book will contain all the recipes that use the greater essences (brilliant and pristine) at a glance. Again, the idea is to take away the need for the player to rifle through various collected essences to find a recipe they wish to follow. Essence description will be made much simpler, and the prospective crafter will refer to the tome instead when wanting to see what is required for crafting with these essences. I had considered a possibility of a third tome that covered the new style recipes that come with the SoZ expansion, but due to the way they are gathered already (as if in their own tome), I decided against it. ADDITION: See the comment above regarding SoZ recipes under "Mold Information".

I am also going to make the usage of Enchantment Recipes single use only. Therefore, finding and collecting more than one of the same recipe (which can be done) will be beneficial rather than sit inside a tome alongside a duplicate that does nothing more than duplicate the same information. Making these recipes single use only feels more appropriate to me, especially as there are other ways to craft items available. UPDATE: I have decided to make the Creation Recipes single use only as well. As these recipes greatly reduce the requirements to create certain items at the cost of only a small amount of gold, I considered that these should be "consumable" during item creation as well.

Specialist Bags

Another section of items I have been setting up are specialist bags. Those who have played SoZ will probably be familiar with the concept already: Bags that are designed to hold certain items only and reject others. To this end, I have created two to date:

1) Treasures Bag: Gems and jewellery automatically go into this bag.
2) Crafting Satchel: Some may know this as the Bounty Bag, but I have renamed it as it will accept a number of other crafting ingredients as well now, like molds.

There may be times when an item is not automatically placed in the bags, such as when a piece of magic jewellery is made. Furthermore, I have made it so items can be removed from the bag again if need be. This may be obvious, but was not the case in practice.

Second Computer Dies

On a personal note, I had the frustrating experience of having my second computer fail on me yesterday. This is a pain, as I test all my multi-player code with this computer on the LAN. After checking around the prices (and discovering everything has gone up due to the exchange rate being so bad), I have decided to just to patch the computer up as cheaply as possible. Therefore, I ordered the following at a total price of just under £185 from ebuyer:

1) Intel Core 2 Duo E7400 2.8GHz Socket 775 1066MHz FSB 3MB L2 Cache Retail Boxed Processor
2) ASROCK P45DE P45 Socket 775 8 Channel Audio ATX Motherboard
3) Crucial 2GB Kit (2x1GB) DDR2 800MHz/PC2-6400 Memory Non-ECC Unbuffered CL6 Lifetime Warranty

Hopefully, I will have the energy to fix it when the parts turn up next week.

SoZ Crafting - Avoiding Trade Items

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 in this blog post.

Using the kinc_crafting include file instead of the kinc_trade bypasses the check for TRADE GOODS. However, you may still like to replace these goods (as described in the original post below) so that the player still has to acquire ingredients similar to the original TRADE GOODS. If you do, simply carry out the instructions below, but now without the need to delete the COST_GOODS and COST_RARERES columns first.

ORIGINAL POST

I thought I would share a couple more things with fellow builders with respect to crafting using SoZ code. First of all, if you have tried opening the nx2_crafting.2da file, you will have probably found that it has errors that prevent it from opening in some 2da editing programs. For those interested, here is a FIXED FILE that you can download. This file is required for those who may wish to edit it to either add or change those recipes that are available in the game.

In particular, you may wish to remove any references to TRADE ITEMS required to craft items. These items appear under the COST_GOODS and COST_RARERES columns and refer to TIMBERS and INGOTS. For basic crafting, you will NOT want these columns to contain references to any items, but want to add items (replacing these trade goods) with specific ingredients to the COST_ITEMS column instead.

E.g. In rows 97 and 98, I have removed the GOOD_TIMBER reference from the COST_GOODS column and added specific tags representing the planks instead. (See screenshot.) Now, when the code checks for the items required to make the different types of poisonous arrows, it will not fail when checking for TRADE ITEMS (which we don't want in a basic crafting system), because they are no longer listed, but will require specific planks of wood instead. In our example, I have made the requirements a Zalantar Plank for mild poisonous arrows and a Shedderan Plank for poisonous arrows.

Continue to remove unwanted TRADE ITEMS from their respective columns and add appropriate planks of wood or ingots as required. In this way, you can keep all the recipes that can be found and make use of basic crafting items rather than have to rely on the TRADE system.

Just for your information, I have also discovered a number of errors with respect to items required for the crafting (in the 2da file), descriptions of such (in the recipe description), and even in the resulting item itself (item object). As an example, these two lines that supposedly make two different types of arrows, actually make an arrow with the same qualities! Of course, it is easy enough to add or alter the properties on the arrows and make a new campaign item (that will be created instead), which is what I have done. Just remember to ensure you have the name, resref and/or tag set exactly as the 2da file requires or the item will not be made.

In-Game Information

I am glad to say that I am nearing the end of creating the tome called, Enchanting Recipes Of The Past (see last blog entry). The tome contains over 50 pages of information, but thanks to the easy to use "Contents" system that works with my ReadBooks add-on, every crafting recipe is easy to locate and follow. I only have three sections left to do: Grenades, Venoms & Special. I also took the opportunity to update the ReadBook code to now close the "Contents" section automatically after closing the book. Therefore, this line in the conversation will be removed for all books contents displays now.

During its writing, I also worked at the modern SoZ system of crafting and checked out some of the code I had already altered. At first, I thought I had located a bug in my code, but after some debug tests worked out that I had just happened to come across a recipe (among the hundreds) that had two errors in it! What are the chances of that? The errors in question (for recipe 11) were:

1. The recipe neglected to tell me that a gem was involved. (I have now edited that in.)
2. The tag in the 2da file was lower case instead of uppercase. (Now corrected.)

The problem was that when the code went to check for the necklace required (written in the wrong case in the 2da file), it did not find it in my inventory and ended up giving me another necklace in its place! This went on every time I tried the recipe, which also means it is an exploit in the game itself.

Before finishing the tome, I also started to check the code behind the Molds that PCs can use to build weapons and armour. Again, I have tried to simplify the usage of these items by explaining the mechanics behind their use and giving extra information in the exotic materials descriptions where applicable to make the crafting easier for the player. To accompany this, I also added more in-game information for the player to help them recognise what they need to have in the way of skills to be able to craft items from molds in the first place. Check out the screenshot to see how the information is easily found from the player's unique Main Menu.

Like all things I am trying to set out for in this module, I am hoping to make the more specialised areas of game-play more accessible to the average player. From my own experience, I have found certain aspects of crafting rather complicated to use, and that it often took more time and trouble to do than it was worth. However, by making the value of crafted items more valuable to the PC (and player) and at the same time easier to understand, then I hope that crafting will take a more enjoyable and prominent place in the campaign than it would have done otherwise.

Crafting Revisited

After doing some work on a new area, I was once again inspired to return to sorting out the crafting system for the new era. I first looked at the system in February last year with these posts: The Art of Crafting and Crafting In The New Era. Then recently I took a closer look at the SoZ additions in the Custom Crafting With NWNX2 post. I know this means I have diverted from plot writing again, but the crafting system is an involved part of the mechanics that I need to get done so I can then use some of its concepts to start adding items to the world and thereby give added reason for PCs to explore.

Enchanting Recipes Of The Past

The Althéa Campaign makes use of all the current crafting systems available in the OC and expansions. However, I have tried to make the more awkward system (the OC for some people) easier to understand and use. To this end, a new tome (currently entitled "Enchanting Recipes Of The Past") has been added to help explain the differences between all the systems that are available to those players who will want to take up crafting. I hope that the rewritten combined system will encourage players to try it out, especially as crafting will be the sure-fast way of acquiring more useful items for the adventurer within the world of Althéa.

Over A Hundred Recipes!

The tome is more than a book simply explaining more about crafting. It will also contain every formula from every one of the 27 recipe books from the original NWN2 campaign! Their inclusion into one tome is explained in the tome itself and forms part of the back-story. As a consequence, however, the PC must have the tome carried somewhere in their party to be able to craft an item in its pages.

The above image shows only the start of the book, as I still need to write the many chapters that cover the formulas. However, the structure of the tome and its added contents guide will make locating an item formula (that a PC can actually do) much easier! Chapters still to be added include: Armour, Weapons, Bracers, Belts, Boots, Cloaks, Amulets, Rings, Grenades, Venoms & Special. Then, within each category, it will be clear what level the PC needs to be before any further requirements (ingredients) will be listed separately for the individual items. Note, however, each chapter begins with a brief explanation of basic requirements that will not be repeated in each item description, thereby removing much superfluous text that can often confuse the reader.

Quick Reference Appendices

The tome will also include appendices that will help the player know how to acquire the different essences (by naming which monster parts yield which essences) and a brief list of spells and gems, etc. that are needed to craft all the items in the tome. Hopefully, the tome will act as a one-stop quick reference guide to make crafting a lot more accessible to players than it is at the moment. As I said at the start, Althéa will also include the two crafting systems that come with the expansion packs. My hope is that this revamped version of the original will complement them well and help to make a complete and comprehensive system for Althéa.

Campaign Specific

As the economy and ecology of Althéa differs from the standards in the toolset (presumably set for Toril), I need to make campaign copies of every crafting item reflecting these aspects. I.e. Prices are a lot cheaper because gold is rarer and some descriptions mention locations that are not within the world of Althéa and therefore need updating. Furthermore, I have found that the original official craft dropping scripts don't work as I first expected, which means I am having to add code to ensure monster drops are working. Doing this and adding the text to the tome is a fair amount of work, but is something I hope to get done over the coming days (or weeks?).

Multi-Player Plot Item System

I have been concentrating on a couple of things this week. First, I have been giving some time to help beta-test Amraphael's Zork module. This is one of three modules I have been trying to spend some time with. The other two, which I have started (but only just) and need to do more with (if and when I get the time) are: Fate Of A City and Price of Honour. I am prioritising the Zork adventure for now, as I did say I would try to help with the testing.

The second thing I have been concentrating on this week turned out to be quite a difficult thing to do, but eventually I succeeded: Design a system to ensure plot items would remain in play in any/most combinations of a game. While this is more important for MP games, it also has some benefits for a SP game. E.g. If a player drops a companion or decides to leave them behind (and they happened to be carrying a plot item), then the item will automatically be given to the main PC. In a MP game, this process becomes somewhat more complicated, as we have to consider other players coming into or leaving the game, who also may or may not have companions and be carrying plot items. In this situation, if a player leaves and they were carrying plot items, then they are passed over to a player still on the server so that the game can continue if they need to. If the same player should return to a later saved game (and still has plot items on them), then they are removed in favour of the player who is currently running the module.

The whole procedure of trying to keep a database of plot items (stored as resrefs on the module that are preserved between game saves - storing objects failed to work), which could also be duplicated or even have tag-based scripting was quite a coding headache. However, after a few days of trial and error, I believe I have a solution. I even had to update the barter.xml code, because if a player cancelled bartering plot items, then the code that updated the plot state was not updated. It was a complicated affair with adding code to the On Mod Leave, On Area Enter, On Acquire, On Unacquire and some specific scripts that I use when handling companions. Now that the job is done, however, I can happily (hopefully) add plot items with alb_plot_ at the start of their resref and the code will take care of the rest. That's the plan at least, and the system is capable of checking 100 items per module as it currently stands, which should be ample. Remember, these are plot items and not just any item: Items that must be acquired and used to complete a quest.

Maybe I can get back to working on the story again now. ;)

Keeping The Faith!

This week I planned to spend some time making items that I am going to need for the quests involved at the start of the module. This should have been a reasonably straightforward task, but it was interrupted by a few things I discovered along the way:

1) A bug with opening books with a contents menu. (Now fixed.)
2) A bug when players switched PCs while reading a book. (Now fixed.)
3) A bug in the ambient system where NPCs would stop walking. (Now fixed.)
4) Players could change their god (not wanted) between levelling up. (See next.)

It's amazing how many things you can "suddenly discover" need dealing with when you are set on moving onto the next stage of building. The fact that a player can change the god they follow during a level up was something I did not know about and only came to light as I tested an XP award. This becomes a problem in the Althéa Campaign, because a PC is not supposed to be able to change their faith this way. Changing the god a PC follows is only meant to be possible if a PC finds and reads a holy book on a new faith. Once chosen, a PC then keeps their faith for the rest of the adventure ... unless there are some very unusual circumstances for such a change. In the end, I managed to fix this as well.

As far as making a start on the new areas where the early quests take place, I did take up Frank Perez's (Faithless) recommendation of Smorpheus' Toolset Visual Index DELUXE, which (from what I have managed to see so far), may go some way to helping me with the huge number of placeables that are available to choose from when trying to decorate an area. If I find I use it more and more, I intend to give some feedback for the author.

Painfully Slow

I tried my hand at doing an interior this week - and how painful it felt! It's not that I did not know how to do it, but that finding the placeables I wanted to use among all those available felt like a very laborious task. And then there were the options to change the different styles the actual tile sets could take in colour and design. The number of options and choices is absolutely marvelous, but having so many options did place my "wanting to do things to the nth degree" under a lot of strain. In the end, I decided that my patience was too lacking to spend too much time looking around at different objects, and decided to say "enough is enough" and kept the design a bit more basic than perhaps I could have done. It still has plenty to look at and do (I hope), but I hope that I can spend the time more productively elsewhere. After all, having nearly finished only one interior, I am not sure I can add much more than 0.5 % to the overall complete score. (I have decided to hold back screenshots until I have more material to choose from.)

World Map Poll Results

The World Map Poll came to a close this week and the results (from this small poll of 23) tend to suggest that most (11 at 47%) are happy with any of the map systems, with some added comments that suggest "as long as the system fits the style of the game". There were similarish results for the next two most popular results for those that definitely preferred the SoZ map system (7 at 30%) or were happy with the original mapping system (4 at 17%). And there was one person (representing 4%) who said they could live without any map altogether.

From this, I think I can be happy that the majority of people do like to have maps in their game, which makes the effort of doing such worthwhile. My only slight concern is for the 30% who really do prefer the new SoZ system, which (at the moment) my campaign is probably going to avoid using. However, as I believe I have mentioned before, I do have some other ideas on how I might be able to put the SoZ mapping system to use. Whether I can do this or not, only time will tell. Other than that, I will have to hope that the modified versions of the static maps I am using adds an interesting element for those gamers.

A Beginning ...

I think the bulk of the house decorating is behind us now, and I am slowly regaining energies to start looking at the campaign again. It's always hard getting back into a module after a break (as I am sure you will know), as one has to become familiar with all the different scripts and aspects again, so that you know where you were.

As it turns out, I think I was at the point where I could continue work on one of my side-quests. It happens to be the first side-quest, and in a sense is the first "plot" section I have written. I have the main story penciled in of course, but other than designing a couple of its areas (very roughly), even that part has not had any conversations done yet.

To mark this stage, I will add a percentage score in the left sidebar for the amount done for the two module sections: Mechanics and Plot. I did this with Soul Shaker and I know it helps players get a feel of how the work is proceeding. Mind you, please don't be put off by the figures, as I sometimes do larger chunks than at other times, so bear with me. ;) I will also add a new label, "Better The Demon", which is the current title for the module. This label will be used for posts that will contain more emphasis on plot writing. That's the theory anyway.

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.