area_set_shape_disabled

Genie

Hey currently i am following an older tutorial on godot 3.x and at some point i got this Error:

E 0:00:02.182 area_set_shape_disabled: Can't change this state while flushing queries. Use call_deferred() or set_deferred() to change monitoring state instead. <C++ Error> Condition "area->get_space() && flushing_queries" is true. <C++ Source> servers/physics_2d/physics_2d_server_sw.cpp:362 @ area_set_shape_disabled() <Stack Trace> Game.gd:40 @ _spawn_platform() Game.gd:59 @ _on_Player_just_jumped() Player.gd:55 @ jump() NormalPlatform.gd:26 @ _on_body_entered()

This error guides me to add_child(new_platform)
It appears pretty often, everytime the add_child code is beeing used i guess.

Why is this error happens and how to use Use call_deferred() or set_deferred() in this case?

Btw. the game works corrently despite all the errors.

Zini

call_deferred("add_child", new_platform)

Genie

Zini
I tried this once, but i get another error Invalid operands "int" and "Nil" in the operator "+"
It guides me to 3 stack frames:

var spawn_x = rand_range(0 + new_platform.sprite_half_width, screen_size - new_platform.sprite_half_width)
_spawn_platform()
_spawn_first_platforms()

Zini

Assuming the error is referencing to the spawn_x assignment, then new_platform.sprite_half_width is null. Maybe something with the setup of new_platform is wrong or incomplete? Difficult to say with such little amount of code.

Genie

Zini

extends Node

export(Array) var platforms
export(Array) var special_platforms

const MIN_INTERVAL = 100
const MAX_INTERVAL = 250
const INITIAL_PLATFORMS_COUNT = 40
const SPECIAL_PLATFORM_CHANCE = 20

var current_max_interval
var current_min_interval
var last_spawn_height
var screen_size


func _ready():
	last_spawn_height = get_viewport().get_visible_rect().size.y
	current_min_interval = MIN_INTERVAL
	current_max_interval = MIN_INTERVAL
	screen_size = get_viewport().get_visible_rect().size.x
	_spawn_first_platforms()

func _spawn_first_platforms():
	for counter in range(INITIAL_PLATFORMS_COUNT):
		_spawn_platform()

func _spawn_platform():
	randomize()
	var index
	var new_platform
	if rand_range(0,100) > 100 - SPECIAL_PLATFORM_CHANCE:
		index = rand_range(0, special_platforms.size())
		new_platform = special_platforms[index].instance()
	else:
		index = rand_range(0, platforms.size())
		new_platform = platforms[index].instance()
	call_deferred("add_child", new_platform)
	var spawn_x = rand_range(0 + new_platform.sprite_half_width, screen_size - new_platform.sprite_half_width)
	var spawn_position = Vector2(spawn_x, last_spawn_height)
	new_platform.position = spawn_position
	last_spawn_height -= rand_range(current_min_interval, current_max_interval)
	current_min_interval += 5
	current_max_interval += 7.5
	current_max_interval = clamp(current_max_interval, MIN_INTERVAL, MAX_INTERVAL)
	current_min_interval = clamp(current_min_interval, MIN_INTERVAL, MAX_INTERVAL / 0.75)

func _on_Player_just_jumped():
	for counter in range (3):
		_spawn_platform()

Anything else that can be helpful?

GlyphTheWolf

Hi,

I am not sure, because I don't know how platforms are coded and what they exactly do, but I would guess they do something in their _ready() method (possibly set sprite_half_width?).

My guess is:

When called add_child() directly _ready() method was already executed when next line of _spawn_platforms() is executed, so if platform is setting sprite_half_width from _ready() method it was already initialized as expected at the time when you are using it.
When calling add_child() using call_deferred() you actually only queue its execution, but at the time next line of _spawn_platforms() is executed _ready() from just created new_platform is not done yet (at least you can't assume it always will be), so if sprite_half_width is set from _ready() or is declared as @onready var it will be still uninitialized at the time when you are trying to use it.

Genie

GlyphTheWolf

Yes the sprite_half_width is set in the _ready() method.
What would be the best way here to fix it?

GlyphTheWolf

In case of Godot 4.x you could try to add after call_deferred() line like:

await get_tree().process_frame

But I am not sure if there is same possibility for Godot 3.x

Anyway another solution is probably:

Call add_child directly in _spawn_platforms() (without call_deferred())

Use call_deferred() to call whole _spawn_platform() method in _on_Player_just_jumped() like:

func _on_Player_just_jumped():
	for counter in range (3):
		call_deferred("_spawn_platform")

Genie

GlyphTheWolf

I did, i get the error
E 0:00:07.438 area_set_shape_disabled: Can't change this state while flushing queries. Use call_deferred() or set_deferred() to change monitoring state instead. <C++ Error> Condition "area->get_space() && flushing_queries" is true. <C++ Source> servers/physics_2d/physics_2d_server_sw.cpp:362 @ area_set_shape_disabled() <Stack Trace> Game.gd:40 @ _spawn_platform() Game.gd:59 @ _on_Player_just_jumped() Player.gd:55 @ jump() GrassPlatformBreak.gd:17 @ _on_body_entered()

GlyphTheWolf

Genie
Hm, that is even when you call _spawn_platform with call_deferred?

Genie

GlyphTheWolf

Oh sorry i put call_deferred("_spawn_platform") in the wrong function, now it works thanks!

I find it interesting how importand the sequence is! Is there a good guide to practise it more?

GlyphTheWolf

Genie
Hmm, good guide... Unfortunately I don't know any guide for that. Possibly documentation have something mentioned about that somewhere around _process() and _physics_process() methods and differences between them. I think there should be something about overall nodes processing order etc.

I know more or less how processing of that nodes may possibly be done, because previously I was working long time on my own game engine, so I know how main loop of such engine need to work and I can imagine how it works in Godot. I read a lot about game engine architecture from different sources depending on issues I faced, so it's hard to give me one exact guide, but all that gave me some experience.

I think basically the most important is to know from which thread methods are called and at which step they are processed by the engine.

Error you originally mentioned cause me to believe you called add_child at the time when physics step was executed by the engine.

Method _ready() is called by the engine main thread and at that time it should be safe to add_child because that means currently no other nodes are processed (there may be of course different issues connected with recursion for example etc., but I assume Godot architecture avoids that, documentation should state what is safe from _ready() and what is not).

In case of _on_Player_just_jumped, it is probably triggered by user input. Not sure how user input is handled by Godot on lower layer, but I wouldn't trust it can't be triggered during another operation.

And if you try to add more threads (like launching physics processing in other thread in Godot 4.x) things are getting even wilder 😝

Genie

GlyphTheWolf

Thanks for the insights! Like i thought, the best source of informations is to be interested in everything about the engine. I always feel like when working with godot, that i am missing some main informations about programming in general.

duane

I think that if you were a perfect programmer -- and all your nodes were little black boxes, completely independent of each other and communicating only with signals -- you'd never have to worry about the order they're ready in. I'm not that perfect.