Transport Tycoon Forums

Went a different route to upgrade the code from 1.9.3 to 1.10.2, I made a diff between the two versions and applied that to the modified 1.9 code.
Compiled and manually updated code until it finished complaining, and the game runs.

I had to begin with a new test game though, because of the many versions after 1.9, but that's all right, wanted to make a fresh start with a few ideas for laying down towns and different purpose networks on different height levels, separating town roads from industry roads and avoiding houses being built along them.

Added the game binaries for use with Linux to the main post.

Things seem to run, with some modifications in production for testing purposes, but the bug causing a crash when trying to join stations is still there.
Haven't found a way to prevent the selection window struct from losing the command container yet.

I managed to compile a binary for Windows, and it worked for the quick test that I made.

Added it to the main post.

Fixed the issue of crashing while joining stations, but in exchange for that there's another issue with the network side of things.
Shouldn't be a problem running stand alone, I guess, but if I don't see any issues with my test game, I'll update the binaries with the latest version soon.

Fixed the join stations bug with patch version 2.1.

Stations and waypoints can be joined again, thus that major bug seems solved.
Because of the version updates from 1.9.3 to 1.10.2 this version can't load previous (based on 1.9.x) realtime games. I might patch newer updates to the TTD code manually so savegames as of this version can be loaded in newer realtime versions.
Building a new network is fun, but sometimes you just want to keep what was made.

On a side note, I extracted the shunt patch code (see thread in this forum) and added it to a copy of my realtime code, but it crashed when I tried to issue a coupling order.
Not quite surprising, since I had to make several changes just to compile it and not complain about variables. I'll have to look into the added order stack code, which is likely the cause, something to do in spare hours when I feel up to it.

Fixed an issue with cargo not being assigned to a destination.

Also made a quick hack to allow larger maps. I can only test 8192x8192 at most but that works fine so far, even though saving takes minutes because of the file size.
Generating a map over 4096x4096 didn't work, but as a workaround, one can be created in the scenario editor by choosing flat land with height 1 as a minimum. Or like I do, load a preferred heightmap and populate it with one small city to begin with. (I add everything else manually since money is never an issue in TTD)

The Windows version crashed with an unhandled exception in wine, but that might be wine itself.

Added fixed arrival and departure variables to orders, and fixed the times in the timetable view that were simply rolling along with the regular time.
Arrival and departure times are always recorded and shown. Only when the timetable is set will expected times work, but I'll see if I can make it work without explicitly setting times as well.
. .

The new test game is on a map of 8192x8192, and with the time factor set to 7200 (1 game minute ~= 10 seconds), about two thirds of the length takes 280 minutes to traverse at 138kph, as can be seen in the timetable screenshot.
Now we're looking at decent distances and time scales to add a little more realism for model railroad fun.
.
(full size screenshot) .
This should be enough for now to set up timetables for vehicles where it's interesting to do so.
Probably going to dig through patches and code to add waiting time to waypoints and depots, so these can be included in timetabling as well, and see if I can add a blank order line as a placeholder to replace the maximum speed = 0 dummy orders for jumping points.

So, I began reworking the way timetables function to work on actual arrival and departure times, and added what I thought would be a minor feature by stealing the code like a good little Apple programmer, and had it working as ugly as the way it was coded, so I trashed it and began my own implementation, and now I'm almost tempted to rewrite the whole thing from scratch into something neatly structured and organised.

Almost.

Working on a new timetable implementation, based on setting real arrival and departure times instead of waiting times.

(work in progress screenshot, departure line will be replaced with something else like refit order, maximum speed, etcetera)
Shown are the actual last arrival and departure times, not scheduled times (the depot order was added during travel between other stations, thus departure at 00:00). .
Vehicles will leave at designated times, eliminating the need to calculate waiting times in order to try to avoid congestion at stations or crossings, or avoid a fast train tailing a slow one on a single line.
Waiting times are still available to have vehicles wait at unscheduled departure times, for instance parking in a depot or at a train yard while waiting for cargo, to free up a loading station.
Skip options are for handling early and late arrivals and departures, something to be done with conditional orders.
Speed on an order will be set for the trip towards the station.
Time slots are based on the scheduled dispatch version.

Are there any plans to resurrect the JGR version of this patch (not sure exactly what problems you encountered)? If so, will the new timetabling logic be integrated with it?

embeddedt wrote: ↑17 Jul 2020 17:06 Are there any plans to resurrect the JGR version of this patch (not sure exactly what problems you encountered)? If so, will the new timetabling logic be integrated with it?

The best way would be to integrate it as a "jgr version", since jgr made a separate versioning system for his branch, but I'd have to figure out how to best do that and re-do the patch with some removed content back into it. Also, because I refactored quite a bit of the core code, the question is if it can be made as a version release.
The other choice is to create a fork of it, but I'd rather not.
The timetabling is a big enough feature to want to complete the basic groundwork first before deciding what to do next. I've already decided to make my patch a fork and integrate changes of the main branch from now on into versions of my own code.

The main problem is the complexity of the OpenTTD code and how similar actions have been coded at different parts of the whole. I don't see any consolidation or structure in the code, which makes it harder to do anything and slows down the development of my patch.
I already upturned the command core part of the code to enable running the game at a comfortable pace and removing any limit of what it can do, and this next step has me thinking about starting the entire game code from scratch (not saying I understand some of the limits at the original development, but still, there could have been more structure).

To clarify, the way I'm coding the timetable into my patch is instead of modifying the current order or inserting implicit orders, I have the single goto order to a station (waypoint, depot), and control the sequential process through vehicle states and flags.

For example:
Station order has arrival, unloading, loading, waiting settings and corresponding flags for the vehicle instead of inserting implicit orders for that.
Much simpler in my opinion.

Current core functions (handlers) for the vehicles have a really bad sequential process coded into them.

Compiled the first release after the original RealTime-1.10.2 version, with basic timetabling functions enabled.

Arrival and departure times can be set (although arrival doesn't do anything yet), and an interval can be set for an automatic update of those times. (train and road vehicles only for now)
Waiting times are discarded when loading an older game because they cause the vehicle to be stuck at the current station, and these times would have to be replaced by setting departure times anyway.

The stations inside this city are set to receive (better said, depart) a bus every 10 minutes.
Each bus has departure times set 10 minutes apart, with an interval of 1 hour and 20 minutes (0120) to update the times automatically.

There's no time dependent passenger and mail production yet like I coded for the industries (day/night cycle), so the busses run on a 24/7 schedule.
. .

Just noticed the counter stating 25000 views on this thread. Never thought it would receive this much attention.

*coughs*

Nevermind. Carry on.

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?

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

After lunching:

"Error! No available language packs (invalid versions?)"

How can I install this correctly?

unpack the binary to an empty directory, do not try to overwrite an existing installation.

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)