Basically, I got two for loops, one inside the other, a variable is reset in the outer loop before starting the inner loop; the inner loop adds various values to it, and then I write the result to an array when the inner loop completes. But things are behaving weirdly; I’m not quite sure how to describe it, but there seems to be some spatial patterns (when the contents of the array are visualized as a pixel array (the array is arranged in rows and columns, with brightness proportional to the value stored on each “position”), there are shapes) even though each point in the array has no reason to act different due to their position in the array, the same code is running for each point, and I’m writing the results on a temporary array and only replacing the original array after the outer loop is done.
Odds are I got something wired wrong, the BP is a mess; but I’ve been trying to figure out where it is going wrong for a while with no success. Are for loops executed in parallel instead of in sequence? Does anything change with nested loops? Is the stuff connected to the “Completed” exec executed before the loop ends under any circumstance? Can you think of anything, other than a bug in my logic, that could be causing the order things are executed to affect the calculations?
ps:I’m not sure if it would be worth to post a screenshot of the BP ; like I said, it is such a mess that even me, the author, am having a hard time reading it…
pps:I do got some background in amateur programing, but when it comes to UE and blueprints, I’m mostly learning as I go; so maybe it’s just some dumb mistake on my part
Actually the problem might indeed be the loop. This is the macro itself (you can view this by double clicking it).
However it’s also likely that whatever logic you’re applying in blueprint takes some amount of time per-iteration. Especially if you’re using nested for-loops. example .
And you can see what happens when I put this on my begin play (with a small delay before)
A solution may be to move your internal loop-segments into a function with a return node. Your inner loop and outer loop would be separate functions, and you would either make your own custom macro or BP event to loop through your data manually.
Maybe something like this (as an example)
1 Like
Hm, alright, thanx; I’m gonna try to recreate the loop functionality enforcing execution order.
Btw, are there any other commands I need to worry about stuff after being executed before they’re done? Does that happen with custom functions?
The most common instance I can think of would be in the for loop macros. Custom functions would only return (progress down the execution wire) after they’ve finished working, but the logic behind when they consider themselves ‘done’ might be fuzzy or work in an unexpected way, which is why I suggested an explicit return node. You’ll have to give your function an output though. If you keep your functions small it shouldn’t be a problem anyway.
Hm, does this look right?
Is “Local integer” local to the macro itself, or the context where the macro was inserted? I mean, does one instance of the macro affects the Local integer of the other, when one is calling the other, or each will create it’s own variable?
Each would have it’s own instance of the variable.
This macro should loop fine provided you put your ‘loop’ logic off the Loop output, and once the logic was complete you brought the execution back to ‘Loop More’. My only criticism might be that you aren’t using a local int for ‘end’, but provided you aren’t changing the value passed in, it’d be fine.
That’s the idea, each iteration (after the first one) is triggered by the end of the previous one. And then when the index reaches/passes the end value, the Completed exec is triggered instead.
End is not expected to change.
But just out of curiosity, what would be the right way to do it if it was?
Hm, then I’m back to square one; even with the more robust version of the loop, things are still behaving weirdly 
Oh well, now at least I know it is not a waste of time to keep looking for bugs in my code…
Possibly processing a size change during the loop; not sure. Just be sure to validate any index if you’re using it for your array. Nothing bad would happen if you change the value to something nonsensical- or if it did you’d get an error.
Might be your logic then, I can’t help you without seeing it.
Hm, I think I found the issue; doesn’t make sense but changing one thing got rid of the spatial patterns in the array.
I have a function that reads from the array, but for certain indexes it actually reads from elsewhere; to more easily visualize what it was reading, I had it writing back into the array what it read, even if it read from the array itself; by skipping the command to write back, the pattern is gone now.
Things are still not behaving as they should; but at least now that obvious bug is gone.
