SetItemCharges(oItem,0) does not set an item's charges to zero
Has anyone else had this problem?
Setting charges to a positive (>0) value works.
Setting charges to zero or a negative value is seemingly ignored (as verified by a GetItemCharges() immediately after).
Regards.
Setting charges to a positive (>0) value works.
Setting charges to zero or a negative value is seemingly ignored (as verified by a GetItemCharges() immediately after).
Regards.
0
Comments
I feel like there's a disconnect between this function and the 'uses per day' item property.
Go figure, there's SetItemPropertyUsesPerDayRemaining. Maybe changing to 'uses/day' will work better for you?
When an item is flagged plot and has 1 charge and you use a 1 charge/use ability to thus have the item have 0 charges, the item is not actually destroyed. If its not set to plot the item will simply vanish (there may be other circumstances to cause this but this is the usual). This is without any scripting.
However setting an items charges to 0 does not actually attempt to do that at all instead it runs DestroyObject. This is why you're having your troublesome experiences.
You can tell this because if you set a script to set charges to 1 and then add in a line about returning the charges on the item, you'll actually get a return of 1 immediately. If you set it to set the charges to 0 however it'll return whatever charges was on the item before - it never even attempts to set the charges to 0. This behavior is completely consistent with DestroyObject, because DestroyObject fires after the script finishes; set charges would of returned immediately if it actually worked or tried to work. (Its also why crawling through inventory items and trying to delete them results in a stack overflow if you just repeatedly get the first item in inventory, on the bright side people who read this can make more confounding scripts that set items to zero charges to delete items; though on the off chance the function gets patched your scripts would break XD).)
It's a bit of a bummer really because you can use an items charges in a quick bar to give real time feedback to a player since the number of charges will show up, but whatever you might want to track up to the maximum can never bottom out to zero. But for any other use case you can use locally store variables to simulate charges and give feedback with name/description/player messages/etc and then that can bottom out (if you want the item to display a number based on charges you could do that too but just never lit it drop to 0 where it'll just be destroyed).