"Real" time patch (TTD 1.9.1 + 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
eekee
Engineer
Engineer
Posts: 94
Joined: 23 Jun 2005 19:45
Location: Cyberspace

Re: Just wondering

Post by eekee » 23 Jun 2019 20:22

Thought I'd mention I just saw a cargodist- and time-related oddity while not using any time stretching. (JGR.PP, no time options selected.) I linked two existing hub stations with a new line. The train on that line didn't carry any passengers for 20-22 months. Just saying cargodist can turn up surprises. (When passengers finally showed up for that route, there were so many that 1 run paid off the train's lifetime running costs!)
SciFurz wrote:
19 Jun 2019 23:16
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.
I like simplicity. I'm learning Forth; there's tons of advice on how to keep the code simple. Factor out this, factor out that, factor out if/else... :lol: I used Plan 9 from Bell Labs for years, that's a fascinating system with a lot of design tricks which keep the code relatively simple. Its C code is still a bit too much for me, but then most things are.
Extreme network builder. screenshot thread

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

Re: Just wondering

Post by SciFurz » 29 Jun 2019 07:34

eekee wrote:
23 Jun 2019 20:22
Thought I'd mention I just saw a cargodist- and time-related oddity while not using any time stretching. (JGR.PP, no time options selected.) I linked two existing hub stations with a new line. The train on that line didn't carry any passengers for 20-22 months. Just saying cargodist can turn up surprises. (When passengers finally showed up for that route, there were so many that 1 run paid off the train's lifetime running costs!)
That's indeed possible. I had trouble and regressions with triggering the linkgraph functions correctly but with the new process of timing I should get it to trigger normally and independent of the time factor, and probably right away.
eekee wrote:
23 Jun 2019 20:22
I like simplicity. I'm learning Forth; there's tons of advice on how to keep the code simple. Factor out this, factor out that, factor out if/else... :lol: I used Plan 9 from Bell Labs for years, that's a fascinating system with a lot of design tricks which keep the code relatively simple. Its C code is still a bit too much for me, but then most things are.
I've heard about Forth and Plan 9 but never really had the time to look further into it though. As an alternative I've heard Ada is a good one and used in secure systems but also had no time to look into it.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Updated patch for vanilla 1.9.1

Post by SciFurz » 01 Jul 2019 08:25

Redid the patch with the slightly alternative method for timekeeping and added a clock to the status bar. This will be automatically disabled at the lowest time factors since it has no use at those game speeds. I only noticed it's faster at the highest time factor and I'll have to fix that later.
Production is non-lineary scaled with 1-15 times a day at each time factor step for simplicity.
Part of timetabling is modified but since there's a lot of bit functions in use I need to check it further for correct variable sizes, especially when I enable hours and minutes for the arrival and departure time..
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

JGR patch will take some time

Post by SciFurz » 02 Jul 2019 15:49

I need to duplicate the command functions to handle 64 bit variables, but so far wrong error messages are some of the results when it comes to dispatch and thus the new patch for verion 0.31.2 will take some time.
Maybe I'll just rewrite the dispatch thing instead and bypass the whole command mess instead. I'll have to replace the add schedule through 14 bits in a vehicle integer anyway. Why was that set up in the first place?
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Next update will take a really long time..

Post by SciFurz » 04 Jul 2019 16:23

Converted the command functions to handle 64 bit numbers but during the recoding of the timetable functions other weird behavior popped up.
Need to find out why the code loses the ability to calculate inside a string format function all of a sudden for one clock definition while the statusbar clock works fine, and just how the -expletive omitted- that string formatting output stuff works.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Intermittent update patch (TTD 1.9.1

Post by SciFurz » 04 Jul 2019 23:34

I did get a clock string to appear in the timetable but the time is off by several hours. I suspect it might be the way the time difference is calculated since I've seen it switch from red to black text while the truck was still lagging behind during a test. I'll write down an alternative way to calculate (individual) arrival and departure times for comparison and see if that does give me the expected results when I put it to code.
Arrival and departure in hours and minutes:
Garfingway Transport, 2066-06-23.png
(434.4 KiB) Not downloaded yet
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Update for JGR 0.31.2 branch

Post by SciFurz » 07 Jul 2019 00:56

An update for the latest JGR branch, version realtime-JGR-1.3.
Scheduled dispatch is screwed up although the standard timetabling seems to work, so I'm still figuring out why times are set to current ones as start time and why I can't add schedules. :-/ Might have to overhaul the whole thing to find out what it does exactly.
I don't think I'll need to modify variables any longer so saved games would be preserved, no guarantees though. I've tentavely begun a new test track on a 2048x1024 map again myself. Luckily, city distances of a 1000 tiles does mean racking in the cash. :-p
Beta-99, 2066-01-06.png
(610.76 KiB) Not downloaded yet
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

JGR 0.31.2 patch update

Post by SciFurz » 15 Jul 2019 14:35

Made the same changes to the JGR patch as I did for the TTD patch and began work on the dispatch part but it's a real mess and I'll have to redo the whole thing because the commands through the callback functions simply ceased working for no apparent reason. Might as well increase the amount of parameters that can be passed through the commands since I increased one to int64 and had to modify all derived function definitions. No more bitshifting and cramming numbers into a 32 and a 64 bit integer. I thought about using the availab;e string argument in a similar way by populating and extracting it with hex values through converter functions, but that would still be just as error prone and unclear as bitshifting.

Been simply running the game for a few dys without intention to tackle the complex parts but still tweaked bits here and there, among which;
- I set loading order to no unload and no load by default and swapped the two buttons so they actually match the order text sequence (first unload, then load).
- Clicking on the buttons switches between no load/unload and load/unload by type.
- The default for all cargos button in the type list is set to no loading/no unloading. (I'll have to see if I can make it clickable as well to set all cargos with a single click, and set the list to no load/unload by default at order creation)
- Set the ISO save naming option to include the time. It saves me needing to add a character to the file name when I save more than once in a game day (which happens when running at factor 14400).

The slightly modified order list:
Beta-99, 2066_03_28-01_04.png
(691.71 KiB) Not downloaded yet
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Re: JGR 0.31.2 patch update

Post by JGR » 16 Jul 2019 22:25

SciFurz wrote:
15 Jul 2019 14:35
Made the same changes to the JGR patch as I did for the TTD patch and began work on the dispatch part but it's a real mess and I'll have to redo the whole thing because the commands through the callback functions simply ceased working for no apparent reason.
It may be useful to some of the scaling within the command handler instead of before it. This may reduce the need for overly wide command fields.
If you are not already familiar with the various internal debugging tools (debug levels, etc.), I would suggest using them as they would likely save you a lot of time trying to work out what the issue is.
SciFurz wrote:
15 Jul 2019 14:35
Might as well increase the amount of parameters that can be passed through the commands since I increased one to int64 and had to modify all derived function definitions
The patches in the first post still appear to send uint32 values over the network.
SciFurz wrote:
15 Jul 2019 14:35
I thought about using the availab;e string argument in a similar way by populating and extracting it with hex values through converter functions, but that would still be just as error prone and unclear as bitshifting.
There is a already binary data mode for the "text" argument, which you could use if need be.
SciFurz wrote:
02 Jul 2019 15:49
I need to duplicate the command functions to handle 64 bit variables, but so far wrong error messages are some of the results when it comes to dispatch and thus the new patch for verion 0.31.2 will take some time.
Maybe I'll just rewrite the dispatch thing instead and bypass the whole command mess instead. I'll have to replace the add schedule through 14 bits in a vehicle integer anyway. Why was that set up in the first place?
It's 30 bits of date + 14 bits of date fract. You could just make that a 44 bit field if you're not doing date fracts.
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

Currently on holiday, patchpack/dev queries will be looked into when I'm back.

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

Re: JGR 0.31.2 patch update

Post by SciFurz » 24 Jul 2019 00:29

JGR wrote:
16 Jul 2019 22:25
SciFurz wrote:
15 Jul 2019 14:35
Made the same changes to the JGR patch as I did for the TTD patch and began work on the dispatch part but it's a real mess and I'll have to redo the whole thing because the commands through the callback functions simply ceased working for no apparent reason.
It may be useful to some of the scaling within the command handler instead of before it. This may reduce the need for overly wide command fields.
If you are not already familiar with the various internal debugging tools (debug levels, etc.), I would suggest using them as they would likely save you a lot of time trying to work out what the issue is.
The basics of the modification hasn't become scaling up from the original DAY_TICK but a new maximum day length in ticks that's scaled down to speed things up. I found it easier to work from the opposite direction since it preserves tick precision for the higher time factors. Additional scaling inside functions is mostly avoided since the scaling is done by increasing time with smaller or larger steps, so it's not a thing about where the scaling takes place.
I went with an increased amount of parameters to avoid unclear bitstuffing and running out of bits with just p1 and p2 available.

Most troubles had to do with solving compiler errors so I haven't yet done much with debugging. The thing with dispatch is likely the roundabout way it works and I'm looking into cutting the redundant functions that timetabling already posesses, like setting the start time, and I'll probably begin adding debug strings to the timetabling code to see what's going on.
JGR wrote:
16 Jul 2019 22:25
SciFurz wrote:
15 Jul 2019 14:35
Might as well increase the amount of parameters that can be passed through the commands since I increased one to int64 and had to modify all derived function definitions
The patches in the first post still appear to send uint32 values over the network.
I hadn't yet gone over all the Command calls for that patch and only modified the minimum, so that should be the cause.
JGR wrote:
16 Jul 2019 22:25
SciFurz wrote:
15 Jul 2019 14:35
I thought about using the availab;e string argument in a similar way by populating and extracting it with hex values through converter functions, but that would still be just as error prone and unclear as bitshifting.
There is a already binary data mode for the "text" argument, which you could use if need be.
That's the reason why I pondered using the text string, but then I'd still have to extract various parameters from it, and possibly a real text string, and seeing as I'd have to convert int->hex->string->hex->int, it would just add more steps and it would still be as unclear as stuffing bits in one integer.
JGR wrote:
16 Jul 2019 22:25
SciFurz wrote:
02 Jul 2019 15:49
I need to duplicate the command functions to handle 64 bit variables, but so far wrong error messages are some of the results when it comes to dispatch and thus the new patch for verion 0.31.2 will take some time.
Maybe I'll just rewrite the dispatch thing instead and bypass the whole command mess instead. I'll have to replace the add schedule through 14 bits in a vehicle integer anyway. Why was that set up in the first place?
It's 30 bits of date + 14 bits of date fract. You could just make that a 44 bit field if you're not doing date fracts.
That would be possible, but all in all it would again be a patch of one part of all the code while all other time variables would still need to be changed to at least 44 bit. I just bit the bullet and went for clean and simple int64 everywhere without worrying about different bit widths and definitions all over the place.
Same with he command structure, it was some work to expand from 2 to 8 parameters all over the code, but now I can see about adding a few smaller features that I've been thinking of (which need more flags and thus more bits).

All in all I'd like to see all the complexity in the code reduced to make it easier to modify it, even if it's just bit by bit. (pun intended :-p)
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

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

Added the experimental patch for JGR 0.31.3

Post by SciFurz » 24 Jul 2019 00:52

For the curiously inclined, I uploaded the patch has the code I'm currently running and working on, and has plenty of junk in it from quick tests of smaller features I'd like to add, and comments at original TTD code that seems incomplete or wrong.

Biggest change is the extended command structure, and the few timetable functions that I changed from bit stuffed parameters to seperate ones so far.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

User avatar
Hezkore
Engineer
Engineer
Posts: 26
Joined: 02 Sep 2008 07:45

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

Post by Hezkore » 06 Aug 2019 22:32

So I have this server that I'd like to keep on 24/7.
At the end of the week I'll announce a winner and reset the game.
And I'd like the time in the game to move a lot slower.
Otherwise you'll be at like years 2060 after only a day.

How would I get this setup with my Linux server?
And would each client need this special version of OpenTTD as well?
Keep it simple.

SimYouLater
Director
Director
Posts: 621
Joined: 03 Apr 2016 20:19

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

Post by SimYouLater » 07 Aug 2019 00:52

Hezkore wrote:
06 Aug 2019 22:32
So I have this server that I'd like to keep on 24/7.
At the end of the week I'll announce a winner and reset the game.
And I'd like the time in the game to move a lot slower.
Otherwise you'll be at like years 2060 after only a day.

How would I get this setup with my Linux server?
And would each client need this special version of OpenTTD as well?
Do you have the JGR Patch Pack? If so, check the settings for "Day Length Factor" and increase it to 125. That's about 24 hours per year.
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
Hezkore
Engineer
Engineer
Posts: 26
Joined: 02 Sep 2008 07:45

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

Post by Hezkore » 07 Aug 2019 00:57

No I don't.
I've only used vanilla and I'm not familiar with patches and packs.
Does it run on the latest OpenTTD version, and does it have a terminal Debian version?
Keep it simple.

SimYouLater
Director
Director
Posts: 621
Joined: 03 Apr 2016 20:19

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

Post by SimYouLater » 07 Aug 2019 01:14

Hezkore wrote:
07 Aug 2019 00:57
No I don't.
I've only used vanilla and I'm not familiar with patches and packs.
Does it run on the latest OpenTTD version, and does it have a terminal Debian version?
Patch Packs are much easier than they sound. A patch is complex to apply, a pack of patches is hard to make, but getting a patch pack is basically just downloading a special version of the game compiled by someone else.

In this case, JGR's latest Patch Pack can be found HERE. Download this one first, and extract the contents to your OpenTTD install folder (the folders inside need to match up, so make sure you are overwriting existing files. If it spits out an error, try using this version for 32-bit processors before asking for help.

Once you've extracted the files, just open the game and you'll be using the JGR Patch Pack. JGR updates his Patch Pack regularly, so keep an eye on this topic for updates.

EDIT: Didn't realise you were on Debian. Try compiling the source from HERE, but other than that I can't really give any more advice.
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: 71
Joined: 13 Oct 2018 16:33
Contact:

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

Post by SciFurz » 07 Aug 2019 23:52

Hezkore wrote:
07 Aug 2019 00:57
No I don't.
I've only used vanilla and I'm not familiar with patches and packs.
Does it run on the latest OpenTTD version, and does it have a terminal Debian version?
There's no other official Debian package than the vanilla version, but if you're a little familiar with working in the termina I could type up some quick instructions on how to compile the JGR version.
Unfortunately my mobile connection is too unstable for me to upload a complete compiled version.
Tinkering in the code in between writing mostly naughty stuff.
See https://www.patreon.com/scifurz

User avatar
Hezkore
Engineer
Engineer
Posts: 26
Joined: 02 Sep 2008 07:45

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

Post by Hezkore » 07 Aug 2019 23:57

But would each player need this custom version as well?
In that case I'd have to compile for both Linux and Windows.
And I'd like the latest vanilla version with this patch.
Keep it simple.

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

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

Post by rowdog » 08 Aug 2019 01:21

Hezkore wrote:
07 Aug 2019 23:57
But would each player need this custom version as well?
In that case I'd have to compile for both Linux and Windows.
And I'd like the latest vanilla version with this patch.
Yes, the clients all need to run the same code as the server, so custom clients all around. To get vanilla + this patch, you need to get the source and apply the patch. It's rather easy as long as the patch applies cleanly. I'd suggest starting with Linux because the build is very straightforward.
https://wiki.openttd.org/Compiling_on_( ... x_and_*BSD
I don't do windows so I can only recommend reading the docs.
https://wiki.openttd.org/Category:Compiling_OpenTTD

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

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

Post by SciFurz » 08 Aug 2019 01:28

Hezkore wrote:
07 Aug 2019 23:57
But would each player need this custom version as well?
In that case I'd have to compile for both Linux and Windows.
And I'd like the latest vanilla version with this patch.
Everyone does need the same version, yes. It's not possible to mix versions because of different features in each version.
The Windows version is available in JGR's thread for download (see SimYouLater's links) so you only need to compile the Linux version.
JGR's patch pack is extensive so it's not quite the same as vanilla version with a patch, I believe some things from the latest vanilla version haven't been imported in the patch pack of the stable version because it needs more modifications to make it work, but I wouldn't worry about that, just go with the patch pack because it has way more interesting features than vanilla.
(if you mean my realtime patch, then it does need compiling for Windows but I don't recommend running this because it still not completely finished)
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], leeus and 6 guests