"Real" time patch (TTD 1.9.2 + JGR 0.31.2)

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

"Real" time patch (TTD 1.9.2 + JGR 0.31.2)

Post by SciFurz » 27 Apr 2019 07:14

This patch replaces the 74 ticks based day with a 60 ticks time unit and multiply it with a chosen factor to slow the game down.
Some said it wasn't possible because the 74 was too hardcoded but yet the core change was done quickly and the game was still functional. Most work is in scaling other aspects and tweaking settings.

Unlike other day lengthening patches, this does not insert an extra loop between two original day ticks but it actually increases the amount of available ticks in a day (with factors aligning to real time). Estimated tile distance at factor 1440 (86400 ticks per day) is 1.73 kilometres and would make it about 50 metres at the highest setting (roughly measured with train and road vehicle).

Currently both vanilla and JGR patch seem fully functional (with exception of scheduled dispatch).

Changes in patch (depending on OpenTTD branch):
- modified and added time related variables and definitions
- modified timetable variables for timing
- setting for selecting the time factor (removed old day length option)
- scaled industry production (non-linear)
- automatic enabling of status bar clock
- extended the command functions from 2 to 8 parameters and currently exchanging the row of variables with the CommandContainer struct.
(as of TTD-1.6, modified it to use the CommandContainer at its core, which is easily expanded with useful variables (see timetable files for example)
This means that there's essentially unlimited flags available as well)
- enabled timetable arrival and departure times permanently, they're useful and times are filled in automatically anyway

Not time related:
- added the slightly modified core code of the patch to slow down fast trains behind slow ones and lessen them constantly stopping and starting;
. viewtopic.php?f=33&t=52085
- replaced monthly with daily autosave
- added time to the ISO version of savegame filenames
- tweaks in duration of loading/unloading trains (dependent on train length, not overhang at a station)
- alternative station catchment radius set higher for bus and 1 for other stations
- changed station rating modifiers, vehicle age factor changes only slightly over 10 years and speed is no longer a factor so the small and slower vehicles have a use
- default order settings are no load and no unload, and clicking on the button will open the cargo by type selection list
- switched the unload and load buttons to align with the actual order text

Recommended settings (depending on OpenTTD branch):

Interface - Wall clock:
- Show time in minutes: on
- Enter timetable times as text: on
- Ticks per minute: is set to a fixed 1800 ticks because of the fixed length in ticks in a day
- Show date: full date

Possible issues (the ones seen so far, depending on OpwnTTD branch, not all confirmed fixed yet by me):

The JGR patch is not savegame compatible yet, you might get an ocean background at the intro screen but saving and loading new games works so far.
Production rate might be set higher for testing purposes, eventually to be set to once a day by default and a scaling option.
Town label is red even though attitude is good. (seems caused by loading of previous test games and disappears after saving/reloading game)

Planned additions:
- scale town size
- scale acceleration
- scale catchment area for bus station (other stations can be scaled by combining with bus station when it makes sense for covering populated areas, like mail, goods)
- park depot order to park vehicles while waiting, without triggering the service function
- loopback to station/waypoint similar to the depot code which calls enter depot when target tile is the same as current tile (to let the vehicle stay at the station while processing concitional orders)
- dummy order to act as placeholder/jump target in order list, current workaround is using maximum speed is 0
- need to look at the code more closely but I think it should be possible to extend the search for industries receiving the same cargo instead of stopping at the first one detected
- when starting the scenario editor, open with a 64x64 map to avoid waiting when the last map created was large

Notes:

Some quirks I ran into (might not be related to the patch, will look into later when there's time):
- YAPF processes signal routing differently coming from the back or the front of the signal, most obvious by deny rules
- sometimes a slot is not released when a train passes
- YAPF can reserve next path when the signal is directly behind a waypoint and the train has waiting time scheduled there
- various other situations where YAPF and routing signals don't work, the whole process needs to be traced and checked
- refit craps out when one or more cargos at station are above an x amount (at one point 40000+ BM), or available cargo list can't be read anymore? -> discovered it's the Vixen TFB flatbed truck that won't refit back to wood after it had loaded some other cargo, other trucks might be affected as well because I thiink I had the same trouble with goods cargo before
refit still ceases to work on other occasions though
- conditional order percent of time set to 0 might still be triggered
- road vehicle must have one order going directly to any station otherwise the cargo links it should have are deleted (one can't create an orderlist avoiding any visit to a station without cargo, workaround is first order to a dummy station directly in front of depot where vehicle is waiting)

Had some thoughts about getting a demand based economy using most of the current functionality. All industries get an order list, towns begin by placing an order for goods and food at available industries (FIRS shops, hotel do the same). Those will create orders for required supplies and so on up to the raw industries. Normal production will create cargo packets based on the order list and drop them at the local station where they'll wait for a transportation connection.
No station or production resources simply means the orders are on hold, orders older than a certain age could be automatically deleted from the list, the older the order, the less payment on delivery.
This is something to mull over after I'm done with the realtime work and refactoring of the code unless someone's inclined to give it a shot in the meantime.

---

Diff for JGR patch branch (0.31.2):
realtime-JGR-1.4.diff
(453.63 KiB) Downloaded 59 times
Diff for vanilla TTD branch (1.9.2), core modifications done, status: bug hunting:
realtime-TTD-1.7.diff
(327.22 KiB) Downloaded 36 times
The diff for JGR patch 0.31.3 that I use to work in and which has various junk code in it to test things (for the curious, the only requirement is that the game runs):
diff.19-08-24-b.diff
(972.84 KiB) Downloaded 12 times
PS: Diff files are made from local directories, not the git repositories.

Time factor selection list in settings:
Image

Status bar clock in 1.9.1:
Image
Last edited by SciFurz on 02 Sep 2019 16:15, edited 62 times in total.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

SimYouLater
Chief Executive
Chief Executive
Posts: 671
Joined: 03 Apr 2016 20:19

Re: "Real" time patch

Post by SimYouLater » 29 Apr 2019 00:20

SciFurz wrote:...
JGR wrote:...
Just getting JGR's attention. This would be nice to add to your patchpack, but no rush.
Licenses for my work...
You automatically have my permission to re-license graphics or code by me if needed for use in any project that is not GPL v2, on the condition that if you release any derivatives of my graphics they're automatically considered as ALSO GPL v2 (code may remain unreleased, but please do provide it) and carry this provision in GPL v2 uses.
Please ask someone in-the-know to be sure that the graphics are done by me. Especially TTD-Scale, long story.

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

updates

Post by SciFurz » 29 Apr 2019 03:44

New versions of patched posted.

In these the station/cargo ratings should get a daily update.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

peter1138
OpenTTD Developer
OpenTTD Developer
Posts: 1646
Joined: 30 Mar 2005 09:43

Re: "Real" time patch

Post by peter1138 » 29 Apr 2019 10:27

SciFurz wrote: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.
He's like, some kind of OpenTTD developer.

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

Re: "Real" time patch

Post by SciFurz » 29 Apr 2019 11:24

peter1138 wrote:
SciFurz wrote: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.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

peter1138
OpenTTD Developer
OpenTTD Developer
Posts: 1646
Joined: 30 Mar 2005 09:43

Re: "Real" time patch

Post by peter1138 » 30 Apr 2019 10:04

SciFurz wrote:
peter1138 wrote:
SciFurz wrote: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?
He's like, some kind of OpenTTD developer.

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

Re:

Post by SciFurz » 30 Apr 2019 10:25

[/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
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

User avatar
JGR
Tycoon
Tycoon
Posts: 1989
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: "Real" time patch

Post by JGR » 30 Apr 2019 13:10

SimYouLater wrote:
SciFurz wrote:...
JGR wrote:...
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.
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

User avatar
andythenorth
Tycoon
Tycoon
Posts: 4998
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: "Real" time patch

Post by andythenorth » 30 Apr 2019 13:20

SimYouLater wrote: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.

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

Re: "Real" time patch

Post by SciFurz » 30 Apr 2019 15:42

JGR wrote: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.
JGR wrote: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.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

SimYouLater
Chief Executive
Chief Executive
Posts: 671
Joined: 03 Apr 2016 20:19

Re: "Real" time patch

Post by SimYouLater » 30 Apr 2019 22:09

andythenorth wrote:
SimYouLater wrote: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.
Licenses for my work...
You automatically have my permission to re-license graphics or code by me if needed for use in any project that is not GPL v2, on the condition that if you release any derivatives of my graphics they're automatically considered as ALSO GPL v2 (code may remain unreleased, but please do provide it) and carry this provision in GPL v2 uses.
Please ask someone in-the-know to be sure that the graphics are done by me. Especially TTD-Scale, long story.

Eddi
Tycoon
Tycoon
Posts: 7419
Joined: 17 Jan 2007 00:14

Re: "Real" time patch

Post by Eddi » 01 May 2019 13:41

SciFurz wrote:
JGR wrote: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.
You might not exactly be interested in Ferion, but if you are, have fun :)

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

Re: "Real" time patch

Post by SciFurz » 02 May 2019 09:33

Eddi wrote: 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.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

Update TTD patch

Post by SciFurz » 02 May 2019 14:47

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.
Attachments
beta, 1981-07-08.png
(700 KiB) Not downloaded yet
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

User avatar
eekee
Engineer
Engineer
Posts: 89
Joined: 23 Jun 2005 19:45
Location: Cyberspace

Re: "Real" time patch

Post by eekee » 04 May 2019 16:42

SciFurz wrote: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.
Extreme network builder. screenshot thread

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

Re: "Real" time patch

Post by SciFurz » 04 May 2019 23:10

eekee wrote: 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.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

User avatar
eekee
Engineer
Engineer
Posts: 89
Joined: 23 Jun 2005 19:45
Location: Cyberspace

Re: "Real" time patch

Post by eekee » 05 May 2019 00:20

Um... That's normal for newly-built stations.
Extreme network builder. screenshot thread

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

Re: "Real" time patch

Post by SciFurz » 05 May 2019 05:30

eekee wrote: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.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

User avatar
eekee
Engineer
Engineer
Posts: 89
Joined: 23 Jun 2005 19:45
Location: Cyberspace

Re: "Real" time patch

Post by eekee » 05 May 2019 16:39

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. :)
Extreme network builder. screenshot thread

User avatar
SciFurz
Engineer
Engineer
Posts: 78
Joined: 13 Oct 2018 16:33
Contact:

Re: "Real" time patch

Post by SciFurz » 05 May 2019 19:24

eekee wrote: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.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 12 guests