Choose Your Language

Friday, 23 January 2009

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.

Saturday, 17 January 2009

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!

Sunday, 11 January 2009

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. ;)