Skip to content

Prevent Sync blocking if added after the parent node - #71

Open
Ivan-267 wants to merge 1 commit into
mainfrom
Ivan-267-prevent_blocking_on_ready
Open

Prevent Sync blocking if added after the parent node#71
Ivan-267 wants to merge 1 commit into
mainfrom
Ivan-267-prevent_blocking_on_ready

Conversation

@Ivan-267

@Ivan-267 Ivan-267 commented Jul 18, 2026

Copy link
Copy Markdown
Collaborator

The main supported method for using the sync node currently is to add it initially to the training scene.

However, if you add the sync node later (e.g. in code) after you've initialized the scene, its ready method will not complete.

This should address that specific scenario without altering functionality otherwise (note: yet to be tested).

There is a related issue here: #55

Sync will now only await parent's ready signal if the parent is not already ready.
@stefanfausser

stefanfausser commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Allowing to dynamically add a sync node is a very good idea.

I have not tested this but have had a look at the code:

Following line is removed:
await get_parent().ready

and then replaced by these lines:

var parent := get_parent()
if not parent.is_node_ready():
    await parent.ready

However isn't this the same as:

var parent := get_parent()
await parent.ready

Because await parent.ready is not waiting when the parent node is already ready?

I only see a difference between the original line and the replaced lines, when await.parent.ready is waiting even when the parent node is ready.

Maybe the code is doing something else I am not currently seeing?

@Ivan-267

Copy link
Copy Markdown
Collaborator Author

If the parent node is already ready, that means the ready signal was already emitted as well.

In the standard use setup that's fine, sync's ready will be called before the parent is ready, and the await is used to allow the scene to load (so that we have available aicontrollers).

However, if you were to add the sync node after, then its ready method would be awaiting a signal that will not be sent again.

@stefanfausser

Copy link
Copy Markdown
Contributor

Thanks, that explains it. So without the if-condition, the sync node would wait forever for the ready Signal that will not be emitted again because the parent node already is ready.

@Ivan-267

Copy link
Copy Markdown
Collaborator Author

Thanks, that explains it. So without the if-condition, the sync node would wait forever for the ready Signal that will not be emitted again because the parent node already is ready.

That's correct. It's fine for the standard use case as in the examples, this just adds the option of adding the sync node later.

@Ivan-267
Ivan-267 marked this pull request as ready for review July 24, 2026 17:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants