Moderator: OpenTTD Developers
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.
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.
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.
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.
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.
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.
(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.
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).
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.
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.
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.
Users browsing this forum: No registered users and 9 guests