"Real" time patch (TTD 1.9.1 + JGR 0.31.1)

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: 53
Joined: 13 Oct 2018 16:33
Contact:

Updated JGR patch

Post by SciFurz » 02 Jun 2019 04:16

updated to version 1.0.
Working on the scheduled dispatch code and replacing _date_fract with _day_tick to make storage of time variables independent of the time factor used.

Noticed things like the option of railway selection being ignored and town passenger generation changing only on month switch instead of right away. Will need to dig even more through the code to find why that is.
Current obvious bugs are invalid cargo links don't seem to be removed and town label stays red despite authority looking favourably for some reason.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Re: "Real" time patch (TTD 1.9.1 + JGR 0.31.0)

Post by SciFurz » 03 Jun 2019 01:11

SimYouLater wrote:Fair enough. I guess a real time patch version of JGRPP is enough to sate my appetite for realism. Thanks in advance!
A compiled version for Windows will take longer. I just ran the compile instructions and the vanilla version was missing some code, and after fixing that it complained about missing a file.
The JGR version just dies with an unhandled exception error in both wine-stable and expirimental, although it did start once. No luck there.
I'll upload the archive anyway because it might just run in Windows itself.

Edit: my mobile connection dies as soon as I try to upload the file so even that isn't possible. You'll have to find someone to compile it for you or try it yourself. At least under a Linux distribution it isn't that hard.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Update for JGR 0.31.1

Post by SciFurz » 05 Jun 2019 16:57

Tweaked the time factor settings and changed the timing increment.
Made some changes to dispatch and timetabling again.

Need to figure out the authority label bug and need to clean up the modification, but it feels like the patch (for JGR at least) is getting close to finished. The vanilla one needs the wallclock code added to take advantage of the patch.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Change in approach

Post by SciFurz » 07 Jun 2019 18:04

Taking a different approach to day length now because I don't like some of the changes I need to make.
Instead of a variable day length in ticks and increasing fractions counter, it becomes a fixed day length amount (enough to run at nearly real time) and variable sized fractions which will add up to a more or less amount in a day depending on the time factor.
For periodic triggering there's a steadily increasing independent tick counter that resets at a new year.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Small status update, alternative time test successful

Post by SciFurz » 10 Jun 2019 02:23

The alternative method of core timekeeping works. The speed of the game is now dependent on the fraction size in a fixed number of ticks (day length).
Added functions to extract and set hours and minutes on top of the existing date functions so it's more integrated and less of a bolt on solution. Hours and minutes are globally calculated and eliminate the need for seperate calculations everywhere.

Made a slight change to the status bar clock to take advantage of the new code but I need to figure out exactly the way strings work to replace the current clock code.
I'll upload a new patch after this and increasing several time related variables, and cleaning up some of the temporary commented out code.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Just wondering

Post by SciFurz » 13 Jun 2019 04:07

Anyone else get the idea this thing's just coded overly complex?
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz


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

Re: Just wondering

Post by SciFurz » 13 Jun 2019 10:36

andythenorth wrote:
13 Jun 2019 07:19
SciFurz wrote:
13 Jun 2019 04:07
Anyone else get the idea this thing's just coded overly complex?
Which thing? :) OpenTTD, or the real time patch? :)
Hey, my patch is actually very simple. :-p I achieved functuality with one change and fixing the compile errors at the start.

It's all this nested stuff and single functions just calling single functions and strings defining strings defining strings that make me lose my train of thought connection and yapf is no help here.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

rowdog
Engineer
Engineer
Posts: 46
Joined: 24 May 2017 12:51
Location: East Texas

Re: "Real" time patch (TTD 1.9.1 + JGR 0.31.1)

Post by rowdog » 13 Jun 2019 12:43

So, I was casually glancing over your patch for vanilla to see what's going on here and I have a question and a couple comments.

My question is, when you widen the uints, is there a reason you choose int32 rather than uint32? Obviously, both will work but I can't help but wonder if there isn't a conceptual and maybe even practical reason to disallow negative time steps.

I noticed that you have a fair number of edits that change nothing but white space.

On line 2449 you have

Code: Select all

-static const uint16 MAX_TOWN_GROWTH_TICKS = 930; ///< Max amount of original town ticks that still fit into uint16, about equal to UINT16_MAX / TOWN_GROWTH_TICKS but sligtly less to simplify calculations
+static const int32 MAX_TOWN_GROWTH_TICKS = 856000; ///< Max amount of originaltown ticks that still fit into uint16, about equal to UINT16_MAX / TOWN_GROWTH_TICKS but sligtly less to simplify calculations     
Comment rot is bad. The old way of reaching 930 no longer applies to your new value of 856000.

There's a harmless but useless double semicolon at the end of line 2210.

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

Re: "Real" time patch (TTD 1.9.1 + JGR 0.31.1)

Post by SciFurz » 14 Jun 2019 07:21

rowdog wrote:
13 Jun 2019 12:43
So, I was casually glancing over your patch for vanilla to see what's going on here and I have a question and a couple comments.

My question is, when you widen the uints, is there a reason you choose int32 rather than uint32? Obviously, both will work but I can't help but wonder if there isn't a conceptual and maybe even practical reason to disallow negative time steps.

I noticed that you have a fair number of edits that change nothing but white space.

On line 2449 you have

Code: Select all

-static const uint16 MAX_TOWN_GROWTH_TICKS = 930; ///< Max amount of original town ticks that still fit into uint16, about equal to UINT16_MAX / TOWN_GROWTH_TICKS but sligtly less to simplify calculations
+static const int32 MAX_TOWN_GROWTH_TICKS = 856000; ///< Max amount of originaltown ticks that still fit into uint16, about equal to UINT16_MAX / TOWN_GROWTH_TICKS but sligtly less to simplify calculations     
Comment rot is bad. The old way of reaching 930 no longer applies to your new value of 856000.

There's a harmless but useless double semicolon at the end of line 2210.
Don't look too much at details right now, this patch is still mostly about functionality.
In the current edit that I'm working on with a different timing approach, most unsigned ints will remain unsigned, just 32 or 64 bit. It's possible that in some instances the value will become intentionally negative, and it saves me from modifying several instances where calculations are done with uint/int values.
There are a lot more variables that could be unsigned but there's no real practical value to modifying all of them.

Where code or comments is written in columns I'll try to keep it neat and tidy as originally intended, and in plenty of cases it means no other change than white space indeed. A good example is the saveload code which has become a mess over time with people adding and modifying their own parts and not keeping the rest tidy. When I finish this patch there will be a lot of unmodified code but for straightening things out.

There are more places where comments need to be modified or added but that's also something for the (near) final version. Same goes for double semicolon you mentioned. I've seen it in other places as well, just like lines of a single tab or whitespace at the end of lines.

I often go through the latest diff I made to check things, but as I said, right now it's about functionality. I'll stick to my modifed parts mostly anyway since cleaning up and tidying the code alone will create a large patch. I'm inclined to do it but I hope with the current code changes done by the devs they'll pick up most of this task along the way.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Re: "Real" time patch (TTD 1.9.1 + JGR 0.31.1)

Post by Eddi » 14 Jun 2019 16:03

There's nothing stopping you from making a separate PR with just layout changes.
You might not exactly be interested in Ferion, but if you are, have fun :)

User avatar
FLHerne
Tycoon
Tycoon
Posts: 1536
Joined: 12 Jul 2011 12:09
Location: St Ives, Cambs, UK

Re: "Real" time patch (TTD 1.9.1 + JGR 0.31.1)

Post by FLHerne » 14 Jun 2019 16:37

Have you considered the effect on industry production, particularly with NewGRF callbacks?

For example, the "deliver <x> units within three months" mechanic used by FIRS:

* If it's always three in-game months, using a 'real' time factor will make those periods extremely long and totally unbalance gameplay.
* If it's really measured in ticks, gameplay will be unaffected but the "three months" text in the industry windows is wrong/misleading.

The second one is probably better, and acceptable for an out-of-tree patch, but ideally needs an extra NewGRF interface for querying the time multiplier, or to convert a time in ticks into displayed time.
Temporary Permanent signature filling text. Content coming soon delayed indefinitely! Oh, and I have a screenshot thread now...
Linux user (XMonad DWM/KDE, Arch), IRC obsessive and rail enthusiast. No longer buiding robots.
Author of an incredibly boring stickied post about NewGRFs.

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

Re: "Real" time patch (TTD 1.9.1 + JGR 0.31.1)

Post by SciFurz » 17 Jun 2019 19:47

Eddi wrote:
14 Jun 2019 16:03
There's nothing stopping you from making a separate PR with just layout changes.
I thought about that for all the parts that aren't directly affected by my changes, but that would be something for after I finish this patch.
And maybe it's better to wait at least until the major migration to standard classes is done by the main devs to avoid duplicate/obsolete work.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Re: "Real" time patch (TTD 1.9.1 + JGR 0.31.1)

Post by SciFurz » 17 Jun 2019 19:54

FLHerne wrote:
14 Jun 2019 16:37
Have you considered the effect on industry production, particularly with NewGRF callbacks?

For example, the "deliver <x> units within three months" mechanic used by FIRS:

* If it's always three in-game months, using a 'real' time factor will make those periods extremely long and totally unbalance gameplay.
* If it's really measured in ticks, gameplay will be unaffected but the "three months" text in the industry windows is wrong/misleading.

The second one is probably better, and acceptable for an out-of-tree patch, but ideally needs an extra NewGRF interface for querying the time multiplier, or to convert a time in ticks into displayed time.
The plan is to scale intervals like industry production with the time factor. Production is more realistic when it's at least once a day or with the higher factors a few times a day.
There's also town growth, passenger and mail production, etcetera. I have to think it over, but I might add a factor for those things as well for people who want increased or decreased production and change other interval based events (like the current town production setting available in the JGR branch).
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: Bing [Bot] and 5 guests