Print String changes previous nodes

[CapCapCaptain (Steve)]

Hey all,

we ran into a super curious behavior in a blueprint, that goes against how I thought blueprints execute code: A Print String node changes the way previous nodes are executed. It’s a bit iffy to debug, since printing the value causes the issue.

Here’s a minimalistic setup:

Pressing the buttons 1, 2 and 3 should set the z-scale of a cube to 1/1, 1/2, and 1/4 respectively. Since the divide node uses two integers as inputs, and outputs a float, the result is truncated to 1/1=1.0, 1/2=0.0, and 1/4=0.0. So far so good.

But as soon as we plug in the Print String node (or any node that uses the result of the divide node), the divide node casts the integers to floats before the division, and the results are 1/1=1.0, 1/2=0.5, and 1/4=0.25. It doesn’t even matter where the Print node is plugged in; it doesn’t even need to be called. As long as it’s compiled, it changes the way the division node works.

The same thing happens when we use a Set Variable node for example:

Can somebody explain this?

Here’s a minimalistic blueprint you can use to check it out:
BP_FunkyPrintStringCube.T3D (155.0 KB)

Cheers

Edit: Phrasing

[ClockworkOcean]

There’s a lot going on in the math nodes since UE5.

Best thing is to stick with the variable type you actually want and convert it explicitly later, if you want.

[Everynone]

Freaky. I’ll add my 2¢.

---

@CapCapCaptain

it doesn’t even need to be called. As long as it’s compiled, it changes the way the division node works.

Can’t replicate this part. Under UE v5.3.1 this behaves ok [results in 1.0, 0.0, 0.0]:

We evaluate only once above. But this, this is bonkers [results in 1.0, 0.5, 0.33]:

In a nutshell. Evaluating for the 2nd time seems to use stale / cached result from:

Which does go against the behaviour UE has been showing thus far.

[Arodi007]

That weird indeed, having 1 evaluation (1st print string) connected only give 0.0 but 2 evaluation(both print string) give 0.5

If no variable is connected, it will return 0.0 tho

[RecourseDesign]

Copying/Pasting operators that you’ve changed the promotion on can get really screwed too - definitely looks like there’s a bug in there somewhere.

[Everynone]

There’s a handful of bugs in the DB regarding type promotion, some backlogged with target fixes in v5.5… But I could not find anything related to this very issue specifically.

[CapCapCaptain (Steve)]

That’s so curious. I’m glad you’re all able to reproduce it and I’m not going insane.

@ClockworkOcean

Best thing is to stick with the variable type you actually want and convert it explicitly later, if you want.

Absoutely agree. It’s definitely not best practice to let blueprints implicitly cast int to float. Still, absolutely bonkers results imo.

@Arodi007

If no variable is connected, it will return 0.0 tho

That’s so strange. So the issue definitely seems to come from the implicit conversion inside the divide node?

[Arodi007]

Yes it seem both input get promoted to double only when using a variable.

[CapCapCaptain (Steve)]

I submitted a report, let’s see what they make of it