My lastest pull request (https://github.com/jamespetts/simutrans-extended/pull/211) makes this change. It is often necessary to depart from a stop only to arrive at it again, usually for timetabling purposes to avoid reversing, or for moving to a siding attached to the main station. A real-world example of the former is the Kennington loop: https://en.wikipedia.org/wiki/Kennington_tube_station. To demonstrate its effects, I have attached the following save, which behaves differently before and after the patch.
That's really nice — bus terminals usually have arrival stops and departure stops in order to separate passengers by their destinations. Your patch enables this.
This is a good change :)
Quote from: Phystam on July 12, 2020, 03:24:11 AM
bus terminals usually have arrival stops and departure stops in order to separate passengers by their destinations.
Do they have this usually?
Might je a country specific thing, anyways this is definitely useful.
Quote from: Freahk on July 12, 2020, 03:15:03 PMDo they have this usually?
Might je a country specific thing, anyways this is definitely useful.
It is not to distinguish the destination but to separate the place to get off and the place to get on to make the flow of people more efficient.
If they just want to distinguish the destination, they don't have to separate the place to get off.
Buses for the urbs of Japan have separate doors for getting off and for getting on.
I have not applied the patch (because I don't know how! I'll wait for the next release or the nightly).
I'm confused why it was needed - I thought if you assigned a specific platform in a timetable and had no choose signals, it would behave as expected - leave the platform it arrives at, loop around and call at the same station on the different platform.
Using e836925 I can see that's not the case. I never knew this was how it worked so it is most useful - sidings and loops are extensively used in the UK, especially turn back sidings or run-around loops, thank you!
Quote from: KneeOn on July 12, 2020, 09:36:50 PM
I'm confused why it was needed -
To clarify, do you mean you were confused, or are you still currently confused?
Quote from: KneeOn on July 12, 2020, 09:36:50 PMI'm confused why it was needed
Imagine a situation where a convoy is waiting at the station for a schedule, causing congestion.
If this is not allowed, passengers will not be able to get off because they will not arrive at the station until the previous convoy departs. Passengers spend wasted time in the convoy.
It is not desirable for travel time to be long in extended.
Proper use of this should help reduce passenger travel time between stations. Empty convoy waiting after unloading passengers at terminal does not affect passenger travel time.
Isn't it possible to put a waypoint between the two stops?
Quote from: Vladki on July 13, 2020, 03:00:07 PM
Isn't it possible to put a waypoint between the two stops?
Yes, but it would have no effect.
I have implemented passenger turnback sidings in existing games by building a goods-only station in the siding(s). It has worked very well (some sidings have 5 roads and handle 3 different routes, with choose-signal entrances). The advantage is to prevent blocking of vey busy stations by reversing services.
E.g. city centre stations with 6 or 8 routes running through both ways, on average each route runs every 30 minutes (so a train every 3 or 4 minutes), but only 4 platforms in total and only double track in and out (can't increase due to limited space in town). Totally impossible if even one line reverses in-station, but reversing sidings keep it smooth even in most cases of service disruption.
This change makes life simpler for sure, so congratulations & thank you.
This looks interesting. However, on reviewing the code, I note that it deletes code without replacement that was implemented as a fix to a reported bug in 2015 with the commit message:
FIX: Trains would not advance their schedules properly in stations in some cases
(See commit no. 03ea2e9492ebd927076c2ce44a6e4294dbdb788a of the 6th of September 2015).
I am concerned that, if I integrate this, this will cause the bug reported that lead to this fix to recur. To integrate this, we will need to find the original bug report, test that this behaviour does not occur with the current master branch version, apply this patch, and test whether this behaviour occurs with this patch applied.
After searching for a while, I couldn't find any relevant bug reports on this forum or on github.
Quote from: freddyhayward on July 19, 2020, 02:43:09 PM
After searching for a while, I couldn't find any relevant bug reports on this forum or on github.
In that case, it will be much harder to test whether this behaviour breaks the thing that the part of the code removed intended to fix; the bug may have been one that I identified myself. What is needed is to identify the cases in which trains would not properly advance their schedules in stations (and this may be a rare and complex edge case only in certain signalling systems with certain schedule settings, etc.) and test this with the new code.
I am afraid that it strikes me as very unlikely that code that was clearly needed in 2015 has since become redundant, so just removing this is unlikely to be workable.
I have updated the patch so that it retains the original fix from 2015. The condition now checks whether the scheduled stop is at the same position as the convoy, instead of at the same stop. I doubt the modified condition would hinder it from detecting whether a schedule has actually failed to advance, since a different position within the same stop would now be a valid advancement.
Excellent, thank you for this. I have now incorporated this.