RealTime-1.10.2-a (preview) patch + binaries

[SciFurz]

A radically modified version/patch that can run slower than the daylength patched versions of OpenTTD, and up to near realtime.
To put it in tile size, at the higher time factors the sizes are (roughly calculated from train travel time in test game):
7200 -> ~119 metre (one game year takes 60 days)
14400 -> ~60 metre
43200 -> ~19 metre

Code-wise, the major change is switching functions from using seperate variables to using the built-in CommandContainer, thereby enabling practically unlimited variables of any type.
Time is modified from 32 bit to 63 bit (signed 64 bit integer).

Slow down multiplication factor can be adjusted in settings, from 1 (60 ticks per day) to 43200 (nearly as slow as real time).
A full date and time clock is automatically enabled in the status bar at higher time factors.
Autosave is set to days, with a daily one at midnight at a minimum.
Integrated a slightly modified train slow down patch (original somehwere on this forum) to avoid faster trains stopping and starting constantly behind slower trains.
As an example of day/night changes made possible by the slower pace, production is limited from 08:00 to 20:00 each day, making an industrial terrain a lot more quiet at night when using road vehicles to pick up cargo.
Several other things have been changed to the interface, and some things are set for testing like higher production rate.

Currently working on a reimplementation of timetables, based on setting arrival and departure times instead of waiting times.
Waiting times are still possible for unscheduled departures to enable waiting in a depot for instance.
Current release has arrival, departure, and interval enabled, the unimplemented features are disabled for now in the interface.

The JGR version is on hiatus because I had to work out at least one major bug. Work on that will continue depending on how easy I can implement a patch version compatible with the internal versioning system of that branch.
Another option might be to implement some of the interesting additions of that branch into this one. I planned to add my own integration of scheduling to timetables anyway since I want to improve on the default functionality.

---

! Note: to play a map larger than 4096x4096, create one in the scenario editor as a workaround until the landscape code upgrade is complete.

Diff for vanilla TTD branch (1.10.2), core modifications done, status: bug hunting related to command process:

realtime-2.4.diff

(558.54 KiB) Downloaded 20 times

.
OpenTTD-1.10.2 based binary for Linux:

openttd-rt.tar.xz

(2.08 MiB) Downloaded 16 times

.
OpenTTD-1.10.2 based binary for Windows (briefly tested with wine (not the grape juice kind)):

openttd-rt-2.4.zip

(2.59 MiB) Downloaded 20 times

.

[SimYouLater]

...

...

Just getting JGR's attention. This would be nice to add to your patchpack, but no rush.

[SciFurz]

New versions of patched posted.

In these the station/cargo ratings should get a daily update.

[peter1138]

Currently default game time is one minute per two real seconds

That does not seem right. A game DAY is 74 game ticks, which is about 2.25 real seconds.

[SciFurz]

Currently default game time is one minute per two real seconds

That does not seem right. A game DAY is 74 game ticks, which is about 2.25 real seconds.

It is default for the patch, which is 1167.567 times slower than the TTD default.

[peter1138]

Currently default game time is one minute per two real seconds

That does not seem right. A game DAY is 74 game ticks, which is about 2.25 real seconds.

It is default for the patch, which is 1167.567 times slower than the TTD default.

Ah, "currently" ... This patch seems very intrusive though. It's there a way to disable it?

[SciFurz]

[/quote]Ah, "currently" ... This patch seems very intrusive though. It's there a way to disable it?[/quote]

Don't patch and compile it.
DAY_TICKS is a constant and there's no changing it dynamically. That's why I'm seeing if I can add a setting to modify it like tthe day length patch, only keeping the factor compatible with real time (no fractional minutes).

And obviously it's very intrusive, anything previously handled by byte size and overflowing them needs to be rewritten to the actual amount of ticks.
It's a wonder I can run the game and load and save without a crash or losing anything so far. :-p

[JGR]

...

...

Just getting JGR's attention. This would be nice to add to your patchpack, but no rush.

I'm not sure I understand what the motivation/benefit of this is.
Changing the day length this drastically is likely to have a lot of side-effects on other parts of the game.
I'm not making any commitments about merging or not, however not being able to to turn it off would be a major blocker.

[andythenorth]

Just getting JGR's attention. This would be nice to add to your patchpack, but no rush.

Why quote people into the thread like this? It's just rude. Stop with this crap.

[SciFurz]

I'm not sure I understand what the motivation/benefit of this is.

It's for those that like to run the game as a model railroad and/or prefer to be able to play and ponder the next step without the stress of constantly needing to pay attention to things one after the other. It also creates more virtual space for better looking railroade stations and junctions without either side ending up touching the next town.
It also makes combining road and rail transport more effective in my opinion. So far it's been a lot more fun and realistic managing a transport network.

Changing the day length this drastically is likely to have a lot of side-effects on other parts of the game.
I'm not making any commitments about merging or not, however not being able to to turn it off would be a major blocker.

Actually, I was surprised at how well the game ran after the simple step of increasing day ticks, and certainly your version compared to the vanilla OpenTTD.
This patch is way too alpha to commit to a release version, for me one requirement is the option to select a speed up, and maybe even a slow down to run it at actual real time. Perhaps even a switch to freeze time and have the game looping the same day?
Anyway, the first step was to see if I could get it running with ticks as seconds, after this I can look at a good method to select a speed for those that like to blast through the game as usual.
They might miss out on taking the time to watch super long trains driving across great plains or parked in numbers on a huge industrial yard though. The shunting ability would be awesome then.

[SimYouLater]

Just getting JGR's attention. This would be nice to add to your patchpack, but no rush.

Why quote people into the thread like this? It's just rude. Stop with this crap.

You don't have to be a jerk about it. I was just trying to point JGR to it, it's entirely up to him; He said he can't decide yet whether it will be included, so I won't bother him further about this patch because that would be rude.

[Eddi]

Changing the day length this drastically is likely to have a lot of side-effects on other parts of the game.
I'm not making any commitments about merging or not, however not being able to to turn it off would be a major blocker.

Actually, I was surprised at how well the game ran after the simple step of increasing day ticks, and certainly your version compared to the vanilla OpenTTD.

several attempts at daylength patches have started with this seemingly simple change, but once you dig deeper, it usually falls apart quickly, as some code paths have not been fitted with handling lager numbers, or people having different opinions over which parts of the game should be slowed down and which parts shouldn't.

[SciFurz]

several attempts at daylength patches have started with this seemingly simple change, but once you dig deeper, it usually falls apart quickly, as some code paths have not been fitted with handling lager numbers, or people having different opinions over which parts of the game should be slowed down and which parts shouldn't.

I did have to increase several variables to int32 indeed. No showstopper for me and the game hasn't crashed on me yet. The only drawback is old savegames aren't compatible with the current code but that's not an issue for me either.

[SciFurz]

Updated the TTD patch to version 0.4.

Included the option setting day length factor under environment to slow down the game speed.
Set to 1 day ticks are 60, higher multiplies it by the factor (goes up to a maximum of 20000(!)). Set it to 1440 to get 86400 ticks in a game day.

Town cargo production is scaled with it, so no need to throw a lot of busses at passengers, instead slow down time so fewer busses can pick up all in one day.

[eekee]

It's for those that like to run the game as a model railroad and/or prefer to be able to play and ponder the next step without the stress of constantly needing to pay attention to things one after the other.

This is exactly what I need! As much as I like OpenTTD, I keep thinking I really ought to replace it with another game because I keep playing too hard and getting stressed.

[SciFurz]

This is exactly what I need! As much as I like OpenTTD, I keep thinking I really ought to replace it with another game because I keep playing too hard and getting stressed.

That's why I began tinkering in the code to get the option to run the game at a scale I want to use. I don't want a train to take hours or even days to go from one end of the station to the next. :-p
Can't wait to build a complete railroad yard with long trains waiting on schedule at a decent scale to cities..

Currently I can slow down the game at a chosen factor, but at a factor above 109 passengers keep gwtting a destination of any station at a newly built one. Working back through the code to find out where probably linkgraph jobs hit a limit.

[eekee]

Um... That's normal for newly-built stations.

[SciFurz]

Um... That's normal for newly-built stations.

Not after a bus has picked up passengers and dropped them off. Then a direct link has been established and subsequent passengers from that station have a destination.
"Any station" is for discovering a station accepting that cargo type.

[eekee]

I just tested in plain 1.9.0 with two quite closely-spaced bus stops and a bus which didn't have enough capacity to pick up all the passengers on its second visit. In this case, passengers "via any station" continued to increase after the second visit.

I don't think the small bus capacity is necessary to trigger this. I think it's because Cargodist doesn't recalculate the link graph straight away. It has an option for how long to take; default 16 days. What that 16 days means with your patch, I don't know.

[SciFurz]

I just tested in plain 1.9.0 with two quite closely-spaced bus stops and a bus which didn't have enough capacity to pick up all the passengers on its second visit. In this case, passengers "via any station" continued to increase after the second visit.

I don't think the small bus capacity is necessary to trigger this. I think it's because Cargodist doesn't recalculate the link graph straight away. It has an option for how long to take; default 16 days. What that 16 days means with your patch, I don't know.

It's not the number of days for the recalculation of the link graph, or the interval. I'm currently trying to figure out why cargo only gets a destination with a day length factor of 1038 or lower (on 60 day ticks in my current modified code). It seems the calculation of links hits an unintentional timeout when there's actually more than enough time in a day. Rather a reverse problem of time. :-/
The term days for the recalculation will become irrelevant anyway since it won't be days but the time unit DAY_TICKS.