-
-
Notifications
You must be signed in to change notification settings - Fork 875
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change: replace per-AI "start_date" with a global "competitors_interval" #10653
Conversation
db1628d
to
a36f341
Compare
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. |
a36f341
to
2b4bebe
Compare
I don't fully understand the saveload changes (mainly why inverting data and check data in compat tables). |
This comment was marked as off-topic.
This comment was marked as off-topic.
Owh, I restored the wrong blob. Will fix that :) See those two in reverse, and you are fine :) Edit: done. |
171fd51
to
fd17980
Compare
The per-AI "start_date" is a lot of custom code, and was rarely used in the way it was meant. While at it, also ported this part over to the new timer system.
fd17980
to
6d17a3f
Compare
There was an issue with the start_date parameter for AIs. It did not let Random AIs to have their configure button clickable once the game has started, and this was due to the start_date not being pushed into the config. But now that start_date is no longer in use since OpenTTD#10653, this workaround can be safely removed.
There was an issue with the start_date parameter for AIs. It did not let Random AIs to have their configure button clickable once the game has started, and this was due to the start_date not being pushed into the config. But now that start_date is no longer in use since #10653, this workaround can be safely removed.
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 singleTimeoutTimer
, which is reset when ever it fired to check again ininterval
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.