The change in https://github.com/OpenTTD/OpenTTD/pull/10655, released as part
of OpenTTD 14, changed how auto saving works from every X amount of game time,
to every X amount of real time. This is an improvement for normal play, but
there are cases where saving every X amount of game time is useful. For example
when developing and comparing AIs, or using OpenTTD to conduct experiments such
as via https://github.com/michalc/OpenTTDLab which extracts data from savegame
files.
This change adds a general "schedule" console command that makes it possible
for a console script to be scheduled for the future, where that script can, for
example, contain a "save" command to save the game. That script can also then
reschedule itself or another script, and thus making it possible to re-create
the pre-OpenTTD 14 behaviour of saving the game every X amount of game time.
(Possibly with a whole "suite" of game scripts that call each other in a chain,
each of them hard coded with a different filename to allow all the savegames to
be saved with different names, but that's a doable detail)
The current change only allows scheduling "on-next-calendar-month", since that
is my specific use case, but the syntax is hopefully friendly to this being
extended in the future. And by scheduling any console script, it is much more
general and so hopefully useful than just for saving games.
There was some discussion on what this should be called at
https://discord.com/channels/142724111502802944/1008473233844097104/1247278039927361546
(as well as some issues with an alternatively proposed solution using game
scripts at https://github.com/OpenTTD/OpenTTD/pull/12750). Instead of
"schedule", "trigger" was suggested for something to only be called once, but
after writing code and output to the user, it didn't make it immediately clear
that "trigger" means "once at some point in the future", and seemed too close
to "exec". Also I think "schedule" can be used _both_ for one-off or repeated
events in the future (in English it's common to say to "schedule an
appointment", even if it's just the one).
Or code-wise:
schedule on-next-calendar-month my.scr (the only current behaviour)
schedule every-calendar-month my.scr (possible future behaviour?)
schedule "* 1 * *" my.scr (possible future cron-like behaviour?)
Possible future extensions could include some mechanism for cancelling
something that has been scheduled, and I have no reason to think that mechanism
would be different for something scheduled to repeat or just as a one-off, so I
think also it makes sense to that we would have the one command for both.
The new "schedule" command:
- Only allows a single script to be scheduled - any (correct) usage of the
"schedule" command will overwrite the previous, but hopefully the console
messages make this clear
- Only allows a script to be scheduled once at the start of next month (but
this could be extended if useful).
- Does not offer a way to unschedule, but hopefully since the script can only
be scheduled to run once in the future, and relatively close in the future
(at the start of next month), this shouldn't be too much of an annoying missing
feature.
Co-authored-by: Patric Stout <github@truebrain.nl>
- Changing zoom no longer stops following vehicle
- Key scrolling while following a vehicle stops following
- Autoscrolling while following a vehicle stops following
- Main viewport can begin following a vehicle at any zoom
How missing glyphs were detected was changed, but the sprite font still substituted `?`, which to missing glyph looked like all characters are present.
english (au): 2 changes by krysclarke
english (us): 2 changes by 2TallTyler
chinese (simplified): 2 changes by WenSimEHRP
russian: 2 changes by Ln-Wolf
finnish: 25 changes by hpiirai
portuguese (brazilian): 2 changes by pasantoro
english (au): 10 changes by krysclarke
swedish: 13 changes by joeax910
english (us): 10 changes by 2TallTyler
chinese (simplified): 14 changes by WenSimEHRP
russian: 6 changes by Ln-Wolf
catalan: 14 changes by J0anJosep
latvian: 15 changes by lexuslatvia
portuguese (brazilian): 12 changes by pasantoro
english (au): 2 changes by krysclarke
norwegian (bokmal): 2 changes by eriksorngard
english (us): 2 changes by 2TallTyler
russian: 2 changes by Ln-Wolf
finnish: 2 changes by hpiirai
french: 2 changes by ottdfevr
portuguese (brazilian): 2 changes by pasantoro
polish: 2 changes by pAter-exe
For non-WWT_MATRIX widgets, scrollbars need to take account of the internal padding used for the widget.
This is not normally noticeable as framerect padding is only 2 extra pixels
english (au): 2 changes by krysclarke
norwegian (bokmal): 6 changes by eriksorngard
korean: 3 changes by telk5093
russian: 2 changes by Ln-Wolf
finnish: 3 changes by hpiirai
portuguese: 2 changes by azulcosta
portuguese (brazilian): 2 changes by pasantoro
polish: 5 changes by pAter-exe
Michal Charemza
translators
steve-goldman
Jeremy Gao
Rubidium
Jonathan G Rennison
Peter Nelson
glx22
Tyler Trahan
Patric Stout
Joan Josep
Edmond Chui
Björn Wärmedal
ladysadie