Long story short... my clock mod makes use of game.ticks_played to calculate total time played including in map editor while paused.
the this end, I have if game.ticks_played % 60 == 0 then in script.on_event(defines.events.on_tick, function()) to update the clock every time a second ticks.
This works fine as long as the game is running, but there's an issue... When in the editor, with the game paused, the clock display doesn't update. When you set time running again, it just jumps ahead 50 seconds, to 10 minutes, or however long you had the game paused in the editor.
Ideally, I need to put this inside an on_ticks_played event instead of on_tick event, but as far as I'm aware, it doesn't exists. So that's my request.
Re: on_ticks_played event
Posted: Fri Jun 05, 2020 5:01 pm
by Rseding91
What about "on_paused_tick" - runs only when on_tick would normally not due to being paused through the map editor logic.
Note: the paused logic can run even outside of the editor so I don't want to associate the event name with the editor itself. It just happens that the editor is the main way most people access it.
Re: on_ticks_played event
Posted: Fri Jun 05, 2020 5:46 pm
by boskid
Could we not have that? paused state is not something used heavily in game, and it could be abused by mods to change other parts of game state. When testing i depend on ability to pause time to investigate state (assuming mods do not catch on_selected_entity_changed event) and when mods would be able to run periodically when time is paused, it would make testing a lot worse - i would loose a "tick once" tool.
Re: on_ticks_played event
Posted: Fri Jun 05, 2020 5:49 pm
by raiguard
I would also like this event, this means I could make Tapeline work while the tick is paused.
Re: on_ticks_played event
Posted: Fri Jun 05, 2020 9:02 pm
by Klonan
I also don't really like the idea of this event
When the tick is paused, I want all logic to be paused, I want a pristine and untouched environment
Re: on_ticks_played event
Posted: Sat Jun 06, 2020 12:20 pm
by Therenas
But, not all logic is paused right? GUI events still work and can change the state of stuff no?
Re: on_ticks_played event
Posted: Sat Jun 06, 2020 12:25 pm
by bobingabout
on_paused_tick works for me.
I do see the concern though, My personal use-case is just to update a "Time passed" display, related to a counter that continues to tick while the game is paused, but I can see how others could abuse it.
Then again, Other events like on_gui_click do still work while the game is paused, so in theory, whatever scripts could be run on a on_paused_tick can already be run while the game is paused manually by pressing a button on a GUI.
Re: on_ticks_played event
Posted: Sat Jun 06, 2020 2:39 pm
by bobingabout
Is there a way to give it it's own bootstrap, Kinda like how on_load can't access game, only allow the on_paused_tick to access certain things, like the GUI, or other light things?
As for Boskid's concern, perhaps a console command that suspends the activation of on_paused_tick?
Re: on_ticks_played event
Posted: Thu Feb 04, 2021 12:52 am
by raiguard
Bump. I have more GUI-related stuff that simply stops working when the tick is paused, which is quite annoying. on_tick_played would fix that!
Re: on_ticks_played event
Posted: Thu Jul 22, 2021 12:14 pm
by KeepResearchinSpoons
Bump.
I also somehow need this. And I also want the ability to have the state to be perma-paused, not the way it works right now with either gui-pause (aaaa, reeeee) or tick_paused.
Well, as a workaround:
I "fixed" it as a side effect of having rcon poll the server ~60 times per sec.
When the game is "tick_paused" rcon events increment the ticks_played like a charm.
On a side note, they also increment game.tick even when player-paused lol, if tick_paused is unset. [not-a-bug]
Does it have to do with a complex scenario crap? Yes it does. A "dirty" workaround? Not so much, more of a pleasant side effect.
Does it fix the main issue? No. But... "Works for me" :>
Thread related.
In my opinion, we do not need such an even in the first place.
Reason: ticks_played is crazy volatile. It does not belong to a world/map. It belongs to a "server".
It is SO MUCH CHARMING to have it exposed ofc. Makes it easier to control the server by a whole lot.
And I would probably love to have the rcon scheduler work even without rcon. But then, how do I stop it in case anything goes haywire?
Afaik, the server may start a converted map midways (game.tick > 0), there is a game.speed, there is an editor pause, there is rcon
yet all of it are "external tools", not being run by the "scenario", or at least not meant to be run by an autonomous scenario.
Clock-wise, do you factor in the game.speed I wonder? Cuz ticks_played would prob really be the only feasible option afaics.
Do you factor in not-100% ups on getting laggy? Ah, here we go again, lets break the "4th wall" yet another time.
Like, when I "control" the server with these tools "from the outside", I expect the server-scenario part to be "sandboxed" inside all of this.
The server (headless) imo should NOT control the behavior of the debug tools that "debug" it. (unless it has a good and working api for that? With rpc stuff and all of it from the box? Nah prob not happening.)
What I do want however would be to pause the simulation updates over the entire specific surface.
short-overview-details
Keep all the events and prob most of the lua.
Update surf content with lua or mutate it "from the other surface"? sure why not.
But stop any entities from "running".
No transport lines/entities cycles or anything should affect the ups greatly...
Thus being "ups-paused".
Way easier than "unload", just a "20-minute adventure" mess with update ques, huh.
The benefit of such a dead (static) surface would be a "sleeping state". For "space travels" or anything.
Cutting down memory as well.. would be great but would be hard by a margin imo.
The other benefit is to have a halt/kill switch for a buggy/broken-data/laggy surface. WHILE having on_tick and the like (scripts) still available.
Like, I could run any transformations/migrations for any number of consecutive ticks and not have them do all the stuff on the same tick?
You know the (de)-serialization hell for structures of more than chunk size? Poof gone in at least half the cases.
The clone-part on switching surfaces aka "spaceship no-dupe" on spacey or "pirate ship size" on pirates... have no more to be atomic "clone"-s!
The obvious mishaps to happen...
Stopping a surface update (like, action pipes already full and all the stuff) may be costly.
Races? "mean do you? What races"... In a sense, all "sleep 2 ticks" is now "garbage" :> Or maybe a blessing, since everyone would now just "sleep".
I feel this idea belongs to another thread however.
Well, if done it would have awesome options unlocked from the get go.
Being a "major feature" request... it would have to have at least a benefits list outlined "through and deep" beforehand.
Some issues should be collected, ideas packed and refined...
You know, setting a script-disabled state on a roboport does almost "nothing" to logi net, for a mere example.
A skip on this is totally deserved and justified. Consider this a preview on the idea that may get to requests some future time, or may as well die in agony.