Allow an upstream node to "wait" for a downstream subgraph to complete execution.

[bhouston]

This is required for the "for loop" node in Unreal Engine and Unity Visual Scripting.

https://docs.unrealengine.com/4.26/en-US/ProgrammingAndScripting/Blueprints/UserGuide/FlowControl/

Also required by "Sequence". These nodes wait for the subgraph connected to their output flow socket to execute and then they will pass execution to either to the same output flow socket (loopBody) or to another flow output socket (complete.).

[DennisSmolek]

Following up,

You would know better than I do (especially because I rarely touch Unreal)

but I was curious about the scenario you described, as it’s similar to common JS for loops being synchronous, thus “waiting”.

I remember all the headaches when things like async http calls became standard and code wasn’t ready for non-blocking..

But all the discussions I’ve found seem to say it’s as I expected and non-blocking:

https://forums.unrealengine.com/t/forloop-is-non-blocking-learn-it-the-hard-way/59127

https://forums.unrealengine.com/t/waiting-for-to-finish-before-continuing-foreach-loop/382460

there’s some stuff about frame execution and a few videos where people create their own to add a delay, but I couldn’t find anything about a “wait”

again I could be totally wrong and just didn’t dig deep enough

[bhouston]

It is complex.

The problem is that you need to cause the downstream graph from loopBody to fully execute (at least the non-async nodes) before you fire it again. The reason you need to do this is otherwise you could have two loopBodies executing at exactly the same time. Given my current implementation that is a work queue, if you fired them all immediately you would have a series of items immediately inserted into the work queue basically all being the same -- loopBody.

This can not be how Unreal Engine Blueprints work. Because their for-loop construct actually supports "breaking" the loop. In order to support breaking the loop, you can not immediately schedule all loopBody iterations for execution -- or you run into the problem you now need to cancel scheduled tasks, which is basically just the same problem I am trying to solve but in a different way.

I believe that the for-loop node waits for the non-async execution of loopBody before triggering that subgraph to evaluate again. This would allow for one to break the loop. I believe that it doesn't wait across an async node though, like Delay. If you have a for-loop with a delay node in the loopBody subgraph, it will not wait for anything after the delay node.

This is what I was thinking of implementing.

So basically I will support something akin to this:

const startIndex = 0;
const endIndex = 4;

for( let index = startIndex; index < endIndex; index ++ ) {
  loopBody( index ); // note: no await here.
}

But just like JavaScript if you add an async call within the loopBody function, the for-loop will not wait for it, but if you avoid async nodes, it will wait for them.

If you put this loopBody into the above for-loop,

async function loopBody( index: number ) {
  console.log( `start: ${index}` );
  await sleep( 1000 );
  console.log( `end: ${index}` );
}

You will get this output:

start: 0
start: 1
start: 2
start: 3
end: 0
end: 1
end: 2
end: 3

But if you put this body into the for loop above:

function loopBody( index: number ) {
  console.log( `start: ${index}` );
  console.log( `end: ${index}` );
}

You will get this output:

start: 0
end: 0
start: 1
end: 1
start: 2
end: 2
start: 3
end: 3

I am looking to replicate exactly this behavior. I want a standard for loop and if you put in async nodes into it, it will not wait for them.

[bhouston]

@DennisSmolek I have implemented support for ForLoops and Sequences via waiting for downstream evaluation. It works well:

https://github.com/bhouston/behave-graph/pull/75