Ah, the footguns of visual programming. Having a diagram creates certain expectations about the execution order, but the devil’s in the details and from a cursory google search, it doesn’t look like the details are well-specified.

In your diagram, without knowing how Unreal Engine works, I could come up with several different execution orders for the node.

For example, if the outputs “pull” from the inputs, then the first node to execute would be whatever is connected to the output of your whole blueprint. It’s a functional programming paradigm, and in that paradigm the “IsValid+Branch” node would execute before other nodes.

On the other hand, if the paradigm is imperative, then the inputs are being “pushed” through to the outputs, so that the “Get Surface Type” node would be the first to run (if your “IsValid” node is absent).

Mix in the concurrent execution, and it gets even merrier. From what I’ve gathered, it looks like the execution order is “push”, and there are no guarantees in which order the concurrent nodes get executed. In fact, even the Sequence node has a footgun in that it creates an expectation of sequential execution, but that expectation doesn’t work well with async nodes like Delay.

But even if the node execution order is well-specified, the logic of each node might also have ambiguities and should be well-specified. For example, in “IsValid+Branch”, what is evaluated first – the validity of the object pin or the condition?

Fortunately, we’re teaching kids to code in schools these days, so maybe one day we’ll get a generation of devs that will dislike being forced to deal with unnecessarily gigantic and poorly documented diagrams, and the engines will give them an option to work with a decent scripting language.

Not that diagrams don’t have their place, but there’s a cutoff point where their complexity becomes a liability, rather than an asset.