Before an Instance is removed the data (in this example only a float as an ID) of the removed Instance and the data of the last index are stored in two variables.
After this, the Instance is removed, and the references are updated with the two variables with the stored data.
*Rarely, I don’t know why, but in the “ID to Index” remains some extra references, which didn’t cause me any problems yet, but I think it is worth mentioning it.
If anyone has any better solution or an idea to improve this, it’d be great to hear it!
Sorry to bring up this from the depths.
ISMs or HISMs if you do a remove, even if they ‘swap’ any specific index for the removed one… is STILL reordering that ONE index (the last one.)
So if you have an Array of 4 items, 1/2/3/4
You remove Item 2:
1/2/3/4 becomes 1/4/3/2 and then 1/4/3 with 2 removed. 1 and 3 stay ordered, 4 is now incorrect. As you continue this, it just continues to get worse.
There are two ways to work with the issue:
Store the Transforms External to the ISM, modify them, and apply ‘clear instances’ ‘add batch instances’ each frame(or on changes) that ensures the order is as expected. This just ensures YOU know what index is swapped. As removing and swapping for last is doing that same thing, you need to adjust your trackers to move what was a reference to index 4, to index 2.
The other option, is to pool your removed ids. This is the best option.
Set the scale to a low amount (0.1) and place it outside your world. Track your pooled ids, and use them for adds as well. Leads to less ‘clear instances’ and more ‘batch updates’ instead of batch adds. No index swapping happens at all, all index references stay good.
