Physics process can't be disabled with set_physics_process(false) before _ready().

[ghost]

Godot version:

75cbcb5

OS/device including version:

Win10 64-bit

Issue description:

Physics processing is turned on by default when the function is defined in GDScript, and it has to be manually disabled. This works fine, only during and after _ready(), it can't be set earlier than that.

It's unclear if this is a bug or undocumented behavior.

https://docs.godotengine.org/en/3.1/classes/class_node.html#class-node-method-physics-process

Note - Same is true of _process().

Steps to reproduce:

The following code provides an example of the failure to flag processing off.

extends Node2D

func _init():
	set_physics_process(false)

func _enter_tree():
	set_physics_process(false)
	
func _physics_process(delta):
	print(get_tree().get_frame())

Minimal reproduction project:

[TheFlamyy]

I wouldn't necessarily say it's a bug. But you should be able to change the processing behaviour anytime - in my opinion.

The code affecting this behaviour should be the following:

godot/scene/main/node.cpp

Lines 141 to 147 in b679f62

	if (get_script_instance()->has_method(SceneStringNames::get_singleton()->_process)) {
	set_process(true);
	}
	if (get_script_instance()->has_method(SceneStringNames::get_singleton()->_physics_process)) {
	set_physics_process(true);
	}

One concern arises and it's "how does the engine know if you manually set the processing to be false". Currently all nodes default to disabled processing unless they are "ready".

[ArdaE]

The documentation of set_physics_process (and set_process) already states "Any calls to this before _ready will be ignored". The version you've linked and even older versions of the documentation all have this warning.

So this looks like the intended behaviour. I wouldn't treat it as a bug.

[ghost]

@TheFlamyy Yes, hard to consider it a bug. Just an odd implementation restriction.
@ArdaE A good point. I'm moving it to a proposal. godotengine/godot-proposals#1008

Though the issue is that documentation doesn't really alleviate the awkwardness of this one. I don't think most have the habit of checking and rechecking the docs on every minor setter/getter on the off chance it has very specific limitations like this. I had found it from inspecting the code, and until you mentioned it, had completely missed it was documented since this behavior was last changed.