BIOBUG - GetItemStackSize, GetNumStackedItems

couldn’t find this bug reported anywhere so thought i’d post it here, so we could all be miserable together. i found the bug after i caught one of my players using an exploit. the player runs a druid and the bug was occurring in the context of a locally-developed spell, ‘fire seeds’. turns out the player wasn’t being dishonest ; rather, the game software *gasp * has a bug

suppose you have a stackable item with a spell script attached. if you use GetItemStackSize or GetNumStackedItems from within the item’s impact script to get the number of elements in the item’s stack, the return values are unreliable. the value returned is actually one less than the stack size in all cases but one – where the stack has only 1 element left. in other words, most likely some inventive soul over at biowere guarded the boundary condition return value by saying ‘if it’s less than 1, return 1’. >:( this results in a situation where the functions return 1 for 1, 1 for 2, 2 for 3, 3 for 4, and so on.

i haven’t found any published solution, nor have i been able to come up w/a work-around. caveat codor. :confused:

[fwiw, by way of atonement, the pc in question proposed to make a ritual sacrificial offering of quinoa and tofu harvested with a golden sicle at midnight.]

Only a sacrifice if they have to eat the quinoa and tofu.

Have you considered reporting this to Beamdog over on their Redmine bug tracking system?

-Dave

Slightly puzzled by this - items don’t have scripts, do they?

Perhaps the issue is with the custom spell script?

I’m speculating that casting the spell might be reducing the stack size by one before the spell script runs (or something like that).

Suggest you post the script and clarify the context in which it runs.

@shadguy i will do that, excellent idea !
i’ll also see what i can do to add a fixed version of this to nwnx_funcs ; i’ll be working on finishing up a submission on sunday, i’ll try to work this in.

@Proleric

Slightly puzzled by this - items don’t have scripts, do they?

sure items can have scripts. every time you read a scroll or fire a wand, you’re actually running a script. each time you throw a grenade, you run a script. when you cast ‘flame weapon’ on a weapon, you’re actually imbuing that item w/the potential to run a script each and every time it hits. every time you select ‘activate item’ on an item’s radial, you’re running a script.

Perhaps the issue is with the custom spell script?

not in this case, no.

I’m speculating that casting the spell might be reducing the stack size by one before the spell script runs (or something like that).

yes, i think that’s exactly what’s happening. if that is the case, the reasonable return value for a stack that had 1 element before invoking the impact script would be the actual value [i.e., 0], not 1. the only reason they’re returning 1 is because they [shortsightedly] specified 0 – a LEGAL return value, as it turns out – as the error return value, so they’re most likely ‘artificially’ changing the return value in a guard condition.

Suggest you post the script and clarify the context in which it runs.

will do if i get the time. won’t be before sunday, at any rate. if you want to try it out yourself before then, it’s not difficult. one possible way –
1- in a new module, put some grenades in the start area. grenades are useful for this test bc they’re stackable and already have scripts associated w/them, so you don’t have to jump through as many hoops.
2- edit the item’s impact script to call GetItemStackSize(GetSpellCastItem()) and spit out the results with SendMessageToPC. you’ll need to click the editor’s radial button marked ‘all resources’ and search for the biowere grenade-like impact script for the item you chose in step 1 in order to get at the right script. these will all start w/x0_s3_ or x2_s3_. for example, if the grenades you chose in step 1 were thunderstones, you would choose the script x0_s3_thunder [ehr… i think… :wink: ].
3- run the module, throw the grenades, and wallow in the lavishness that is Despair by BioWere®.