Timetable "auto start-date" generating wrong start dates

[GNRD]

Hello!

I'm having a problem with timetable auto-start using shared-orders with some vehicles, which generates wrong start dates... in the past!

These vehicles are all identical, they are using shared orders, they have a timetable already set up and are at the same depot waiting to start the trip. I used the "first" vehicle to do the autofill, and it completed the trip filling the timetable and following all orders successfully. Then when I ctrl-click the start date button and set a start date for the next (first) order a few days in the future for this first train, all other trains get wrong start dates, in the past, failing to serve any purpose.

I thought at first the problem was due to the first train's start date being the 25th of December 1936 - all other trains getting dates in 1936 which were already past, so I waited a few days for the next year and did it again, but the other trains were still pointing to (a new date, but still in) 1936. Letting years go by and doing it again produces the same results: the other trains would start with the same separation but in the past. I did try turning it off and on again, same results.

My setup:
"vanilla" OpenTTD ver 1.4.4 linux 64 build, mostly default settings.
NewGRFs: Generic Tram Set v0.4, NUTS v0.7.8.

[3iff]

I've a feeling that the dates will 'catch up' once the trains have completed a full journey (taking 273 days is 9 months or so...)

I've finally got to grips with the trunk vehicle separation system. Unfortunately it's nowhere as good at the one from the chillpack but that version is now too old to run many of the newgrfs I like.

Don't worry about the dates from the past as I'm sure they will reset themselves in time.

[Transportman]

Don't worry about the dates from the past as I'm sure they will reset themselves in time.

It will either reset because the vehicle is more than one complete timetable late, or it catches up, but in time it will be okay (unless your timetable is not correct, then vehicles will keep getting late again and again).

[GNRD]

Problem is it started happening to all new schedules in that particular game, the 'date generator' gets confused and counts days backwards instead.. I could just divide the whole scheduled time by the number of trains and release them manually... But i'm kinda leaning towards a new game now : P to apply what ive been learning.

I've a feeling that the dates will 'catch up' once the trains have completed a full journey

I tried it out, i had several routes being updated so i just let them all go.. Which not surprisingly caused some major mayhem - they start severely late on their schedules so they try to catch up (being very inefficient on transporting stuff cause they never wait) and after some time they start bunching up, clogging the lines for other services. Pretty nasty : )

Anyway, I'll check the code (if I can understand it) and try to see if there's something I can do to prevent it. This 'date generator' shouldnt be allowed to set dates already past.

[Eddi]

have you tried the ctrl+click method right after the vehicle entered the first station? the game might be trying to set the start date according to the start date of the current vehicle, which may be one round-trip behind

[GNRD]

have you tried the ctrl+click method right after the vehicle entered the first station? the game might be trying to set the start date according to the start date of the current vehicle, which may be one round-trip behind

That makes complete sense!!! I usually do it as soon as the first vehicle comes into the depot (finishing its schedule), but the game might still be "thinking" it's on the previous ride. I wouldve liked to have kept the previous saves to try it out now, cause it's quite likely that was the issue...

Back to PAX it is.

BTW, I checked the code, and as far as Ive seen error checking is done for the first vehicle's start date, but not for subsequent ones in its group... Could be horrendously wrong (tho if it did, this problem wouldnt have arisen anyway)

[3iff]

I did have one route that showed the 2 vehicles as 70+ days late and 30+ days late. So I reset the late timer for both and they gradually got into the correct synchronisation.

It is very important that the timetable has surplus days available so it can adjust up and down...for a 60 day route I would add 5 days or so to allow for flexibility.

[lilbear]

I'm having a problem with timetable auto-start using shared-orders with some vehicles, which generates wrong start dates... in the past!

Hi, I recently started a related thread: http://www.tt-forums.net/viewtopic.php?f=31&t=72724

It seems that the auto-spread feature works well as soon as all the vehicle's timetables are "active" in the sense that all vehicles have already visited the first stop in the timetable and thus there are estimated arrival dates filled in everywhere. For vehicles in the depot with "inactive" timetables, however, the last vehicle in the queue will get the earliest start date. So, if you ctrl-click the start date button for the last train and set a start date a few days in the future, no train should get start dates in the past. Still, you have to release trains manually from the depot one-by-one, starting at the end of the queue, as otherwise trains will leave the depot in the wrong order.

Addendum: I started a suggestion thread to change how the auto-spread feature works on inactive timetables: http://www.tt-forums.net/viewtopic.php?f=32&t=72794

[audigex]

I find the simplest thing is to add a day or two to each station's dwell time, and/or add several days at stations along the route (eg my trains tend to stop at several smaller stations before a larger one, so by setting the wait time at the larger station, I don't waste platform space at smaller stations)

I also find it's best to set the timetable a moment before the train arrives at the first station, then add a few days to the date before hitting ok: there's nothing to say you have to just hit ok on whatever date it suggests (the current date) - add some slack in here and it won't spend the first "loop" of the timetable trying to catch up.

That said, I do think it's a shame that it doesn't work in trunk as well as the Improved Timetable Management etc patch did. The current system is ok but lacks flexibility