Page 1 of 2
OpenTTD 14.0 Test Game Sun 1/14
Posted: 12 Jan 2024 19:41
by kamnet
Posted on Discord by dev team member 2TallTyler:
In OpenTTD 14.0, you'll be able to slow or freeze the passage of calendar time using the new Timekeeping setting. We need your help to test this new feature before release!
Join us in a new frozen-time game to play 1960s trains forever, check out the new Wallclock timekeeping mode, and see if you can find any bugs.
You will need a custom build of the game, found here:
https://cdn.openttd.org/openttd-branche ... c3e0d9af8/
The server name will be
Tyler Ruins Time.
https://discord.gg/zCy3F3Rd?event=1194316504305520820 for more info and join the Discord community. Game will start at 1PM ET Sun 1/14.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 12 Jan 2024 21:20
by 2TallTyler
Thanks, Kamnet.
For those who want to follow along on GitHub, here's the main PR that changes how fast the calendar ticks:
https://github.com/OpenTTD/OpenTTD/pull/11428
There is also a companion PR (not part of the test game) that fulfils the other usecase of Daylength as it's implemented in JGRPP, which is to scale the production of towns and industries:
https://github.com/OpenTTD/OpenTTD/pull/10606
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 13 Jan 2024 21:40
by ebla71
Very interesting - big thank you to the people who put a huge effort into development of this nice feature, which I particularly like as a person who plays large "real-world" map and likes stay in an epoch for an extended period of time. So far, I have done this by regularly "setting back the time" every one or two years manually, so the feature will come very handy for future gameplay.
However, one thing I immediately noticed when downloading and installing the game version from the link above and then use the new settings is that the first (road) vehicle (did not test the others so far) created ages extremely quickly and reaches a reliability score of 0% within just a few "real-world" second, before you can even make it leave the depot, while a second (and any further) vehicles cloned from the first one do not show this behaviour.
For example, I create a road with one freight stop and a depot. In the depot, I purchase one coal truck from the standard game ("Balogh") to run down the (short) road to the stop and then clone it to get a second one. Let both leave the depot. First truck quickly reaches 35 years and 0% reliability while second truck remains at age of 0 years and 95% reliability.
Maybe a problem with an array or other index??? Can tell you that since I have been in "index hell" with some Python programs
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 13 Jan 2024 21:43
by ebla71
ebla71 wrote: 13 Jan 2024 21:40
For example, I create a road with one freight stop and a depot. In the depot, I purchase one coal truck from the standard game ("Balogh") to run down the (short) road to the stop and then clone it to get a second one. Let both leave the depot. First truck quickly reaches 35 years and 0% reliability while second truck remains at age of 0 years and 95% reliability.
Now check - same problem also with other vehicle types (train and ship) - but it is only the very first vehicle created that is affected this way, irrespective of what's the next one.
For example, I create 1) a ship, 2) a second ship, 3) a train - then only the first ship shows the "rapid aging" behaviour, but not the second ship and also not the first train (or any other).
Another thing noticed: only the first vehicle starts to loose money (since it does not transport anything) besides all of them just running to a stop or bouy and then back to depot without any loading.
Seems to be some initialization or index problem, indeed.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 13 Jan 2024 21:54
by ebla71
Just made an additional strange observation: if you create one bus, for example, then it shows the weird behaviour mentioned above. Create a 2nd bus, does not show it. Delete first bus so that second bus is the only vehicle remaining for the moment - does not get the strange behaviour "transferred". Now create another bus, which gets the vehicle number #1 again - strange behaviour back. It is really something about the vehicle index ...
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 14 Jan 2024 10:48
by jfs
I can't reproduce the behaviour you're describing. Can you share a savegame where it happens in?
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 14 Jan 2024 17:32
by ebla71
jfs wrote: 14 Jan 2024 10:48
I can't reproduce the behaviour you're describing. Can you share a savegame where it happens in?
Didn't save it but when creating a new game happens again:
Second vehicle was cloned from the first one and both never even left the depot.
Version ist
Code: Select all
openttd-20240108-pr11603-gcc3e0d9af8-windows-win64
downloaded 13.01.2024 from the link provided above
Savegame attached below
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 14 Jan 2024 17:48
by jfs
Okay I can reproduce it now. Yeah, when you normally start a game it will have some industries, and usually at least one of those industries will have a smokestack that produces smoke. And those smoke puffs use vehicle slots, they are "effect vehicles". So the first player-built vehicle will under normal circumstances never end up in the first vehicle slot.
But if you generate a map without industries, they there won't be any effect vehicles, and they the misbehaviour with the first vehicle slot manifests.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 14 Jan 2024 19:49
by 2TallTyler
This is indeed a bug with my PR. Thanks for the report.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 14 Jan 2024 21:01
by ebla71
jfs wrote: 14 Jan 2024 17:48
Okay I can reproduce it now. Yeah, when you normally start a game it will have some industries, and usually at least one of those industries will have a smokestack that produces smoke. And those smoke puffs use vehicle slots, they are "effect vehicles". So the first player-built vehicle will under normal circumstances never end up in the first vehicle slot.
But if you generate a map without industries, they there won't be any effect vehicles, and they the misbehaviour with the first vehicle slot manifests.
Correct - the map was without industry. Can also reproduce the mentioned behaviour - if you create an industry with a smokestack like a power plant first and only then purchase the first vehicle - no "rapid aging". Create industry without smokestack like printing press and then do the same - "rapid aging" back. First buy a vehicle and then build a power plant - "rapid aging". Delete the vehicle after building the industry and then buy a new one of the same kind - still ages rapidly.
So there is an "internal vehicle index" variable that does not go along with the one that is display in the game, right?
Quite an esoteric behaviour - so kind of the vehicle sprite system was "mis-used" (or put more positively "re-purposed") to animate some industries or "recycle" the smoke?!?
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 14 Jan 2024 22:30
by 2TallTyler
Yes, each vehicle has an internal index. I haven't dug into fixing the bug, but to briefly explain the diagnosis: Every tick the game cycles through the list of vehicles in the game to handle aging, reliability, etc. In order to avoid stuttering, the code spreads out this processing by comparing this index against the calendar date_fract, which is normally incremented every tick and therefore processes one vehicle per tick (until some vehicle threshold where it loops back and does two vehicles per tick, etc).
When the calendar speed is frozen, this date_fract stops being incremented, but because of my error, the game still tries to age vehicles. But now it ages vehicle 0 every single tick, so it becomes old extremely quickly.
Once I modify the vehicle aging code to follow the current calendar progression speed, this will be resolved.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 14 Jan 2024 22:48
by Argus
But why is there always only one vehicle at fault? I'd rather not ask why smoke counts as vehicles. But I would expect this bug to affect all vehicles.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 15 Jan 2024 11:14
by ebla71
Argus wrote: 14 Jan 2024 22:48
But why is there always only one vehicle at fault? But I would expect this bug to affect all vehicles.
Well, if I understood 2TallTyler correctly, the vehicle data (like aging, profit, and so on) are not updated every "game tick" for all vehicles, but each tick only a certain fraction of vehicles is analyzed, in order to keep the game running efficiently. How many vehicles are updated per tick is calculated in a function and with the "frozen time mode", none should be updated - but there is an error in the code that selects the vehicles from updating and thus, incorrectly, the first vehicle still gets updated but not the others. If the first one is an "industry animation vehicle" you will not notice, since this data cannot be displayed, but if it is a "true" vehicle (train, car, ship) you will notice.
Correctly paraphrased?
Argus wrote: 14 Jan 2024 22:48
I'd rather not ask why smoke counts as vehicles.
Well, would be interesting for a short explanation from the developers anyway.
I would suspect that it is due to the fact that industries are normally "static" and to have some animation, somebody tried to "re-purpose" part of the code that was already animated. Or, alternatively, to "recycle" the smoke from steam engines? Who will lift this mystery???
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 15 Jan 2024 12:19
by jfs
Yes it basically boils down to the "Vehicles" concept in the game being used for most anything that can move across the map. I think the occasional sparks on the power station transformer are also vehicles, as are the bubbles from the bubble factory in Toyland.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 15 Jan 2024 13:21
by Argus
According to this logic, a steam locomotive is actually two vehicles in one.
If the scenario is limited to, say, 100 trains, how exactly do the animations factor into that? I'm surprised it doesn't cause problems elsewhere.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 15 Jan 2024 23:25
by 2TallTyler
ebla71 wrote: 15 Jan 2024 11:14
Correctly paraphrased?
Yes, you've got it.
I can't offer an explanation of why effects are coded as vehicles, as it's long before my time. But OpenTTD is far from the exception with
vehicles coded in a strange way that made sense at the time.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 15 Jan 2024 23:33
by ebla71
"Fallout 3 Broken Steel Train Is Actually Just a Giant NPC Hat"
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 16 Jan 2024 12:41
by peter1138
Argus wrote: 15 Jan 2024 13:21
According to this logic, a steam locomotive is actually two vehicles in one.
If the scenario is limited to, say, 100 trains, how exactly do the animations factor into that? I'm surprised it doesn't cause problems elsewhere.
Well they're not trains so they don't count towards the train limit.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 16 Jan 2024 15:58
by Argus
Well, it certainly takes up one slot somewhere. Or does it take up the "neutral cars" slot?
I'm curious if it could be used, for example, to simulate tractors in fields and the like.
Re: OpenTTD 14.0 Test Game Sun 1/14
Posted: 23 Jan 2024 05:50
by Eddi
each smoke puff is an individual vehicle that gets created at the current location of the train, completes its dissipation animation, and then gets destroyed.
so you have like 6 or 7 addittional vehicles per steam engine. similar for diesel smoke and electric sparks.
also, the shadow of an airplane is a separate vehicle to the plane itself. and the rotor of the helicopter.
and then there's the disaster ufos and stuff.
all these are features that were already in the original game, so you'd have to ask chris sawyer himself why he did it this way.
back in the original game, if you got near the vehicle limit, you could notice steam engines skipping smoke puffs occasionally, as no new vehicle slots could be used. or buildings spawned without the moving elevator.