Page 7 of 9

Re: RealTime-1.10.2-a (preview) patch + binaries

Posted: 22 Nov 2020 22:21
by Eddi
if the download really only contains the .exe file (which i have not checked), then a) it violates the license. as the binary must always be delivered with the license text, and b) is completely useless, because it must come with the right lang files and a bunch of other files.

in that case, you should probably keep your hands off this patch, as this is not a good sign for quality

Re: Whohoo!

Posted: 02 Apr 2021 17:50
by Gadg8eer
SciFurz wrote: 08 Oct 2020 22:15
Gadg8eer wrote: 27 Sep 2020 20:11
SciFurz wrote: 30 Jul 2020 01:49 Just noticed the counter stating 25000 views on this thread. Never thought it would receive this much attention.

*coughs*

Nevermind. Carry on.
Is this still being developed?
Haven't had the time lately, but I hope I can return to it when my writing is back on schedule.
Not being able to play the game causes slight withdrawal symptoms. :-p
Any chance I could get a JGR-based binary?

Re: Whohoo!

Posted: 28 Apr 2021 02:04
by SciFurz
Gadg8eer wrote: 02 Apr 2021 17:50
SciFurz wrote: 08 Oct 2020 22:15
Gadg8eer wrote: 27 Sep 2020 20:11

Is this still being developed?
Haven't had the time lately, but I hope I can return to it when my writing is back on schedule.
Not being able to play the game causes slight withdrawal symptoms. :-p
Any chance I could get a JGR-based binary?
Not any time soon.
Offline life keeps me busy and I only began the upgrade to the 1.11.1 code base today, so I have a lot of changes to incorporate into my local source of vanilla OpenTTD.
JGR's code has many differences because of the patches he integrated, and is a lot of work to modify.

If you or anyone else want to compile yourself, the minimal code changes are two lines which have worked for me without trouble:
date_type.h: static const int DAY_TICKS = 132; ///< ticks per day
schdispatch_cmd.cpp: assert_compile(DAY_TICKS * 120 < 16384);

Set day length to 120 and ticks per minute to 11, and the game runs almost twice as slow as on maximum day length factor while keeping perfect time on the clock.

Re: RealTime-1.10.2-a (preview) patch + binaries

Posted: 28 Apr 2021 02:09
by SciFurz
4zet55 wrote: 22 Nov 2020 12:48 I did so.
But the only compressed file is openttd-rt-2.4.exe
So I think that further steps are necessary.
The main-thread ottd and JGRp are also installed on my computer, and both work well...
(The download was from the link in the first post of this topic)
?(
My internet connection through mobile craps out when I try to upload the complete file here, so I only did the executable as it worked for me before.
I've begun upgrading to 1.11.1 code, so I'll try again when I've finished work on that. Maybe by then I can upload the entire file. Or maybe split the archive.

Re: Whohoo!

Posted: 29 Apr 2021 07:53
by Eddi
SciFurz wrote: 28 Apr 2021 02:04 schdispatch_cmd.cpp: assert_compile(DAY_TICKS * 120 < 16384);
that line is there for a reason. ignoring this limit will cause hidden errors deep inside the code, which may have weird side effects, which may not be immediately obvious.

Re: Whohoo!

Posted: 29 Apr 2021 18:29
by SciFurz
Eddi wrote: 29 Apr 2021 07:53
SciFurz wrote: 28 Apr 2021 02:04 schdispatch_cmd.cpp: assert_compile(DAY_TICKS * 120 < 16384);
that line is there for a reason. ignoring this limit will cause hidden errors deep inside the code, which may have weird side effects, which may not be immediately obvious.
Yes, the line sets the tick limit as < 16384 because the dispatch time is cramped into 14 bits, see the original comment in the code.
132*120=15840, which is less than 2^14=16384, yes?

PS, I currently run the JGR version with day_ticks set to 1440 and the assert line commented out, and as long as I don't use dispatch, things run smoothly.

snag on code update

Posted: 16 Jan 2022 19:00
by SciFurz
Finally finished the code update to version 1.11.1, which I was working on last time, but hit a snag on squirrel stuff with the api scripts:

‘SQGSWindow’ is not a member of ‘ScriptWindow’

Searched through the code, but no reference to it anywhere, so I'll be messing around for a while longer, unless I find a way to temporarily disable the whole scripting part that isn't more work than a few lines in the make files.

Re: RealTime-1.10.2-a (preview) patch + binaries

Posted: 16 Jan 2022 20:55
by Eddi
you might have to regenerate some script files.

Re: RealTime-1.10.2-a (preview) patch + binaries

Posted: 18 Jan 2022 16:49
by SciFurz
Eddi wrote: 16 Jan 2022 20:55 you might have to regenerate some script files.
I tried with an empty build directory, but still the same.
I also had a similar thing with the modified 1.10.2 code, where the generated table/strings.h couldn't be found during compile. When I copied the file from objs to src, compile continued without problems.
Didn't have that trouble when I worked on it last time.

I tried copying the generated script_window.hpp file to src, but then the timestamp routing complains and stops compilation. Haven't yet looked into changing the destination path of the generated file in the makefile.

Re: RealTime-1.10.2-a (preview) patch + binaries

Posted: 19 Jan 2022 02:37
by Eddi
have you tried running the actual scripts that are supposed to generate those files?

Long time no code

Posted: 06 Jun 2022 15:46
by SciFurz
In a recent burst of energy and motivation to tinker with code, I more or less started from scratch with the 12.2 release code and my previous latest realtime-2.4 patch, and continued from there.
Had to upend a lot more code this time, as can be seen by all the lines I commented out, but it compiled and I could start a new game. Pretty much release ready then. :-p

The zip file in the main post contains the src directory to replace the one in the original 12.2 source code because this can no longer be reduced to a mere patch.
Also. thanks to a better connection out here, I can upload something more than a couple of MB this time.

Main takeaways:
Entire DoCommand core switched over to struct for parameters exchange, and renamed to ProcessCmd because tracing and debugging (eliminating the old two uint32 limit on every command function call, might reverse to DoCommand name again)
First new scheduled timetable features, ability to set station departure times on an interval for transport scheduling (no more calculating wait times on every route)
And of course the original reason for this, running the game at slower speeds up to nearly real time

For those who dare, enjoy digging through the code mess. :-p

Small update 3.0b

Posted: 08 Jun 2022 07:19
by SciFurz
Timetable Interval time is now actually saved.
Linkgraph doesn't work, although the connections are shown, going to take more time to figure that out.

Trying to make wait time work for road vehicles, so I'm trying to make sense of the code by first untangling the large functions into smaller ones and figure out what happens where.

Edit: Wait time works for road and rail on stations, but not depots. These lack the same kinds of orders for leaving. More work to be done on that.

Waiting in depot enabled

Posted: 09 Jun 2022 17:49
by SciFurz
I split up the VehicleEnterDepot function, and added the ability to wait in it for road and rail (probably also works for aircraft and ship, but not tested yet).

The plan is to not run the service and trigger functions by default because those cost CPU time, but make explicit order options for it.
Thinking about a park option as well to keep it in the depot until a conditional order triggers it.

I'm actually tempted to implement the shunting patch already.

Re: Waiting in depot enabled

Posted: 09 Jun 2022 18:13
by wallyweb
SciFurz wrote: 09 Jun 2022 17:49 I'm actually tempted to implement the shunting patch already.
:bow: :D

Might as well post it

Posted: 10 Jun 2022 22:54
by SciFurz
Made some progress on ship and aircraft code because it was more broken than I expected.
Refactored bits of code here and there for all vehicle types to unify the flow of orders. I could replace part of each vehicle controller with a single shared function now, and unifying the depot process is another candidate.

What else?
Collected loading functions into a seperate source file with remaining refit functions to be added to it.
Placed the train path functions into their own source files to declutter the original file a little.
Split a few longer functions I needed to work on into smaller ones.
Changed or cleaned various bytes and pieces in between.

See the ttd-rt-3.0e attachment in first post.

On a side note, added my two data servers for a distcc compiling farm to my laptop and replaced ld with lld, and that made plenty of improvement in speed.

Re: Waiting in depot enabled

Posted: 10 Jun 2022 23:03
by SciFurz
wallyweb wrote: 09 Jun 2022 18:13
SciFurz wrote: 09 Jun 2022 17:49 I'm actually tempted to implement the shunting patch already.
:bow: :D
*lol* I think I will deserve to be worshipped when I make it work. I once had it running with an older version of OpenTTD with my realtime patch, but parts of the original shunting patch had to rewritten for later releases because of code changes.
Well, it was written for 1.8 originally, so no surprise there.

Re: Waiting in depot enabled

Posted: 11 Jun 2022 00:47
by wallyweb
SciFurz wrote: 10 Jun 2022 23:03 *lol* I think I will deserve to be worshipped when I make it work.
The one bow was for the good intention.
Two bows if you make it work. 8)

Update 3.0h

Posted: 19 Jun 2022 12:28
by SciFurz
Posted the new src directory 3.0h.

Did some more refactoring and undid the CFollowTrackT template, creating specific ones for rail, road, and water, and eliminating the unused bits in each.
Together with a cache struct to circumvent frequent retrieval of data which had to be extracted bit-wise, performance increased noticably on my laptop.
Those were a fun couple of days.

Minor update 3.0i

Posted: 20 Jun 2022 13:41
by SciFurz
Fixed the setting of wait and speed times in the timetable window, and added an indication that interval is set (not with value yet).

Update 3.0j

Posted: 21 Jun 2022 21:08
by SciFurz
Fixed bugs I encountered while setting up a new game, and replaced the usage of "get" in the (UK) english language file to correct english.