Well, he did say "could" so likely not intimate knowledge of the engine.ShadowHeart wrote: 8 hours agoAre you speaking from actual knowledge of how the game engine works, from having read the reversed engineered code? Or are you just throwing around programming lingo? It might be like you say, but I'm curious.Tornado_OLO wrote: 8 hours agoOnce the items are stacked, the stack could become an array filled with items.
So an array filled with IDs.
But realistically, that (or some way close to it) is how it would have to work if it were to be implemented in D2:R for the exact reason you already brought up: item IDs.
If they didn't need the unique IDs for their anti-dupe or if the anti-dupe were instant, you could simply attach a "quantity" value to items to simulate a stack and basically have them work exactly the same way Arrows already do. But doing so means you're turning multiple items into a single one and losing the extra data for them, meaning unique item IDs would be lost on stacking.
To counter that, since their anti-dupe requires those IDs to be preserved, you would have to end up with some form of array(-like) stacking where you don't necessarily need to preserve everything about each stacked item but would at minimum have to add an array/list property to the item to fill with all of the unique IDs in the stack. De-stacking could then pick one from that list, remove it and attach it to the de-stacked item.
Plus the entire anti-dupe would then also need to be adjusted so it searches said list/array to specifically remove only the duped ID in it, rather than the entire stack.
Or you do an active dupe-check on every 'stack' action after which you could remove the ID and merely generate a new one on each un-stack. But that's probably not too performant of an approach.
Schnorki
4110Moderator