Change: replace per-AI "start_date" with a global "competitors_interval"

[TrueBrain]

Motivation / Problem

Currently, you can define the start_date per AI. The name is misleading, as it is the time, in game-days, since the last AI to start the next one.
This approach has been troublesome ever since its invention. It is unclear to the user how to configure it properly, and nobody is actually interested in this fine-grained "when does an AI start".
Additionally, the code complexity that comes with it is big.

As such, this PR sets out a solution that tailors more to the average user: in the AI settings dialog you can now enter the average interval between AIs. The value gets a small deviation of 87.5% .. 112.5%, to make it feel a bit more natural when playing the game.

Description

This PR is mostly removing a lot of code related to the old start_date, and switches to the new timer system to introduce a fairly small amount of code to add the new interval system. It is basically a single TimeoutTimer, which is reset when ever it fired to check again in interval time if a new company should be started.

The interval value is in game-minutes, which is a new unit to the game. A second is ~1/2 game-days, so a minute is about a game-month. It is under the influence of fast-forward.
The reason for this is because a human has a much better understanding of time defined in real-world units, like minutes. Additionally, with upcoming changes to influence how slow/fast the calendar moves forward, it makes no longer sense to hold on to game-days. However, it is important to still use game-ticks as a foundation for this timer, as save/load should still result in the AI starting at the same moment in time as if when the game wasn't save/loaded.

The default used to be a game-year, which is roughly 12 minutes; but to make it a bit easier on the eye, the default is 10 minutes. Shouldn't affect any real gameplay, as it is just when an AI starts.

Acknowledgements

Although #10330 does an attempt of doing something similar, in my opinion, the handling of "when to start the next AI" had too many layers. This PR sets out to do a similar job, but the result uses far less layers to achieve the same.

Closes #10330

Limitations

As OpenTTD currently isn't really event-based, it is a bit difficult to make an actual good "when to start a new AI". For example, the check if a new AI should be started now keeps on running, even if all AIs are running. This simply as an AI might go bankrupt, and than it should be replaced. In an ideal world, the timer would only start after an AI went bankrupt. But currently there isn't any easy way to hook into that, without overly complicated the code further.

Sadly, the regression savegame didn't already have the AI loaded (like the stationlist savegame). This means it would start using the new delay, instead of the old start_date, and that messed up the regression results.
So, I changed the savegame (by saving it with the latest version) to already load the AI, and just don't do anything yet. Now it is similar to the stationlist savegame. This means this problem never resurfaces again.

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

[James103]

The interval value is in game-seconds, which is a new unit to the game. A second is ~2 game-days. It is under the influence of fast-forward.

Actually, the correct value for one 'game-second' is half a game day or 37 ticks, since a game day at normal speed lasts about 2 real seconds, not 1/2 a second.

[TrueBrain]

The interval value is in game-seconds, which is a new unit to the game. A second is ~2 game-days. It is under the influence of fast-forward.

Actually, the correct value for one 'game-second' is half a game day or 37 ticks, since a game day at normal speed lasts about 2 real seconds, not 1/2 a second.

Minor typo in my description. Fixed.

[glx22]

I don't fully understand the saveload changes (mainly why inverting data and check data in compat tables).

[TrueBrain]

I don't fully understand the saveload changes (mainly why inverting data and check data in compat tables).

Owh, I restored the wrong blob. Will fix that :) See those two in reverse, and you are fine :)

Edit: done.