Instance Index Change

For anyone who is interested in a solution, here is mine:

As setup, after every instance added 2 references are made. Each is a map variable, but one with an inverted Key and Value.

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!

2 Likes

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:

  1. 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.

  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.

1 Like

Sorry to bring this up from the depths, yet again!
But, for those browsing to this page…

I put together a quick blueprint of a component which inherits from the regular HISM.
But adds an permanent integer ID to each instance and tracks them for you when adding and removing while using the available functions.

It also includes a way to convert Permanent ID’s into instance ID’s, and vice versa, allowing you get the instance ID from a line trace (Hit Item), and using the functions to look up the Permanent ID if required.

The uasset is attached below for anyone who wants to use it. Added some comments in the blueprints explaining the function uses:

HISMwithPermanentID.uasset (149.1 KB)

Enjoy! :slight_smile:

(Just don’t use the regular HISM add/remove instances, or it will not record the permanent ID’s)