Advice for item stacking issues

[Legacy_Shadooow]

               I was solving one paticular stacking issue yesterday and I found out quite interesting informations.

Any item that has the same baseitem, same tag, same number of itemproperties and same number of charges will stack with each other. Item resref, name, description, extra cost, plot/stolen/cursed flag doesn't matter, neither even itemproperties - they can be totally different, but once two items have same ips count they might stack.

That might be especially troublesome for miscelanious items with special power that shares the same script thus also tag which was my case.

I was looking for way to make my misc items nonstackable but the only reliable solution I found was create this object via CreateObject and change tag to random tag of 8chars. So in the end I rather abadoned tag based scripting and gave these items different tag and added the code into OnAcquire event. They can still stack with each other, but thats OK.

Hope that helps someone.

EDIT: this of course applies for default NWN, NWNX has a way ho to disable stacking on two items with different variables etc.
               
               

               

                     Modifié par ShaDoOoW, 08 janvier 2012 - 03:15 .
                     
                  

            

[Legacy_Lightfoot8]

               interesting,   Instead of killing TBS all together,  You could try a system that trims the Tag mane for the script to run.   example,  modify the GetUserDefinedItemEventScriptName(oItem) function from x2_include switches to trim the first three characters from the begining of the tag instead of adding three.
               
               

               
            

[Legacy_henesua]

               regarding tag based scripting. It is very easy to run a script with a name based on a part of a tag instead the whole tag. I did this by only reading the tag up to the first delimiter, but not look beyond the delimiter. You could of course choose to handle this differently.

So I use the underscore character to define the "tag" within the tag. This is important for keys in my mod.

all of my keys begin with the tag "key_" and run a script called "do_key" everything after the undescore is ignored by the tag based script system. I just added a trim function to it. The "do_key" script however reads the entire tag because the rest of the tag contains other information taht all keys use.

Anyway... your mileage may vary.
               
               

               

                     Modifié par henesua, 07 janvier 2012 - 12:14 .
                     
                  

            

[Legacy_Shadooow]

               

Lightfoot8 wrote...

interesting,   Instead of killing TBS all together,  You could try a system that trims the Tag mane for the script to run.   example,  modify the GetUserDefinedItemEventScriptName(oItem) function from x2_include switches to trim the first three characters from the begining of the tag instead of adding three.

yeah thats possible but I inherited this module and there are already plenty of tagbased items, doing this globally would make them do nothing unless i would manually resaved script for correct name. If I would start doing my mod it would be fine, but not in my situation and lazyness '>

Currently most of my miscelanious item uses the random tag solution so they cannot stack and the activate item power is resolved in OnActivate via resref.
               
               

               

                     Modifié par ShaDoOoW, 07 janvier 2012 - 12:19 .
                     
                  

            

[Legacy_Lightfoot8]

               Yea, I agree.
               
               

               
            

[Legacy_WhiZard]

               

ShaDoOoW wrote...

I was solving one paticular stacking issue yesterday and I found out quite interesting informations.

Any item that has the same baseitem, same tag, same number of itemproperties and same number of charges will stack with each other. Item resref, name, description, extra cost, plot/stolen/cursed flag doesn't matter, neither even itemproperties - they can be totally different, but once two items have same ips count they might stack.

That might be especially troublesome for miscelanious items with special power that shares the same script thus also tag which was my case.

I was looking for way to make my misc items nonstackable but the only reliable solution I found was create this object via CreateObject and change tag to random tag of 8chars. So in the end I rather abadoned tag based scripting and gave these items different tag and added the code into OnAcquire event. They can still stack with each other, but thats OK.

Hope that helps someone.

I'm thinking there is more to this than identical IP number counts.  In HotU the default poison arrows (2 IP) stacked with the acid dealing poison arrows of the drider (3 IP).  Also, I believe, the plot fire opal in the OC (which originally cast fireball) had the fireball cast spell removed because it could cause other fire opals it stacked with to cast fire ball; the end result was a plot fire opal that could mark other fire opals it stacked with as plot and thus unsellable.
               
               

               
            

[Legacy_Shadooow]

               

WhiZard wrote...

I'm thinking there is more to this than identical IP number counts.  In HotU the default poison arrows (2 IP) stacked with the acid dealing poison arrows of the drider (3 IP).

Negative for me in 1.69.
               
               

               

                     Modifié par ShaDoOoW, 07 janvier 2012 - 09:58 .
                     
                  

            

[Legacy_WhiZard]

               

ShaDoOoW wrote...

WhiZard wrote...

I'm thinking there is more to this than identical IP number counts.  In HotU the default poison arrows (2 IP) stacked with the acid dealing poison arrows of the drider (3 IP).

Negative for me in 1.69.

Not finding it now either, though this was reported beforehand.  Looks like the IP count was one of the "fixes" in a "recent" patch.