Anonymous Login
2019-07-21 09:19 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001927OpenClonkEnginepublic2019-04-07 06:53
ReporterMarky 
Assigned To 
PrioritylowSeverityfeatureReproducibilityalways
StatusnewResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0001927: Feature Request: Pause/Resume the game via script
DescriptionI want to be able to "pause" and "resume" the game via function call(s). Ideally, the GUI, menu and controls would still work while the game is "paused".

This means that objects must not move, the landscape must not change, particles and effects must not advance their lifetime.

Maybe this could be solved by a script effect, instead of adding an engine function. The purpose is to have a custom ingame menu that you can operate, while not worrying about other objects/timeouts/whatever. Pausing the game in such a way can be a potential drawback in network games, right?
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0005685

Luchs (administrator)

There is already PauseGame(), but you obviously can't resume with that.

~0005686

K-Pone (developer)

@Luchs: In theory you could resume via /script, but this seems kinda useless since you could simply press Pause instead. Although there might be some use for it if used by /script when it's part of a custom function, but I just can't imagine any for now.

~0005687

Marky (developer)

The crucial part is where this pause function should still allow the interaction with GUIs, so it is not exactly the same as the ingame pause?
I know that pausing the game allows interaction with the player menu (switch music on/off, save the game), but it is not possible to interact with the interaction menu (the one that you get by pressing [E]).
This is also a tricky part. I requested that effects do not get executed, but the interaction menu works with effects internally :(

~0005694

Sven2 (developer)

Last edited: 2017-07-13 01:42

View 2 revisions

The control queue is not run in paused mode, so any queued command cannot be executed. Some stuff like music is allowed because it doesn't affect synchronization. But pretty much any script command needs to be queued.

We could allow resuming as a special GUI action. But what exactly is the use case for this?

~0005695

Marky (developer)

I want to be able to open a menu, for example an inventory or option menu, do some stuff there, then close it. Meanwhile, outside of the menu, the game state should be frozen: Enemies should not move/attack, objects should not fall, etc.
The words "paused"(or whatever happens when you normally pause the game) should not appear on screen in this state. There are many games that handle inventory selection and other things like that, but it is useful for single player only.

This is not needed in the base game, in my opinion.

~0006226

Marky (developer)

Took a look at the engine, and implemented a script function that has the same functionality as the pause button (will not commit that).

What kinds of call should I still execute? I guess: Global effects, scenario effects (although that may be a problem)? Mouse control looks necessary, but on the other hand, in C4Game.cpp, from a naive point of view the same exit point as if the game were not running.
Unfortunately, I do not see where the script engine runs in this, or are those just calls that are executed whether the game is running or not? Obviously, if objects are not executed, then you could create an object, but it would not be drawn, so it seems that a more differentiated approach may be necessary.

After thinking a bit, here is my proposal:
- add game function for querying whether the game is in "GUI only" mode
- execute objects, player, controls, game over check only in this mode
- although objects are executed, only those that have the "GUI only" category are updated
- not sure what to do with the frame counter. It should be halted in "GUI only" mode, I guess.

~0006227

Marky (developer)

Last edited: 2019-04-07 06:53

View 2 revisions

Instead of a category, a property might work well, too. Basically anything that you have to set on purpose (with a property you may even give it to effects and have some evaluations, etc. in the game run in the background while such a GUI is open).

Obviously, this is bad in a network game, so I'd have it either do nothing in network games and maybe issue a warning when a script with this is used in a network game.

+Notes

-Issue History
Date Modified Username Field Change
2017-06-29 15:31 Marky New Issue
2017-06-29 18:33 Luchs Note Added: 0005685
2017-07-01 15:20 K-Pone Note Added: 0005686
2017-07-02 14:39 Marky Note Added: 0005687
2017-07-13 01:42 Sven2 Note Added: 0005694
2017-07-13 01:42 Sven2 Note Edited: 0005694 View Revisions
2017-07-13 14:57 Marky Note Added: 0005695
2019-04-06 21:04 Marky Note Added: 0006226
2019-04-07 06:50 Marky Note Added: 0006227
2019-04-07 06:53 Marky Note Edited: 0006227 View Revisions
+Issue History