Realtime 3.1-maybe-beta (12.2 base)
Moderator: OpenTTD Developers
Realtime 3.1-maybe-beta (12.2 base)
This is a version of OpenTTD in which the game time can be slowed down to practically real time.
Unlike previous day lenght patches, this one does not stretch the day but has the core rewritten to enable it to run at any speed desired.
The main change for the original patch goal has been to switch all neccessary command functions to use the already existing command container.
Doing this basically eliminates all limits of the game, like the different amounts of roads, rail, cargo types that could be used.
Status: Alpha migration to CommandContainer done.
What remains is clean-up like removing commented-out original code, replacing the used command containers with smaller, individual structs,
and cleaning up and maybe consolidating the three core command functions. Also, network testing.
Work in progress:
Improved scheduling for vehicles: Departure and wait times can be set for vehicles to stay at stations or depots. Interval time can be set for
the complete route to automatically update departure times. Arrival times can be set but have no function right now.
Working on the display of relevant times in time table window.
Enabling larger maps: Sizes larger than 16k x 16k can be set, although there is no check on total size of XxY, so use with caution.
Creating a map in scenario editor first might be needed to begin a new game.
Loans are automatically paid off at the end of the day when the balance is more than 1000 in the plus. Will make it a optional setting later.
Side effects:
Changes made while working on the major parts: Refactoring code at various places, Added a tile cache for read-mostly tile data that had to be
calculated every time. Exchanged the CFollowTrack template for more streamlined versions for rail, road, and water to improve performance.
Splitting groups of related functions in large source files off into their own .cpp, _func.h, and _type.h files for clarity. This also exposes the
mess of included header files.
Splitting large functions into smaller ones, sometimes reducing executable size by a little.
Removed implicit order usage.
Skipped a few blitter inherited classes to improve performance for sse2 (and sse4?).
Adding category subdirectories and moving relevant source files in those to lessen the amount of files in src root.
Unlocked all industries, cargoes, and vehicles from every climate apart from Toyland ones (but including plastic).
Possible future features:
Arrival and departure board for stations and the like.
Rewriting and integrating the shunting patch. Think working cargo yards where consists are split up and re-assembled for the next part of the route.
Enable the same possibility to carry different cargos for articulated road vehicles, just like trains.
Tile locking and change status to maybe enable running the landscape part in a seperate thread, and only iterating over tiles that have actually changed.
In that train of thought I'm wondering about using a database backend like SQLite.
Migration of windowing system to wxWidgets. I like to see multiple viewports and management windows without cluttering one main window.
Also being able to switch through them like regular programs.
Gradual build of road/rail as in Simcity.
Demand based economy instead of production based. End customers place orders at producers, who place orders at suppliers, etc., and cargopackets
are created when the required supplies are delivered. Unfulfilled orders will be removed after a set time. Not transporting in time? No monies.
Limit vehicles by amount of coal mined (steam locomotives) and delivered and or amount of power stations (electric locomotives),
as well as oil and refineries (road vehicles)?
Improve YAPF to take waypoints and line ends into account for routes, so it will for instance use a siding to reverse direction into a depot.
Diagonal roads?
---
Complete src directory to replace the 12.2 src directory of the official release: .
Linux package: .
No Windows build because it seems cross compiling no longer works.
Unlike previous day lenght patches, this one does not stretch the day but has the core rewritten to enable it to run at any speed desired.
The main change for the original patch goal has been to switch all neccessary command functions to use the already existing command container.
Doing this basically eliminates all limits of the game, like the different amounts of roads, rail, cargo types that could be used.
Status: Alpha migration to CommandContainer done.
What remains is clean-up like removing commented-out original code, replacing the used command containers with smaller, individual structs,
and cleaning up and maybe consolidating the three core command functions. Also, network testing.
Work in progress:
Improved scheduling for vehicles: Departure and wait times can be set for vehicles to stay at stations or depots. Interval time can be set for
the complete route to automatically update departure times. Arrival times can be set but have no function right now.
Working on the display of relevant times in time table window.
Enabling larger maps: Sizes larger than 16k x 16k can be set, although there is no check on total size of XxY, so use with caution.
Creating a map in scenario editor first might be needed to begin a new game.
Loans are automatically paid off at the end of the day when the balance is more than 1000 in the plus. Will make it a optional setting later.
Side effects:
Changes made while working on the major parts: Refactoring code at various places, Added a tile cache for read-mostly tile data that had to be
calculated every time. Exchanged the CFollowTrack template for more streamlined versions for rail, road, and water to improve performance.
Splitting groups of related functions in large source files off into their own .cpp, _func.h, and _type.h files for clarity. This also exposes the
mess of included header files.
Splitting large functions into smaller ones, sometimes reducing executable size by a little.
Removed implicit order usage.
Skipped a few blitter inherited classes to improve performance for sse2 (and sse4?).
Adding category subdirectories and moving relevant source files in those to lessen the amount of files in src root.
Unlocked all industries, cargoes, and vehicles from every climate apart from Toyland ones (but including plastic).
Possible future features:
Arrival and departure board for stations and the like.
Rewriting and integrating the shunting patch. Think working cargo yards where consists are split up and re-assembled for the next part of the route.
Enable the same possibility to carry different cargos for articulated road vehicles, just like trains.
Tile locking and change status to maybe enable running the landscape part in a seperate thread, and only iterating over tiles that have actually changed.
In that train of thought I'm wondering about using a database backend like SQLite.
Migration of windowing system to wxWidgets. I like to see multiple viewports and management windows without cluttering one main window.
Also being able to switch through them like regular programs.
Gradual build of road/rail as in Simcity.
Demand based economy instead of production based. End customers place orders at producers, who place orders at suppliers, etc., and cargopackets
are created when the required supplies are delivered. Unfulfilled orders will be removed after a set time. Not transporting in time? No monies.
Limit vehicles by amount of coal mined (steam locomotives) and delivered and or amount of power stations (electric locomotives),
as well as oil and refineries (road vehicles)?
Improve YAPF to take waypoints and line ends into account for routes, so it will for instance use a siding to reverse direction into a depot.
Diagonal roads?
---
Complete src directory to replace the 12.2 src directory of the official release: .
Linux package: .
No Windows build because it seems cross compiling no longer works.
Last edited by SciFurz on 30 Jul 2022 08:46, edited 122 times in total.
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
-
- Chief Executive
- Posts: 675
- Joined: 03 Apr 2016 20:19
Re: "Real" time patch
SciFurz wrote:...
Just getting JGR's attention. This would be nice to add to your patchpack, but no rush.JGR wrote:...
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.
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.
updates
New versions of patched posted.
In these the station/cargo ratings should get a daily update.
In these the station/cargo ratings should get a daily update.
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Re: "Real" time patch
That does not seem right. A game DAY is 74 game ticks, which is about 2.25 real seconds.SciFurz wrote:Currently default game time is one minute per two real seconds
He's like, some kind of OpenTTD developer.
Re: "Real" time patch
It is default for the patch, which is 1167.567 times slower than the TTD default.peter1138 wrote:That does not seem right. A game DAY is 74 game ticks, which is about 2.25 real seconds.SciFurz wrote:Currently default game time is one minute per two real seconds
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Re: "Real" time patch
Ah, "currently" ... This patch seems very intrusive though. It's there a way to disable it?SciFurz wrote:It is default for the patch, which is 1167.567 times slower than the TTD default.peter1138 wrote:That does not seem right. A game DAY is 74 game ticks, which is about 2.25 real seconds.SciFurz wrote:Currently default game time is one minute per two real seconds
He's like, some kind of OpenTTD developer.
Re:
[/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
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 http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Re: "Real" time patch
I'm not sure I understand what the motivation/benefit of this is.SimYouLater wrote:SciFurz wrote:...Just getting JGR's attention. This would be nice to add to your patchpack, but no rush.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.
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
- andythenorth
- Tycoon
- Posts: 5666
- Joined: 31 Mar 2007 14:23
- Location: Lost in Music
Re: "Real" time patch
Why quote people into the thread like this? It's just rude. Stop with this crap.SimYouLater wrote:Just getting JGR's attention. This would be nice to add to your patchpack, but no rush.
FIRS Industry Replacement Set (released) | HEQS Heavy Equipment Set (trucks, industrial trams and more) (finished)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Re: "Real" time patch
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.JGR wrote:I'm not sure I understand what the motivation/benefit of this is.
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.
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.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.
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 http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
-
- Chief Executive
- Posts: 675
- Joined: 03 Apr 2016 20:19
Re: "Real" time patch
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.andythenorth wrote:Why quote people into the thread like this? It's just rude. Stop with this crap.SimYouLater 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.
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.
Re: "Real" time patch
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 wrote: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.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.
Re: "Real" time patch
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.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.
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Update TTD patch
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.
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 http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Re: "Real" time patch
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 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.
Extreme network builder. screenshot thread
Re: "Real" time patch
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. :-peekee 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.
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 http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Re: "Real" time patch
Um... That's normal for newly-built stations.
Extreme network builder. screenshot thread
Re: "Real" time patch
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.eekee wrote:Um... That's normal for newly-built stations.
"Any station" is for discovering a station accepting that cargo type.
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Re: "Real" time patch
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.
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
Re: "Real" time patch
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. :-/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.
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 http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Who is online
Users browsing this forum: No registered users and 4 guests