Move Node2D with child Area2D using threads?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Micky

I’ve been having a peeve for days which I don’t think has a solution, but it’s worth asking either way. As a training to learn the engine I wanted to recreate some elements of Bloons Tower Defense, the most important being, the track the Bloons go through. Very simple, I set up a Path2D and a custom PathFollow2D, the latter of which will be a bloon, set up to move forward until the end of the track, which also contains an Area2D to test for collisions against projectiles.
But, I had noticed that, with a lot of Bloons, the performance took a massive hit, and thought that it may be possible to optimise it, by splitting the movement into multiple threads.
As expected, the game does run better, but the Area2D works unexpectedly if the threads are greater than 1.
Through a lot of debugging, while the position of the node is updated accordingly, the true checking area is stuck behind, as if something has gone terribly wrong behind the scenes.

I showcase this with the cursor entering the areas:

Is there any way to make this work as it should?

This is what each thread executes:
process_bodies
The bloons are directly fetched as children of the Path2D node before the threads start, and are not passed as argument

And the Bloon’s core functions:
Bloon._process(delta) and Bloon.move(delta)
The normal “_process” of each Bloon is halted with set_process(false) and called in the thread itself, but calling either _process() or move() doesn’t change the issue I’m describing.

:bust_in_silhouette: Reply From: timothybrentwood

Try moving the bloons using _physics_process(). _process() goes as quickly as your frame rate allows while _physics_process() is tied to the FPS found at

Project → Project Settings → Physics → Common → Physics FPS

it’s likely what you’re experiencing is a result of movement being updated as quickly as it can and the collision detection of the Area2D catching up on the next physics frame. More info can be found here: https://docs.godotengine.org/en/stable/getting_started/step_by_step/scripting_continued.html#processing

Thank you for the answer! Unfortunately, changing the type of process somehow doesn’t change the current issue. I’ve attempted to change all settings regarding threads and physics, but without any difference. Perhaps it’s better for me to throw in the towel, and realise that this isn’t currently possible…

Micky | 2021-04-27 10:36