Widget positions backwards after package (maybe array problem)

In my game, I have papers in 3D space and I am overlaying a 2D widget image (arrow) over top to act as a menu choice. The arrow’s position is relative to an array of decal components. It lerps to the position of each decal component based on an index (with an offset).

For reference, here is how the paper object is set up. At the start of the level, I append all of the decal locations together into an array of all of them.

I use inputs to add or subtract from an integer variable that serves as an index for which array element should be chosen.

I then lerp an actor (A_SelectArrow) to the specified position based on the index and array built earlier.

Then, finally, I set a widget image (arrow) to the position (converted to 2D widget space) of the actor.

This works perfectly in-editor during previews. It works windowed, maximized window, and in the main viewport.
The expected behavior is that pressing up and down will move the arrow vertically through the list of choices. Moving left and right moves the arrow between columns.

Unfortunately, when I package the game (for windows), the up/down menu selections are backwards. Left and right move between columns appropriately no matter what. But once the game has been packaged, pressing up (on keyboard or gamepad) move the cursor down and vice versa.

I don’t know if this means the arrays are getting built in the wrong order or it is a positioning problem, but I can’t seem to make it work after packaging.

Thanks!

So it seems the array-writing in UE4 is different in preview and packaged mode. The editor reads through arrays of components in the order they were added to the actor (I had done this backwards, but it worked so it was fine until I packaged), whereas the packaged version of the game reads through them in what I presume to be alphabetical order. The only workaround I could manage was to select each component manually instead of looping and build the arrays myself.

So I still think it is a bug and would be awful on really complex objects, but this workaround at least got me to have the same behavior before and after packaging.