I’m having a darned weird bug here. I calculate a value, then store it in a variable using a **Set **node. However the value at the **Set **node doesn’t match the value as computed!
I have attached a screenshot below to show what I mean. In it I am looking at two values, and in both cases the value just prior to the **Set **node and the value **in **the **Set **node do not match. The Value in the Set node is incorrect.
You can’t tell because this screenshot is actually a composite so I could show both things at once easier, but in each case the values were taken with the execution pointer being on the Print String node immediately after the **Set **node in question
To my knowledge, you’re calculating the value twice, once to set “Chosen Mineral Amount” and again to print the string, try getting the “Chosen Mineral Amount” and plugging that into your append string
Yeah this is as expected, the random node is hit twice so you are getting a different value in each case. You can simply pull out the pin from the SET node instead to get the correct value after it is assigned. Like this:
I was always confused by this. I think it makes no sense that one random node outputs a different value when it’s called again later in the same “sequence” of nodes.
I just do it the “correct” way as Zenity described from experience by now.
However it certainly was confusing the first few times, so it’s good to see it’s (presumably) intended to be like this.
It’s totally ok that the value is different. Even though the main life line is going from left to right, as soon as you have an input in a node, it will go from right to left.
Means:
First time calling the Random is at the SET ChosenMineralAmount node. It will go to the “RandomFloatinRange” and then check “Min” and “Max” etc.
Now at this point, there is no point where this RandomFloatinRange node could save its value alone. The value that the node created is saved in the
ChosenMineralAmount variable. Now this call is completed and the code moves on, going to the “PrintString”. Again moving from right to left over
the Append, the Cast and finally, again the “RandomFloatinRange”. Now this whole thing is called again, resulting in a new random number.
So i think this is pretty normal and straight forward. You could thing about duplicating the Random nodes for each node if you can’t imagine why it
gives different values in the same chain and call.
If you are familiar with coding, you can think about it being called for the variable and later for the print again. If you don’t use the saved value, you will
get a new one. Only BPs allow us to use a function (the RandomFloatinRange at this point) twice, without copying it, because we can just reuse the wire.
That’s why it is confusing i guess.
It’s also worth noting here that when you are dealing with a green node that does not require an execution wire in/out, like the case is with any “Get Random [something]” they are in fact executing pure functions, which means that they are guaranteed to execute fully every time you pull a value out of it, and the output value is guaranteed not to be cached anywhere internally in the BP at runtime, contrary to what can happen in ordinary “impure” functions.
Since there are two float wires leaving the GetRandomFloatInRange node, which is pure, getting the same value on both wires would qualify as a bug (except for the rare chance that two adjacent random numbers just happened to be same of course).
So… green node without execution pins = pure function, always called, value never cached.
Doh! Thank you everyone. I had actually been bit by this bug before which is WHY I was saving my variables for later re-use. But my code was giving bad results so late last night I was frantically throwing in Print statements to track it down, which led me to this, which turns out was a red herring. The real problem was simple logic (I was using a Max when I should have been using a Min).
But tired people make for stupid mistakes. Thanks all for pointing it out so I didn’t waste even more time on a dead end.
