Realtime 3.1-maybe-beta (12.2 base)

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
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Updated JGR patch

Post by SciFurz »

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 http://scifurz.wordpress.com/
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

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

Post by SciFurz »

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 http://scifurz.wordpress.com/
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Update for JGR 0.31.1

Post by SciFurz »

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 http://scifurz.wordpress.com/
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Change in approach

Post by SciFurz »

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 http://scifurz.wordpress.com/
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Small status update, alternative time test successful

Post by SciFurz »

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 http://scifurz.wordpress.com/
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Just wondering

Post by SciFurz »

Anyone else get the idea this thing's just coded overly complex?
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Re: Just wondering

Post by SciFurz »

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 http://scifurz.wordpress.com/
rowdog
Engineer
Engineer
Posts: 67
Joined: 24 May 2017 12:51
Location: East Texas

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

Post by rowdog »

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
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

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

Post by SciFurz »

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 http://scifurz.wordpress.com/
Eddi
Tycoon
Tycoon
Posts: 8258
Joined: 17 Jan 2007 00:14

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

Post by Eddi »

There's nothing stopping you from making a separate PR with just layout changes.
User avatar
FLHerne
Tycoon
Tycoon
Posts: 1543
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 »

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 had a screenshot thread.
Linux user (XMonad DWM/KDE, Arch), IRC obsessive and rail enthusiast. No longer building robots; now I ring church bells.
Author of an incredibly boring stickied post about NewGRFs.
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

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

Post by SciFurz »

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 http://scifurz.wordpress.com/
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

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

Post by SciFurz »

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 http://scifurz.wordpress.com/
Eddi
Tycoon
Tycoon
Posts: 8258
Joined: 17 Jan 2007 00:14

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

Post by Eddi »

SciFurz wrote: 17 Jun 2019 19:47And maybe it's better to wait at least until the major migration to standard classes is done
and when do you think that will be?
User avatar
eekee
Engineer
Engineer
Posts: 96
Joined: 23 Jun 2005 19:45
Location: quantum superposition

Re: Just wondering

Post by eekee »

SciFurz wrote: 13 Jun 2019 04:07 Anyone else get the idea this thing's just coded overly complex?
Not just the idea, I heard it from core devs years ago! :) In IRC 10 or more years ago I requested stations in tunnels, but they said the map code is such a mess, it would be hard to add anything. I wanted to clean it up more than make any one patch, but I never got good enough to understand the C code of a (different) supposedly simple system, so I never dared try C++.
Extreme network builder. screenshot thread
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

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

Post by SciFurz »

Eddi wrote: 18 Jun 2019 13:09 and when do you think that will be?
Next week? :-p
I have no idea on the timeline, I only understood it's something they're working on. It'll be some time before both patches of mine are finished and by then I'll decide on what I'll tackle next depending on what news had been posted on the vanilla release. If it looks like the homebrew code replacement is still a ways off I might go for reorganising the code in a seperate patch.
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Re: Just wondering

Post by SciFurz »

eekee wrote: 19 Jun 2019 10:47 Not just the idea, I heard it from core devs years ago! :) In IRC 10 or more years ago I requested stations in tunnels, but they said the map code is such a mess, it would be hard to add anything. I wanted to clean it up more than make any one patch, but I never got good enough to understand the C code of a (different) supposedly simple system, so I never dared try C++.
Ah, good, then I'm not the only one.
Maybe someone more familiar with the code could mark blocks of code or functionality that needs attention so the cleanup could be done in small steps. The alternative would be a complete rewrite but I'm pretty sure no one will dare to begin on that.
Thinking about it now, maybe it would help if more similar parts were reorganised into their own files. For example, the OnLandscapeTick function seems redundant and I had a brief thought on creating a seperate file to collect all (base) functions that are triggered by time (or perhaps in date.cpp). It would make for a better overview to see what happens on intervals of one or more ticks, days, week, etcetera.

I bought books on C and C++ many years ago when I began working in IT but unfortunately I never had a use for it other than to understand it. I do like C though for it's relatively simplicity (I prefer the UNIX method of thinking compared to the Microsoft one for example). In a way it's a shame I didn't stumble upon OpenTTD much sooner.
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
User avatar
jfs
Tycoon
Tycoon
Posts: 1750
Joined: 08 Jan 2003 23:09
Location: Denmark

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

Post by jfs »

If you want to improve the code structure you're welcome to do so. Make small step changes, submit it as a pull request on GitHub, and it may get integrated. Also join the IRC channel to get more immediate feedback on things.
(Nobody will accept a huge dump of unstructured changes, and if you want to help out on the master branch it's easier to get into the process with small, manageable changesets initially.)
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

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

Post by SciFurz »

jfs wrote: 20 Jun 2019 08:21 If you want to improve the code structure you're welcome to do so. Make small step changes, submit it as a pull request on GitHub, and it may get integrated. Also join the IRC channel to get more immediate feedback on things.
(Nobody will accept a huge dump of unstructured changes, and if you want to help out on the master branch it's easier to get into the process with small, manageable changesets initially.)
I'm thinking of doing it after I finish my realtime patch. I'll have to set up iptables/nftables first though because I'm currently behind a proxy I set up to connect through my mobile connection. That's why I haven't used git directly yet either.
I'm also in favour of making small changes to keep control of things whenever possible. I've had to deal with enough trouble from large changes in my years in IT and that's why I need to be sure this realtime patch is flawless before I tag it as completed. ;-) Burn out made me extra coutious. :-)
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 10 guests