[jugondavidlisto]

Hi Angelo,

with the renaming of the platforms to simulate two different stations it seems to be working as expected thanks.

[Angelo Rosa]

Perfect jugondavidlisto :)

[joe_star]

Hello,

Something I noticed recently while playing around with attach/detach commands, regarding timetable mode honoring end points specified.

From what I noticed, Timetable mode seems to ignore where I set the end point for the path, but runs the train as far along the straight track as it can and stops just before an upcoming node (assuming the track is free).

On the other hand, if I specify a dummy path for the detached portion, still within the same portion of track as where the previous train stopped, the detached portion does not move away from the original portion.

Is this expected/known behavior?

[joe_star]

Weter, on 31 March 2024 - 06:30 AM, said:

Hello.
Is it for just uncouple, but not leaving a platform?

Hello, no platform related, its at end of service on siding

You can see in the video below the scenario in action. The turntable is static so I doubt a factor here.

https://youtu.be/o2uS0JBPDeM

a) If I set the dummy path for the detached loco prior to the switch entering the turntable, the loco detaches then does nothing
B) Even if I set the dummy path end point just a few meters past the leading end of the switch (i.e. before the turntable), the locomotive moves to the end of the track section as seen in the video, rather than stopping at where I defined the end point of the path

[Weter]

B issue is known: path is being extended till the end of block of track.

[Laci1959]

Weter, on 31 March 2024 - 09:48 AM, said:

B issue is known: path is being extended till the end of block of track.

Unfortunately.

Such mistakes should be corrected instead of ambitious plans.

[Weter]

There is no such logic there. Alas.

[roeter]

Laci1959, on 31 March 2024 - 10:26 AM, said:

Unfortunately.

Such mistakes should be corrected instead of ambitious plans.

That a path is always extended to the next node (end of track section) is not a mistake, but is quite deliberate.
On signaled tracks, one generally wants to stop the train at the signal. If the end of path was used rather than the end of the section, one would have to place the end of path point quite accurate to make it look as if the train was stopped at the signal.
Another reason is that, in timetables, paths are often used for more than one train. If end of path position would be used, one would have to work out for which trains that path might be used, which of those trains is the longest and ensure that the end of path position is placed thus that even the longest train would clear all switches at the rear.
Furthermore, when the path ends on a section which has a platform, the end of path position would not be used anyway as the platform position would override this.
So, to make behaviour consistent and avoid having to set end of paths very accurate to get the train to stop at the proper position, it was decided to always extend the path to the end of the section (so upto the next node).
Clearly, one can't have it both ways, so there can indeed be situations where this is not ideal.

But there is an important lesson here.
When something is not working as one would like in a particular situation, don't immediately cry "error". Timetables are complex, and there are many different situations, and the implemented behaviour could well have been set up with such different situations in mind, as is the case here.
Also, do not immediately cry "change". Behaviour which has been quite deliberately set up in a specific manner to cover certain situations, and which has been around for such a long time, should not be changed simply because there might be another situation where the selected behaviour does not work out properly. Changing that behaviour after such a long time will likely cause severe problems for existing timetables.
So, rather than crying "error" and "change", think in terms of "improvement" and "extention".
In this case, a new qualifier for the #path field, e.g. named "$UsePathEnd", could sort this issue and allow users to choose, either to let the system work out the stop position as implemented now, or use the path end as new option.
Such extentions and additions are generally far more useful than to change existing behaviour based on a very specific situation.

All that is now required is to find a developer willing to implenent such a new qualifier. I'm afraid I cannot help you there, I am no longer active as code developer.

Regards,
Rob Roeterdink

[Laci1959]

Quote

Hello.

I can't really agree with that. In Hungary, the train must stop at the Stop sign. Even if the end of the train hangs out. Until then, the next train waits in the space (block) or at the other station. If the train has moved on, the following train can also move on. That is why the traffic attendant works at the railway station to solve such things.
Most European countries use such a sign.
The extension is also an improvement for me. It solves the problem and for me that's the point.
I don't want to derail the thread, but this phenomenon also exists in Activity mode, unfortunately. Or at least something similar. We struggled a lot with it years ago before it got good. In fact, he made the program route the so-called LOOSE consist and set the railway signal free. It had to be deleted because the Activity was not good.

Sincerely, Laci1959

[Weter]

One problem, I've encountered with such behavior was: the distance to switch's blades tips, where train stops, is too short, and train blocks adjacent exit of the switch.
This way, the offered option to take path's end point in account for particular case would be really needed.