How to intentionally call upon or pass execution to _process(delta) until a certain condition is met within a node?

E.g.

while(!<a condition that has yet to be verified>):
	_process( ??? )	//Call _process

While it's possible to do it the way you have written above, I'd highly suggest trying something like what I wrote below (near the bottom). That said, here is one possible way you could do it using a while loop. func _physics_process(delta): # or _fixed_process if you are using Godot 2 while(<condition insert here>): self._process(delta)

There are a few problems with this bit of code though:

The first (and probably biggest) problem is while the loop is running nothing else will be processing. In other words, none of the other processes (like other nodes) will be doing anything while your while loop is running. The game will seem to be frozen until you've finished doing whatever you need to do in the while loop.

Another problem is that it's using _process. Based on what you've stated, you don't really need to use _process. I'd suggest doing whatever you need in its own function, as it will both be easier to maintain and easier to change where it's called if you change your mind.

One final potential snag I can see with the code above is that you cannot do anything else in _process that doesn't relate to your condition checking. Even if you break it into a function like mentioned above, you'll still need some sort of check to see if you even need to verify the condition.

All of that said, here's a bit of code that I think will do what you want while fixing the problems I mentioned above:

extends <insert node here>

# Any time you change this boolean to true, then in _process it will
# do whatever you need to do
var check_condition = false

func _ready():
    check_condition = true # If you do not need to check
    # at the beginning, then remove/comment-out the line above
    set_process(true)

func _process(delta):
    if (check_condition == true):
        # <Insert whatever you need to do to here!>
        if (<whatever needs verifying here is verified>):
            check_condition = false

(NOTE: The code above is untested, but it should work, in theory at least :smile: )

Thank you beforehand, Twisted, for the comprehensive reply. My code is already similar-ish to the one you posted at the end.

I should've described my situation on my first post but it's still better later than ever :tongue:

Basically i have a board game, a grid with dots on it. Dots are shifted/translated everytime other dots are removed/popped off the grid to fill in the voids/gaps.

What i've found out so far, is that in order for the translation to be visiblly drawn, and not be an immediate translation of popping off one place to appear in another, whatever manipulates the dots's positions needs to execute within _process(delta), and, since other variables are updated with the dots final positions right afterwards, it needs to have a blocking effect on the execution.

The problem is that waiting for this global signal variable in a while loop completely halts execution.

Ah, my apologies for misunderstanding!

So, if I'm understanding correctly, you have this problem:

You have a grid of dots that can be removed/popped off by the player. When this happens all of the remaining dots move so that any voids/gaps are closed. The problem is that while the dots are moving, something undesirable (likely player interaction) can happen. Using a while loop fixes the problem, but then all of the dots just snap into position.


If what I wrote above is correct then the problem might be how you have the game structured mechanically. A simple solution may be making the player script (whatever interacts with the grid) wait until the animation is finished.

Another way you go go about it is to stop all of the other nodes you don't want processing while the animation is going (maybe through a variable?) then you should, in theory, be able to move all of the dots in _process, restart all of the nodes processing again, and then rinse and repeat when more dots are removed/popped off the grid.

A final potential way that I can think of would be restructuring the game to use a state machine. This is likely the most time intensive solution though (unless you're already using a state machine)


If I've misunderstood the problem, my apologies once again :dizzy:. I would suggest seeing if you can temporarily disable player interaction (or whatever is editing the grid) until the animation is finished and see if that fixes it. While it's not the 'cleanest' solution (as it really just masks the problem), it should work relatively well and should be easy to implement.

Tweens are perfect for this. Apply a tween to the position, and use a flag to disable user input. When the Tween finishes and emits its tween_completed signal, you reset the flag and allow input again. AnimationPlayer would work as well.

See this tutorial I recently posted for an example where I use it for grid-based movement:

My apologies for the slightly late reply. Thank you for the ideas, the tweens solution looks like an interesting feature to look into!

No need to apologize Twisted, odds are, it was me who wasn't able to be clear enough about the issues i'm having. You're already awesome for lending off some help to others :smile:

My current solution is to shift the dots fairly quickly, while using a variable that immediately gets updated with the dot's future new position, and, while browsing a grid container to fetch every dot's new position in subsequent calls to a function of theirs to return their current position while remapping the grid, instead of doing a 'return get_pos()', it returns this global variable within each dot node.

So, my issue isn't so much the user input but rather the need for execution to wait at some point to wait while the dots weren't set at their destinations, since the remapping of the grid which takes places right afterwards needs to know the final position of each dot, and that was my issue. In order to see the dots moving, whatever manipulated their movement had to be placed within process(), and there was no way to intentionally call process() on demand, i've tried draw() and using update() but with little success, and using a while loop to wait for a variable completely halted the execution altogether, freezing the game, since, and i'm just guessing, execution only moves onto process() only after the script execution pointer has reached a certain point within the main node's loop.

5 years later