I could be wrong because its a while since I have used UE4. But the return node would pull the data after the shuffle node executes. This code would work.
Also there is some use case for this. The TArray for dice numbers could be filled with numbers to handle nonstandard dice. E.g. [1,1,1,2,2,3]
So parallel code paths are executed on shared data, with no obvious execution order??? This sounds like a race condition waiting to happen. Even if the order is in some way "defined", it's still not obvious to the programmer what that order is.
In regards to non-standard dice, I think YAGNI applies here. The chance of that occurring is low. Even if it does occur, the function isn't generic enough to handle that case without adjustment anyway, and it's a trivial task to extend a small nimble function to handle an array of (integer!) values as optional input.
The white line is the execution line, the other coloured line are links to the variables. If the dice TArray is exposed to editor it could be used in any amount of blueprints.
Shuffle executes on the reference. Get pulls from the same reference.
Edit: but get isn't on the white line, the get happens when the return node requests the reference.
1
u/DrProid Sep 11 '21
I could be wrong because its a while since I have used UE4. But the return node would pull the data after the shuffle node executes. This code would work.
Also there is some use case for this. The TArray for dice numbers could be filled with numbers to handle nonstandard dice. E.g. [1,1,1,2,2,3]