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.|
The gui_splitfix script:
|The script that handles the callback when the player clicks OK from the split GUI.|
|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.|
object oTarget = GetPlayerCurrentTarget(oPlayer);
This will be useful to other coders who may wish to alter other aspects of GUI targeted objects.