Feature: Change speed of calendar progress (with optional real-time display)

[2TallTyler]

Motivation / Problem

Note: This supersedes #10322, with the real-time mode now optional. Players can continue to play the game using the current calendar date displayed, so long as they're using default calendar speed.

---

In the daylength discussion, @andythenorth gives motivations for players to configure how fast technology progresses in OpenTTD:

Play 1960 trains forever!

For many players, the game seems to progress quickly. A new generation of vehicles appears, so we upgrade and tune our networks. Then just as we finish, boom! A new generation of vehicles appears.

On busy or large maps it can be hard to keep up.

Slower progression of vehicles would make a more relaxing games for some players.

Additional usecases might be:

• A GS freezes technology progress and advances it when the player completes transport goals ("research" in many games).
• Early-year games such as the American Wild West can actually reach a late-game network size and bank account without cheating time and money — without this, by the time a large network can be built, the era is long past.
• Industry sets can be designed for frozen progression without regard to supporting realistic technological progression, and can offer industry chains which were phased out long ago. Imagine sending ships to hunt whales, delivering coal to gasworks for town gas production, and harvesting ice from frozen lakes to ship around the world. Currently, the NewGRF author can either choose to force these industries to close, frustrating the player, or keep them around forever, which feels silly.

Description

This implements @nielsmh's approach which uses real-time units.

Date/time handling is separated into two systems:

Calendar time for technology and world appearance

• Vehicle introduction and obsolescence
• Available airports, stations, objects, etc.
• NewGRF variables which can be used to determine visual styles or behavior based on the time of year
• Snow line movement

Economy time

• Industry and house production/consumption, etc.
• Town growth
• Industry production changes, closure, and spawning
• NewGRF variables for things like FIRS production boosts
• AI/GS API additions for things like town growth scripts
• Running and maintenance costs, loan interest, etc.
• Vehicle and group profit statistics
• Finance graphs
• Cargo payment rates graph
• Local authority reputation, station ratings, etc.
• Vehicle service interval and time since last service
• Linkgraph tooltips and update interval setting
• Autosave frequency and other settings
• Network game duration in server list (currently says "Years") - @TrueBrain will help with this before merging.

Calendar time is kept in a common Gregorian calendar, with 365 days in a year, leap years, variable length months, and so on.

Real-time mode

By default, we continue to present economic information in calendar dates. This is done by keeping the economy date synced with the calendar date.

In order to change the speed of calendar progress, players will need to start a new game and enable the new real-time setting. This breaks the synchronization between economy and calendar dates: economy months have 30 days, so a "day" is 1.998 seconds, a "month" is a minute, and a "year" (now called a period) is 12 minutes. There are no leap periods.

Savegames cannot be converted to real-time mode. You must start a new game. Once in real-time mode, the speed of calendar progression can be freely changed during games, including by Game Scripts.

In the user interface, all elements that run on economy time are presented in real time units:

Seconds (multiples of 2), for things which were originally daily

• Timetables

Minutes, for things which were originally monthly:

• Industry production per minute
• Passengers last minute
• Vehicle service intervals and time since last service
• Subsidies

Economic periods (sometimes described as simply 12 minutes) for things which were originally yearly:

• Running costs
• Company finances
• Vehicle and group profit statistics
• Company performance rating (league table)

Internally most events will still be referenced as daily/monthly/yearly.

Limitations

While every effort was made to make this change optional, a few changes were impossible to avoid:

• This changes MILLISECONDS_PER_TICK from 30ms to 27ms to make an in-game day last 1.99 seconds instead of 2.2 seconds, making real-world time feasible. This actually matches TTD and closes [Bug]: MILLISECONDS_PER_TICK should be 27, not 30 #10205. 😉
• The settings for Linkgraph updates now use seconds instead of days.
• The setting for the delay before starting the next AI company now uses seconds instead of days.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR touches english.txt or translations? Check the guidelines
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[TrueBrain]

Time to use words in this PR too, as keeping this on IRC/Discord only is not fair! :P

In general, I think this is a really good improvement on the last PR. As you know, I didn't really like that economy and calendar ran on different speeds; but with this PR that is nicely solved. People can still play the game as they currently can, and optional people can go to realtime dates, and speed up calendar, etc.

That said, I think this PR is too big to merge like this. A few concerns there:

• The current PR is hard to review, as there are many other small things to be found too. Some refactors, that are worth getting in master no matter what.
• This PR introduces more than one new feature, that all deserve their own podium. Being able to see things in "realtime" is a big feature. And allowing the calendar to run at a different speed is too. By having that in a single PR, we kinda do unjust to that :)
• It makes comments on how some things are approached tricky, as it would hold back the whole, while the other parts are fine.

But, I fully understand that if this is not the direction that we want to go to, splitting the PR up might be "a waste of time". So, we need some consensus that this is the direction we want to go.

From my perspective, this is by far the best approach I have seen thus far for any form of daylength, in almost 20 years. It is light, it is optional, it doesn't come with tons of settings, and it is understandable. Additionally, it allows for further growth in the next 20 years, no matter what. So I personally really like it.

My suggestion is to do the following:

• Make some small PRs for the small fixes that you did. Like using a bool instead of a != 0xFF is just objectively better. In the motivation it is fine to mention that you are building up to something bigger, but those PRs just help the quality of our code. Similar for the removal of some magic numbers, etc.
• Make a single PR that split calendar and economy, without any changes.
• Make a PR that adds realtime setting.
• Make a PR that does what this PR says it does.

I know, you came up with this list yourself on Discord; I am just writing it down for history :)

Curious if other devs / users have an opinion about the direction this is going, but I like non-intrusive additions to the game that actually don't hurt the code complexity all that much :)

Code-wise, I have a few things, but I rather highlight them in the smaller PRs. Small things, like missing spaces etc can be dealt with in those PRs :) The bit bigger things, like the 75+ instances of the realtime setting need some thinking on my part too, to see if we can reduce that amount :)

All-in-all: excellent work :))

[James103]

Suggested change

	STR_CONFIG_SETTING_SUBSIDY_DURATION_HELPTEXT :Set the number of {RTS years "12-minute periods}" for which a subsidy is awarded
	STR_CONFIG_SETTING_SUBSIDY_DURATION_HELPTEXT :Set the number of {RTS years "12-minute periods"} for which a subsidy is awarded

[nielsmh]

I'm very happy to see my idea from back then has manifested into a real patch, and that it's working out too. Unfortunately I haven't had the time to actually sit with the game for a long time, so I don't know how it is to play with, but it sounds like pretty much every potential issue has been resolved.

I think the presentation of the Calendar progress speed setting needs to be carefully considered. It's easy to make it confusing, and I think it is right now.
The best way to handle it in my opinion would be to directly set ticks per calendar day, possibly with a lower limit somewhere above 10, and possibly with a kind of exponential scale in the up/down buttons. Maybe even present it as in dual units, "One calendar day lasts 4.00 seconds (148 ticks, 50% speed)" or "One calendar day lasts 1.35 seconds (50 ticks, 148% speed)" or "One calendar day lasts 2.00 seconds (74 ticks, original speed)".

[nielsmh]

Bug: When entering delay in a timetable, the input window takes a number in days, but is initialized with a number of seconds. So if the current delay for a timetable line is given as 8 seconds, I click "Change time", then the editing window shows the number 8, but after clicking OK the timetable is then changed to a delay of 16 seconds.

[LC-Zorg]

I don't like the idea of real time because, with a whole host of changes, it brings chaos to the game. But if it's meant to be an option, it's not so horribly bad anymore.

I have two questions:

1. Why slowdown pace of game with default time display should not be possible? In the JGR version, this works very well and to a ~20% slowdown, a different format is not necessary.
2. What happens when the player changes speed during the game? Currently it doesn't work. In the JGR version, player can do this and it doesn't cause any problems.

[2TallTyler]

It doesn't bring chaos to the game. The player will not notice any changes unless they choose to use them.

This implementation is very different from that of JGRPP, so instead of slowing down the entire economy and calendar as one, it changes only the calendar. This means the calendar and economy are not in sync, so there's no way to accurately show the economy in calendar units. That's why we have to show the economy in real-time units, decoupled from the calendar.

I will have to test changing calendar speed during a game. It worked fine last I tried it.

[2TallTyler]

Superseded by #10700, #11341, and #11428, among others.