One For Me & One For You (Variable Split Fix)

One of the things I have been looking at since I last wrote is what happens to variables on "stacked items" that are split up by the player to share among their PCs. I had to do this when I noticed one PC, after taking a potion, had less duration for the potion taken than another PC who took one from the same stack.

The problem was that when a player splits a stack of items that have a variable set on them, the variable would be lost on one of the split stacks. Consequently, any code that relied on that variable was affected. In my case, I have some potions that vary in effect level according to a local variable on them. So, to fix the problem, I had to edit the splitstack.xml and create a new script that was called from the xml script, which fixed any splits after they had taken place.

Below is the code from the two scripts that fixes the problem. This version of the fix relies on the builder having an original template of the "item" in question, so that the code can recreate the working object by referencing it. However, I believe it may be possible to make a more robust version of the fix (that does not rely on a template) by using both the CopyItem and CopyObject functions. I might look at that in the future if I ever need that level of fix, but mention it now in case other builders needed such.

The XML Script: splitstack.xml:

I have highlighted the only changes needed for this campaign original XML script.

As always, please be sure to only work on copies of any official campaign scripts, and place your edited copies into either a campaign or override folder, so they are referenced rather than the original.

The gui_splitfix script:

The script that handles the callback when the player clicks OK from the split GUI.

And here are the results:

Player is about to split a stack of ten potions (That have a variable set on them).

New confirmation feedback says what the player has just split.

Debug feedback shows the first stack has kept the variable of 2 when the potion is used.

Debug feedback also shows the second stack has kept the variable of 2 when the potion is used.

One thing that I discovered during this fix, is the way to have the object that the player is targeting made available to the coder via the use of the following function in the following manner:

object oTarget = GetPlayerCurrentTarget(oPlayer);

This will be useful to other coders who may wish to alter other aspects of GUI targeted objects.