Splitting Stacks Fix (Revisited & Improved)

For those NOT interested in this scripting fix,

jump to the bottom of this post for Other Module News.

This week I had reason to visit that old problem of split stacks losing their variables. Basically, the official version of the XML code that allows players to split stacks of items is broken: When a player splits a stack of items, if the builder has any variables associated with the stack, then they are lost on one stack when the stack is split into two. This can be a problem if the variables are needed, which is the whole point of them being there in the first place!

I addressed this problem with a fix back in February 2013 with this post, but even back then I mentioned the fix may need to be looked at again. And with my latest work on applying poison to stacked items I found that a more robust version of my fix was required to ensure all items kept any newly added temporary properties as well. This latest version makes use of the CopyItem function (which I mentioned back in 2013), while implementing a temporary storage location as the stack is split.

Fix Basic Outline

1) The official splitstack.xml has been edited to call an edited home function with fixed scripting.
2) The new gui_splitfix creates a temporary inventory placeable to help handle item splitting using CopyItem function (which can be used to maintain variables).
3) The same script tidies the temporary environment after finishing the split.

The XML Changes

Note, the default splitstack.xml already has scriptloadable=true, and so the only change comes at the point when the player clicks on the "split button" and the piece of code that operates there. (See image below and the circled part.) Note the following: The original OnleftClick call has been removed, and two new OnLeftClick calls have been added.

UPDATE: Please note that I have added another line in this XML code, which I have not highlighted in the image. It is the part of code within the "inbox" section:
OnUpdate1=UIObject_Misc_SetLocalVarString(local:0)

This is a newer (changed) version of my previous XML alteration.

The New Gui_Splitfix Script

My earlier version of this fix was based upon recreating a copy of the item from an original template, which was fine if the builder considered the need prior to module release. However, this version did not consider alterations to stack conditions after build time, like in the example of poison being added to a stack of arrows. This new script takes such situations into account by basing all splits on the original item rather than referring to a template of it that now potentially differs. Here is the new script:-

NB: Remove the #include line and use the official

"Random" function rather than my own version.

The more robust script, which uses the CopyItem function. 

The Invisible Inventory Placeable

For this system to work, the builder must create a placeable object that the script temporarily uses to help the script to work. This is necessary because the new stack items cannot be placed on the PC during time of splitting as they would be destroyed along with those we don't need once the script has completed. Basically, this placeable is a very small invisible object with an inventory where the stacked items can be "worked with" before returning them to the PC in question. Here is an outline of the placeable object properties the builder will need to have in their module:-

Note: Appearance, Scale, ResRef, Dynamic Collisions, Has Inventory, Plot, Useable and Walkable.

Pay careful attention to the attributes of this placeable object as described in the caption:- Appearance, Scale, ResRef, Dynamic Collisions, Has Inventory, Plot, Useable and Walkable.

Other Module News

I continue to work at the module, finding and fixing any other issues as I encounter them. For instance, I did a quick test run of an area the other day, and noticed the following:-

GOOD: Encounters and environment all worked as they should.

GOOD: AI worked really well, with creatures intelligently summoning creatures, using missile weapons where appropriate and generally healing and fighting well.

GOOD: New interfaces all worked well, including the new inventory system.

BAD (NOW FIXED): A sound file did not fire. Now also has improved method of working for reliable results.

BAD: (NOW FIXED): A visual effect was not working after I had edited the script to work from a conversation as well. I simply separated the two scripts and now both work as they should.

BAD: (NOW FIXED): Dead body removal effect. I have incorporated my own visual effect for when a body "fades" on death (rather than simply disappear after looting). It was failing if the creature only carried gold rather than any other item. I have now fixed the script to recognise gold as well, which turned out more complicated than I first thought, as I needed to make "gold" a standard item rather than use the "gold" as it stands.

Poison! - Althéa Mechanics (Poison Use Poll Added)

A Tempting Proposal?

I decided to take a break from conversations and add a few encounters. One thing led to another (doesn't it always) and I soon found myself learning about how poison works in NWN. So, this week, I have been looking more closely at poison, particularly when it comes to the "item" and how it is "applied to weapons".

In my own experience with the use of it in the game, I have always found it very frustrating to use. First, I considered it very expensive for what it did. Second, I could never make any practical use of it ... I would mess up applying it (i.e. I would accidentally use it on a wrong type of weapon and lose it), and third, it never lasted long enough to be of any practical use if I succeeded anyway! For the Althéa campaign, I decided to address all these issues to make the poison item a useful and tempting item to purchase and use. Here are my results:






You Like This One?

Or Maybe This One?

Stackable Bottles: First and foremost, I changed the "item" type to a "single-use miscellaneous stackable item" so that I could allow potion bottles to be stacked in one item slot, rather than use individual slots with "charges". This allows me to add checks to the two poison scripts that apply poison to weapons and to make sure the player does not lose the item if used incorrectly, by adding the item back if used in error.

Useful Application: Second, I have changed the way "duration" is handled for the poison after it has been applied. In the official campaign, the poison last for 3 rounds. In the Althéa Campaign, I have allowed the applied poison to last for a random 1-3 successful hits. Hopefully, the difference in application should be obvious. And while it is true that a high level character could potentially have had more successful strikes in 3 rounds compared to only 1-3 hits, on balance, the advantage is not being forced to use the poison within the 3 rounds after application. BONUS APPLICATION: If applied to a set of arrows or bolts, then the whole set remain "poisoned" until used up.

Game Feedback: Lastly, I am a great fan of game feedback, and feedback of when the poison is active or when it has all been used is given in the game during combat.

Two Systems: I intend to use both "poison" systems that come with NWN, as they differ in their means of poison application. I will be using the older system for "Simple Poisons", which can only fail application on a roll of 1 on a D20, and the newer system for more complex poisons, which require a dexterity roll to apply. To be clear, however, both systems use my improved checking, feedback and duration improvements, and only differ when skill is required to applying the poison to the weapon.

UPDATE (27/02/14): Due to popular demand regarding stronger poisons and concerns regarding safety, I have done the following:-

1) There will be two types of poisons: "Simple" and "Specialist".

2) The Use Poison feat will be available as a general feat (free for Assassins and Blackguards). Only those with this feat can apply the Specialist poisons without risk to themselves.

3) Applying Simple Poisons: Without the Use Poison feat, a DC check versus the Handle Poison DC is required to apply the Simple poison. On a DC fail the poison vial is simply lost. With the feat, the poison application is automatically successful.

4) Applying Specialist Poisons: A Handle DC check is always required. A normal failed DC check and the vial is simply lost. Without the Use Poison feat, on a critical fail (roll a 1 on a d20) the PC will suffer poison damage unless immune. With the Use Poison feat, the PC cannot harm themselves on a critical fail.

This allows a "safety net" for those that want to use poison without the risk of any injury to themselves (but the poison does less damage), or attempt to apply a "Specialist Poison", which a) Requires a Handle DC check to apply, and b ) Has a risk of self harm when applying if the PC does not have the Use Poison feat.

For those interested, the two "weapon application" scripts used in the game (which I have now edited) are "nx1_s2_poisonwp" (Uses Cast Spell: Apply Poison and the Poison.2da) and "x2_s2_poisonwp" (Uses Cast Spell: Poison Weapon and the des_crft_poison.2da). Alteration of the application duration and in game feedback required me to edit a number of my own scripts. This is quite useful information for those (like myself) who want access to the different poisons that are available in the game.

Stackable Poison Vials! 
(Viewed In The New Inventory System)

Successful Application Of Poison To Dagger

Feedback In Chat Window That Poison Weapon Being Used As Well As Item Visual

 

Notice Text & Chat Window Notification When Poison Finished
(Dagger Visual Fades Within A Heartbeat)