Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pause mode enabled stops body/area signals being raised on a scene that has pause mode set as Process #47326

Closed
Tracked by #45334 ...
chucklepie opened this issue Mar 24, 2021 · 15 comments · Fixed by #50207

Comments

@chucklepie
Copy link

chucklepie commented Mar 24, 2021

Godot version:
3.2.3

OS/device including version:
Linux mint

Issue description:
I have the following global code to toggle pausing so my main game pauses but a node (a mini-game popup in a gui) runs:

func _input(event: InputEvent) -> void:
	if Input.is_action_just_pressed(INTERFACE_OPENCLOSE_ACTION):
		visible=!visible
		if visible:
			get_tree().paused=true
		else:
			get_tree().paused=false

I have set pause mode as PROCESS for this 'popup' node. When the game runs, the scene is shown, the mini-game plays ok, i.e. pause mode is being ignored for this whole scene correctly. However none of the body or area entered signals within the scene are raised and no collisions occur, they are completely ignored, but the rest of the scene runs fine.

Please see below the little character going straight through the blocks. I have enabled collision visibility to show these are being generated ok

bunny1.mp4

Now, if I change the autoload to not pause the game, then everything works fine. So game_pause is stopping signals from being raised.

    func _input(event: InputEvent) -> void:
	if Input.is_action_just_pressed(INTERFACE_OPENCLOSE_ACTION):
		visible=!visible
		#if visible:
		#	get_tree().paused=true
		#else:
		#	get_tree().paused=false
bunny2.mp4

Minimal reproduction project:
See below comments

@chucklepie
Copy link
Author

chucklepie commented Mar 25, 2021

@Calinou
Find attached a simple as possible case as I could do

  1. Run the program use the cursors and watch it either collide with the tilemap or the kinematic (kinematic to show it's not tilemap at fault)
  2. Press the ui_accept key to pause the game and hide display, then press immediately again to unpause the game
  3. Repeat 1 and watch it not collide with anything

collision_test.zip

Any short term fix suggestion would be appreciated as my game relies on this ability...

@pouleyKetchoupp
Copy link
Contributor

pouleyKetchoupp commented Mar 25, 2021

It seems there's a typo in your pause/unpause script, this version works as expected:

if Input.is_action_just_pressed("ui_accept"):
	visible=!visible
	if !visible: # here, should be set to pause if visible was just set to false
		get_tree().paused=true
	else:
		get_tree().paused=false

In your current version, pressing the button the first time leaves the game unpaused, then pressing it again actually pauses the game (edited).

With this fixed, the signals work as expected.
While the game is paused, signals stop being received because the physics world is not processed.
When the game is unpaused, signals are received again.
Does that work for you?

@chucklepie
Copy link
Author

chucklepie commented Mar 25, 2021

No, the code is correct, I set paused to on when this mini-game is visible.

But you've got me worried. Are you saying that when you set paused=true then physics stops?

This is not in the documentation, it has no mention, it says when you set Process to TRUE on a node it and it's children will continue to work and ignore the pause mode.

If so, what is the point it letting _process() continue but pause _physics_process(), it's like allowing half a scene from functioning? and how is it possible to get this working - this is a popup gui (like pip boy) with a mini game...

@pouleyKetchoupp
Copy link
Contributor

Right now, in your test project, pressing the key twice doesn't revert the state to normal, it's setting pause to true, that's why the signals keep not being received.

But beside that, I understand better what you're trying to do.

By default, yes I can confirm the whole physics is paused when the tree is paused. It causes rigid bodies to stop colliding and getting forces applied, and no collision signal is sent. On the other hand, _process and _physics_process are still called on objects with pause mode set to "process", that's why you can still move the character.

You can work around that by forcing physics to still be processed while paused, using Physics2DServer.set_active(true) just after pausing the game. In this case, the physics world will be still processed while paused, which means rigid bodies will be still moving and signals will be sent on all objects. Objects with pause mode set to "stop" won't receive calls to _process or _physics_process but they will receive signals.

@chucklepie
Copy link
Author

chucklepie commented Mar 25, 2021

My test case was me trying to refactor everything :)

Yes, the purpose is this is a mini-game within a 'pip boy' that pauses the whole game but not this.

If what you say is correct, I'll try it out. Why does process and physics process get called but signals on area/kinematic stop? This doesn't quite make sense to me, but either way it would be nice if it were mentioned in the docs the limitations of the pause mode.

But thanks for your time and effort, I'll check it out.

However, will this mean that my game behind that really is paused will really be paused (I have no rigid bodies, just area and kinematic)?

@Zireael07
Copy link
Contributor

Physics not being processed AT ALL when the game is paused is a BIG catch that absolutely needs to be called out in documentation...

@pouleyKetchoupp
Copy link
Contributor

The reason behind this limitation is that the physics world can only be processed or paused as a whole, which includes checking for collision and sending signals.

In Godot 4.0, the plan is to allow physics objects to be removed from the simulation or set to static when the game is paused, which will help with this limitation.

But yeah, I agree the documentation in 3.2 could be clearer on this aspect. It only mentions that physics 2D/3D will be stopped when you pause the tree, without giving details about what it means.
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-property-paused

And the pause modes could have more details about this too:
https://docs.godotengine.org/en/stable/classes/class_node.html#enum-node-pausemode

@chucklepie
Copy link
Author

chucklepie commented Mar 25, 2021

So if I don't have any rigid bodies and I call Physics2DServer.set_active(true)

then pause my game leaving my mini-game running, will there be any side effects on my main game that is paused?

Also, is it worth going to the documentation section and raising a 'request' for documentation update from somebody knowledgable enough to put something useful in the
https://docs.godotengine.org/en/stable/tutorials/misc/pausing_games.html

section?

@pouleyKetchoupp
Copy link
Contributor

So if I don't have any rigid bodies and I call Physics2DServer.set_active(true)
then pause my game leaving my mini-game running, will there be any side effects on my main game that is paused?

If your main game also uses 2D Physics, physics will keep running as a side effect. If it's a problem for you, the easiest way I can think about to work around this would be to disable physics in all your physics objects manually when you pause (probably by removing the nodes from the tree).

For the long term, the best way to handle this case would be to have a new node type to allow creating separate physics worlds, so you could use it for your minigame and if needed, pause the physics for your main game only. I'll add it to the list of useful things to add in the future, I think it would be relatively easy to do.

Also, is it worth going to the documentation section and raising a 'request' for documentation update from somebody knowledgable enough to put something useful in the
https://docs.godotengine.org/en/stable/tutorials/misc/pausing_games.html
section?

Yes, it's a good idea! You can open a ticket in https://github.com/godotengine/godot-docs/issues and link to this issue.

@chucklepie
Copy link
Author

chucklepie commented Mar 25, 2021

@pouleyKetchoupp
It works great, thanks. One thing I've just noticed and oddly I raised an issue about this ages ago but never saw the link, is when you have animated resources (e.g. animated tres for a tile) they continue to animate with game_pause on. These changes regarding how physics engine works that you mention is coming to 4, would they fix this issue?

At the minute I go through every animated tile and set it's speed to 0 which is quite painful and obviously easy to break when adding new animated resources.

@pouleyKetchoupp
Copy link
Contributor

Great to hear this workaround works for you!

The pause changes for 4.0 I was referring to are specific to physics nodes, animated textures are not part of it and need a separate discussion.

@chucklepie
Copy link
Author

chucklepie commented Mar 30, 2021

@pouleyKetchoupp

I've found another issue, can you clarify to save wasting another issue, or if you think it's a bug or separate issue I can raise a ticket. If it is a bug/feature do you know a workaround?

If I call:
get_tree().paused=true

Tooltips for all gui controls stop working. I know you said physics is excluded but I guess tooltips are threaded and maybe it's been stopped at a global level too, but doesn't seem right given a major use-case for pause mode is config screens...

@Zireael07
Copy link
Contributor

IIRC there's an issue for tooltips not showing when paused and it's a bug @chucklepie

@Calinou
Copy link
Member

Calinou commented Mar 30, 2021

Tooltips not being shown while paused was already reported in #29362.

@chucklepie
Copy link
Author

@Calinou thanks, like I always say I did search just github never seems to be very accomodating with matching.

That bug seems to be not active and classed as requiring a documentation update only, so I've added some comments to it if you don't mind.

I guess this case can be closed as the original bug was down to a known limitation of world physics.

akien-mga pushed a commit to akien-mga/godot that referenced this issue Sep 21, 2021
This pull request adds a small amendment to `SceneTree` describing the behavior `_physics_process()` when pausing the scene.

`_physics_process` will completely stop processing collisions and signals whenever the scene is paused, however, the function will still receive calls.

This addresses: godotengine#47326

(cherry picked from commit d62175e)
akien-mga pushed a commit to akien-mga/godot that referenced this issue Sep 21, 2021
This pull request adds a small amendment to `SceneTree` describing the behavior `_physics_process()` when pausing the scene.

`_physics_process` will completely stop processing collisions and signals whenever the scene is paused, however, the function will still receive calls.

This addresses: godotengine#47326

(cherry picked from commit d62175e)
sairam4123 pushed a commit to sairam4123/godot that referenced this issue Nov 10, 2021
This pull request adds a small amendment to `SceneTree` describing the behavior `_physics_process()` when pausing the scene.

`_physics_process` will completely stop processing collisions and signals whenever the scene is paused, however, the function will still receive calls.

This addresses: godotengine#47326

(cherry picked from commit d62175e)
lekoder pushed a commit to KoderaSoftwareUnlimited/godot that referenced this issue Dec 18, 2021
This pull request adds a small amendment to `SceneTree` describing the behavior `_physics_process()` when pausing the scene.

`_physics_process` will completely stop processing collisions and signals whenever the scene is paused, however, the function will still receive calls.

This addresses: godotengine#47326

(cherry picked from commit d62175e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants