View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0001927 | OpenClonk | Engine | public | 2017-06-29 15:31 | 2019-04-07 06:53 | ||||||||
Reporter | Marky | ||||||||||||
Assigned To | |||||||||||||
Priority | low | Severity | feature | Reproducibility | always | ||||||||
Status | new | Resolution | open | ||||||||||
Product Version | |||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0001927: Feature Request: Pause/Resume the game via script | ||||||||||||
Description | I 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? | ||||||||||||
Tags | No tags attached. | ||||||||||||
Attached Files |
|
![]() |
|
Luchs (administrator) 2017-06-29 18:33 |
There is already PauseGame(), but you obviously can't resume with that. |
K-Pone (developer) 2017-07-01 15:20 |
@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. |
Marky (developer) 2017-07-02 14:39 |
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 :( |
Sven2 (developer) 2017-07-13 01:42 Last edited: 2017-07-13 01:42 |
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? |
Marky (developer) 2017-07-13 14:57 |
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. |
Marky (developer) 2019-04-06 21:04 |
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. |
Marky (developer) 2019-04-07 06:50 Last edited: 2019-04-07 06:53 |
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. |
![]() |
|||
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 |