[VicenteIR]

I think that is not correct to set $forms command in this way. The command need to have a common section of both paths. The "runround" qualifier must be started and terminated also at the same section. It is for turn power units around the consist were $forms takes place.
You can form a new train at start position of your "runround" path, to terminate it at the end point with one more $forms command forRt1_Run1_Trip2 train.

Regards
Oleg

[Traindude]

 VicenteIR, on 19 July 2020 - 03:45 AM, said:

I think that is not correct to set $forms command in this way. The command need to have a common section of both paths. The "runround" qualifier must be started and terminated also at the same section. It is for turn power units around the consist were $forms takes place.
You can form a new train at start position of your "runround" path, to terminate it at the end point with one more $forms command forRt1_Run1_Trip2 train.

Regards
Oleg

Thanks. I tried you suggestions and it worked!

One more question, though:

In creating timetables for the Downtown Trolley route, I am creating them based on a "service day" that begins at 4 AM on any given day and continues until 3:59 AM, which is technically on the following day. So even though the last train may be booked to begin after midnight and technically on the following day, it is actually running as part of the previous day's schedule. For example, if a train scheduled to depart at 12:30 AM on a Saturday, it is still, in terms of the 4 AM service day start time, running under Friday's schedule.

After reading the OR manual, I am under the assumption that, since OR timetable mode acts as if service days began at midnight, then I have to include the last "previous day" departures as part of the following day's timetable file. For example, the last trains from the "Friday" schedule must be included in the "Saturday" timetable file, and so on.

Since I am creating separate Weekday, Saturday and Sunday timetables (the latter also being in effect on major holidays), this overlap can be a bit confusing, but I think I've got the general idea, so I need to make the following timetables:

1. Monday (includes "Sunday" schedule trains before 4AM)
2. Tuesday-Friday (includes "Monday-Thursday" schedule trains before 4AM)
3. Saturday (includes "Friday" schedule trains before 4 AM)
4. Sunday (includes "Saturday" schedule trains before 4 AM)
5. Monday Holiday (Sunday schedule, includes "Sunday" schedule trains before 4 AM)
6. Tuesday-Saturday Holiday (Sunday schedule, includes "Weekday" schedule Trains before 4 AM)

Is my assumption correct in this regard?

[roeter]

You can start the timetable at 04:00, and include trains after midnight by using the $next qualifier for the start-time, so a train with starttime 01:00 $next will not start at the beginning of the timetable but after midnight at the end.

If there is no overlap of services this will work fine. If there is an overlap, you may need to include trains around the overlap time twice, i.e. both at the beginning and the end.

Regards,
Rob Roeterdink

[VicenteIR]

I've a question about the "location linked passing path" process. How does it work at locations where detaching/attaching and other commands of consist replacemants takes place?
I mean when the path of train is through the location whirh detaching of power units at the head and continues (leaving the location) my logic says that if an original platform is occupied by another train, the arriving train will taken to free platform. It's loco(s) will detach static consist and will continue on it's path. Will an attaching loco with path to original line (platform) been attached to the correct consist on passing path?

Regards
Oleg

[roeter]

 VicenteIR, on 04 August 2020 - 05:35 AM, said:

I've a question about the "location linked passing path" process. How does it work at locations where detaching/attaching and other commands of consist replacemants takes place?
I mean when the path of train is through the location whirh detaching of power units at the head and continues (leaving the location) my logic says that if an original platform is occupied by another train, the arriving train will taken to free platform. It's loco(s) will detach static consist and will continue on it's path. Will an attaching loco with path to original line (platform) been attached to the correct consist on passing path?

Regards
Oleg

No, I fear that's too complicated for the system to work out. It would require the system to automatically adapt the path of both the detached engine and the new engines to the new location of the train, and that's just not possible at present. In fact, there might not even be such a path - in complex station areas, it might well be that the siding where the engines are to go to or come from, are not connected to all platforms.
So the combination of passing paths at locations where also detach/attach actions are to take place could lead to real problems, and trains getting stuck.

Regards,
Rob Roeterdink

[Traindude]

 roeter, on 02 August 2020 - 02:03 AM, said:

You can start the timetable at 04:00, and include trains after midnight by using the $next qualifier for the start-time, so a train with starttime 01:00 $next will not start at the beginning of the timetable but after midnight at the end.

If there is no overlap of services this will work fine. If there is an overlap, you may need to include trains around the overlap time twice, i.e. both at the beginning and the end.

Regards,
Rob Roeterdink

Thanks Roeter. I was just curious.

Now, I'd like to take the opportunity to pitch a new concept in timetable mode--I call it "estimated departures".

In normal operation, a train is usually held at a station until the time shown in the timetable. For example, if a train is booked to depart a station at 4:00 PM, and loading time finishes at 3:59 PM, the train is detained at the station until 4 PM.

However, in some operations, such as commuter and rapid transit systems, it is inefficient to detain the train in this manner, and more efficient to keep trains moving, especially during peak commute times. Instead, what is done is that an "estimated" departure time is given as a guide for both passengers and operations staff, but the train is given authorization to depart immediately if loading time finishes before the time shown in the timetable.

My proposal is to give trains this authority by placing a "flag" of sorts in the departure time cell which lets the game know that it is not supposed to detain the train at the station, but instead let it leave early, if loading time finishes before the time indicated in the timetable (if traffic conditions permit).

That may sound a little confusing, so I'll try to clarify:

Without this "estimated departure" flag, you get "normal operation", which, in terms of departure time, means if loading time finishes before the time indicated, the train is detained until the time indicated in the timetable. For example, if a train is to depart at 4, and loading finishes at 3:59, then the train is detained at the station until 4.

However, once the "estimated departure" flag is added, what happens is that the game now lets the train depart as soon as loading time finishes, even though that may be before the time indicated in the timetable file (provided that traffic conditions permit this). So, instead of having the train wait until 4 before departing after loading ends at 3:59, the train can now depart immediately at 3:59.

I will add a Trello card for this later, but is this worth implementing?

[roeter]

Why not just set the intermediate timings a couple of minutes early? Than the train will behave exactly as you want. It will be reported as running a few minutes late but that has no consequences. You can add a comment in the timetable regarding the 'published' departure time.

Regards,
Rob Roeterdink

[Traindude]

 roeter, on 20 August 2020 - 01:27 PM, said:

Why not just set the intermediate timings a couple of minutes early? Than the train will behave exactly as you want. It will be reported as running a few minutes late but that has no consequences. You can add a comment in the timetable regarding the 'published' departure time.

Regards,
Rob Roeterdink

That's nice to know. But IMHO it still would be nice for the sim to not report it as "late," even though there is no harm done.