Moderator: OpenTTD Developers
in that case, you should probably keep your hands off this patch, as this is not a good sign for quality
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.
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.
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.
‘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.
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.
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.
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
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.
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.
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.
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.
*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.
The one bow was for the good intention.
Two bows if you make it work.
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.