Transport Tycoon Forums

I've seen the same effect happening, the pileup at a station where a train is waiting to separate... Maybe though there were too many trains on the route (for the network, not for the amount of cargo)...

I'm very pleased with this patch. Although I had never worked with sources/compiling it worked like a charm.
Working with r18956.

Thanks, and I will follow this thread.


Wouter

PS: I uploaded a Win32 binary r18956 with automated-timetables-and-separation_trunk_svn_r18956.diff

Thank you for the feedback! And thanks, boekabart and Wouter, for the update and the new build!

I agree a maximum waiting time might be needed, unless something else is done to make sure the times never get as high. Traffic jams, for example, might be detected and affected vehicles timetables halted until things are running again.

I've not updated the patch for a while now, because I've been playing with a new approach to this patch and rewriting the parts that handle the actual separation. The new idea could perhaps be described as "rubber band separation", as the idea is for the vehicles to behave as if they are connected with stretchy rubber bands: they always want to be in the middle of the vehicle directly ahead and the vehicle directly behind.
(previously they all aimed for their own "global" slot without caring about the local situation)

I have an early version running now, but it's not yet ready for public testing since it's not complete enough. I'm afraid this means no updates until it's done, but when it is I hope it'll be better and more resilient than before.

New version uploaded, with rewritten and very different separation logic!

I've done a lot of changes and only small scale testing, so new bugs might have sneaked in.. But hopefully it should both work and be a big improvement. Things like stopped vehicles and manually skipping orders should be handled more gracefully now, by stopping their timetables and removing them from the separation chain. (As soon as they arrive at a station they'll be started and added once again.)


(I don't usually post whenever I update, but this time the changes compared to the last version are just too big)

Updated binary
automated-timetables-and-separation-v0.6 against r19027

First test shows no bugs.

Hello Gathers,

Things like stopped vehicles and manually skipping orders should be handled more gracefully now, by stopping their timetables and removing them from the separation chain. (As soon as they arrive at a station they'll be started and added once again.)

This works very well and me likes very, very much.

However loading savegames seems to be broken.
I have solved it on my side by bumping all savegame values beyond trunk.

ps:
Maybe you could introduce #define TIMESEP_SV "value".
That way you do not have to go find all values to change them but only have to do value + 1 when trunk bumps.

ChillCore wrote:Maybe you could introduce #define TIMESEP_SV "value".

Introducing more named constants is always a good idea, except not with a #define, but with a 'const int', or an 'enum' (this is C++, man ).

Alberth wrote:

ChillCore wrote:Maybe you could introduce #define TIMESEP_SV "value".

Introducing more named constants is always a good idea, except not with a #define, but with a 'const int', or an 'enum' (this is C++, man ).

Thank you for correcting me Alberth. It is very much appreciated.

[Off-topic]
"#define" is C? I saw/learned it from other patches.
I tried an online tutorial but I prefer flipping real pages so I did not get very far. Time to hit the book store for a few kilos of paper. The new Operation Flashpoint will have to wait a bit.
[/Off-topic]

EDIT:
saveload/saveload.h line82: #define SL_MAX_VERSION 255.

ChillCore wrote:"#define" is C? I saw/learned it from other patches.

In principle, yes in the sense that C++ has better mechanisms to express something is a constant number.
On the other hand, C++ is a super set of C, so a #define is (Edit: technically) correct C++.

ChillCore wrote:I tried an online tutorial but I prefer flipping real pages so I did not get very far. Time to hit the book store for a few kilos of paper.

Me too.
With programming, you can also learn a lot from doing, and from reading other code.

ChillCore wrote:saveload/saveload.h line82: #define SL_MAX_VERSION 255.

Unfortunately, when a dev decides OpenTTD is going to use C++ instead of C, the source code does not magically improve itself to shiny new and perfect C++ code overnight

That #define is one of the more harmless ones. There are also a few that create more complicated data structures.

Wait... So can I use the most recent version of the patch? Or does the save/load thing need to be fixed first?

You can play. Just hit new game and go.
For loading savegames, scenarios are also savegames, you fix it yourself or wait a little bit.

ChillCore wrote:You can play. Just hit new game and go.
For loading savegames, scenarios are also savegames, you fix it yourself or wait a little bit.

Well, I'd have to devote some time to learning C++ to fix it. I'll just wait.

Wow, this is very very awesome, i never before quite did understand how to use timetables, but with this, even us lesser mortals can have fun thanks

I've fixed the savegame version numbers now, sorry it took some time. Thanks for the bug report! Please let me know if there is anything else that I should change.
(besides adding more comments)

Would this patch be a client side only patch on MP games? Ie would it be optional for the clients?

robotboy wrote:Would this patch be a client side only patch on MP games? Ie would it be optional for the clients?

No. This patch influences the game state, so you will desync.

This patch fails to apply with IS2 applied. It fails at saveload.cpp. If you want, I can upload PeterT's updated IS2 patch. Woyld it be possible to get a patch that works with IS2 please
Edit
I actually tried compiling it and it seems to work, even saving and loading. I did not try and set up any timetables though.

robotboy wrote:This patch fails to apply with IS2 applied. It fails at saveload.cpp.

Usually it's fine to ignore anything that fails at src/saveload/saveload.cpp, it's just because they wanted to bump the save game version, it should compile anyway.

New version
I'm now trying to detect and handle jams by checking if the travelling time takes more than 10 times as long as expected. If that is the case, all shared vehicles timetables are stopped until they reach the next station (to avoid updating the timetable with huge travel times because of a jam) and the order time that was detected as 10 times higher than expected is cleared (set to 0) to avoid having vehicles become erroneously early and blocking the station. The order time that was cleared will be filled again as soon as another vehicle with a running timetable arrives again.

This might not be the most elegant way of solving it, but it should make recovery from large jams much smoother, even when 1-lane stations are used.

I've not had time to test everything in a larger game for a while, so please let me know if you happen upon any bugs or situations where vehicles block stations annoyingly long.

Hi Gathers,

Looks like the pattern of my behaviour at this forum is to lurk for some time, report a few bugs, and then disappear for several years
Anyway, I think I found a bug in your patch. The scenario is: you have several vehicles sharing the same order, with automated timetable. You decide to move one of these vehicles to another route. You delete shared orders from this vehicle. After that, when the first of the vehicles of this group arrives at a station, the game crashes
The easiest way to repro is
1. Start a new game
2. Create a bus route serving one of the towns
3. Create 3 busses to serve this route. Make sure they all share the same orders
4. Wait for a few days to let the timetable to settle
5. Open Orders window of any of the vehicles, and remove its shared orders
I'm attaching two save games. In autosave1.sav, steps 1-4 are done, so you'll need to delete orders of one of the busses to reproduce the crash. In game will crash.sav, all steps are done, and it will crash as soon as one of the busses arrives to a station. The saves were made by trunk version r19283 with version 0.7 of your patch applied; the game was compiled in Visual C++ 2008 Express Edition. I deactivated all NewGRFs for these saves
The crash.* files are also attached
If you need more information, let me know

Thanks for the excellent patch, and best regards
Yuri