Is this Inconsistent Blueprint Array Add/Append behavior "by design"

[Wambosa (SteelPinion)]

Alright I am shocked about this blueprint array management. I spent some hours troubleshooting this and turns out it has something to do with memory management and possibly a bug.

A bit of background, I spend alot of time programming in javascript and its been awhile since I’ve done c++. That is an aside, but relevant when considering how arrays are allocated and retained in scope automagically in javascript.

I thought I could take that same concept here to blueprints with a high level algorithm of;

“declare an array buffer, add some stuff to it, save it for later”.

After troubleshooting my own actual blueprint, I created these 4 experiments to determine what the heck is going on with arrays. These experiments should result in "final length 3 with new id 7" when successful, indicating the correct number of elements and the proper expected order.

BEGIN EXPERIMENT A
restore id 8
restore id 9
 final  length 1 with new id 7
BEGIN EXPERIMENT B
 final  length 1 with new id 7
BEGIN EXPERIMENT C
restore id 8
restore id 9
 final  length 3 with new id 7
BEGIN EXPERIMENT D
restore id 8
restore id 9
 final  length 3 with new id 7

We can see that experiment A and B both fail. What they have in common is using the “make array” node. Which appears to preallocate a fixed length at creation time. The Add/Append nodes appear to work without error, BUT THEY DONT. They actually just erase the last value instead of appending and altering the size of the array.

So I am thinking that I need to make a paradigm shift and change the way I deal with arrays in blueprints. Hence the success in experiment C & D; they merely allocate the variable as a local function variable or blueprint variable. There must be some kind of difference between the two, and it would be helpful if the node context explorer didn’t mislead us in this way since the resulting entity from “make array” node is not the same as using variable arrays of the same type!

Experiment A

Experiment B

Experiment C

Experiment D

Disclaimer: technically experiment b would expect 4 array elements in the screenshot, but nevermind that cause it fails to ever get past 1

[Mind-Brain]

Hey @Wambosa!

So yes, you do want to promote an array to a variable for reuse as you continue- Also here’s a longer list of nodes and what they do, though granted this is not an exhaustive list!

Array Nodes

[RhythmScript]

I want to say, and maybe I’m mistaken, that the Add and Append functions work a bit like the Increment Int functions, in that they’re taking the input array to act on by reference; you can’t have a valid reference to a Make Literal because it isn’t a variable of any kind, it’s just a value. The act of feeding a Make Literal to any function input is akin to simply explicitly defining a series of values in array format for that input, it isn’t actually any kind of “array” that is pointed to in memory, so you can’t do further operations on it.

As to whether it’s “by design”, Blueprints just don’t distinguish between input validities when it comes to pass-by-ref or copy. If you hook up a Make Literal Int to an Increment Int, it will accept that input, and then proceed to not work. The issue is the engine doesn’t seem to be declaring “this array input is By Ref”, which may be a limitation of Blueprint, IDK.

[Mind-Brain]

Have you tried printing after “Make Array” but before the FELoop? You can also try converting a literal to an integer before plugging it in. Making Literal #'s isn’t usually something I’ve had to do alongside arrays before, but I can make suggestions. Generally you want to convert things into variables, though, before pushing them into arrays.

As far as ref vs copy, any work ON the array to alter it is a reference, as far as my experience. If you need to get a copy, promote the array into a placeholder solid variable before doing so. Then you just use “Get Copy” and plug in the array and index int.

Generally if something made with “Make Array” goes more than one node further, it’s left behind. Good for things like declaring things to seek with sphere traces etc.

[Wambosa (SteelPinion)]

Thank y’all very much for your comments and suggestions. This led me to study the difference between the special increment/decrement nodes as well as how that kind of play might work out for arrays.

In short, the below algorithm worked for what I needed, which is an arbitrary list of keys connected to an unknown list length of values.

Experiment Q

The solution (in step 3) feels “heavy”, yet I understand the need to completely rebuild the struct. I had hoped that the array ref in the struct would be sufficient to mutate it, however this was not the case. There is some behavior that prevents arrays within structs from being mutated (with silent honeypot failure). So a complete regeneration of the struct with all its properties is required for array mutations . (note: steps 1, 2, 4 are boilerplate test code that won’t be in my actual project)

successful output here for solution Q

BEGIN EXPERIMENT Q
confirm item: 6
confirm item: 7
confirm item: 8
item: 6
item: 7
item: 8
item: 9

The default behavior for “make array” is perplexing to me. I think that several of the nodes like array’s add, should also return the mutated array copy for clarity. Also the “make array” is useless for any dynamic case. It should be renamed to “make fixed array” or make static array".

Since y’all got me to understand that an explicit blueprint scoped variable is required for mutations to work, I created this function “MakeLocalIntArray” which behaves like what I’d expect the built-in “make array” to do.

I attempted to move this function into a Blueprint Library, which alters the scope of the variable and breaks the functionality. So this technique only works if the Blueprint managing the array holds the scope of the function making the dynamic int array (which feels like a terrible newbie trap).

Output from using this same function, cept from a Blueprint library

BEGIN EXPERIMENT Q
confirm item: 6
confirm item: 7
confirm item: 8
item: 6
item: 0
item: 0
item: 9

Note: All other experiments E through P either partially worked for my purposes or flat failed. Excluded for brevity