Closed 4Luke4 closed 4 years ago
UPDATE: if the position
parameter affects only new item additions (i.e., existing items are kept in place), then I can see why the item does not get relocated.
However, the stack
parameter does not get updated, so you might want to check that out...
Yes, the position argument only applies for new items added by the function. stack
seems to get updated. It's 5 in the vanilla store and 1 after the code has run. It's set to 1 because you supplied the unlimited supply flag.
Yes, the position argument only applies for new items added by the function.
stack
seems to get updated. It's 5 in the vanilla store and 1 after the code has run. It's set to 1 because you supplied the unlimited supply flag.
OK, so you're saying it doesn't matter if it's 0
or 1
.
I mean, for vanilla items the stack
parameter is set to 0
when the unlimited supply
flag is set to 1
(see BOLT01
, same store as before...)
Since the code has been in use for something like a decade, I'm going to guess 0 or 1 makes no functional difference.
Since the code has been in use for something like a decade, I'm going to guess 0 or 1 makes no functional difference.
Fine, closing this one...
I really did not mean to sound snarky or anything. I don't know that 0 or 1 are functionally identical, but rather than looking into it, I'm guessing they are, or someone would by now have discovered that WeiDU could not add working unlimited stacks to stores.
Example code (BG2EE)
After executing the aforementioned piece of code, open Nearinfinity and inspect
RIBALD.STO
. You'll notice thatAX1H01
is still first (should beLAST
as per+
).Anyway, I'm not sure this issue is relevant if @Argent77 's ADD_STORE_ITEM_EX is meant to replace ADD_STORE_ITEM...