While I’m not sure this applies to this specific Blueprint – I’d need to go dig into how the Blueprint stuff is implemented under the hood – in many languages there can indeed be situations where you do want to reverse the loop for something like this.
For instance, say you have a validating array class that will remove any invalid item from it. (Such as an actor that’s no longer around.) If you iterated forward, it would be like:
- Get first item (position 0 in array).
- Destroy the item.
- Because array validates, the first item is removed and everything shifts down a space. Item at position 1 is now at 0, etc.
- Get second item (position 1 in array).
- Since everything shifted down one, you’re now missing the actual second item (which is now in position 0).
- Destroy the item you got.
- Because array validates, everything shifts down a space.
- Get the item at position 2.
- Since everything shifted down, you have items at position 0 and position 1 which you’re skipping.
- Etc.
Whereas if you iterate in reverse order, you get the last item… and the array doesn’t rearrange when it’s destroyed. Then you get the next-to-last item, and so on. So you actually do go through the whole array.
While I do not know offhand whether this is true for Blueprint or not – thus whether it’s the root cause for you – this is why I’ll generally do a destructive operation (like what you’re doing here) in reverse order, just in case there’s an implementation detail under the hood about how it’s iterating that I’m not aware of.