The International Simutrans Forum

 

Author Topic: Proposal to replace 'mirror schedule' with standard's 'copy backward'  (Read 442 times)

0 Members and 1 Guest are viewing this topic.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 456
  • Languages: EN
In summary, the 'mirror schedule' feature offers a small amount of convenience at the cost of reduced control and increased complexity. Replacing it with 'copy backward' from standard and potentially adding utilities for copying and reversing lines would bring many improvements. This change would:
- Eliminate the following:
    - the 'Reverse schedule' button for all convoys.
    - the 'Alternate directions' option in the schedule window
    - the distinction between normal and reversed unidirectional journey time records.
- Greatly simplify all code relating to schedule traversal making it less bug-prone and easier to contribute to.
- Bring schedule-related code closer to standard making it easier to port over any fixes or improvements.
- Prevent unexpected behaviour when:
    - replacing convoys where the 'reverse schedule' setting is reset.
    - sending new vehicles from the depot to wait for schedule, where departure slots are duplicated because of differing 'reverse schedule' settings.
    - setting convoys to a different line where the 'reverse schedule' setting is retained, even when the new line does not have 'mirror schedule' enabled.
    - disabling 'mirror schedule' on a line where half the convoys will now travel in the wrong direction until the player notices.
« Last Edit: October 20, 2020, 12:47:30 AM by freddyhayward »

Offline wlindley

  • Devotee
  • *
  • Posts: 1030
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #1 on: October 19, 2020, 11:16:34 PM »
The only use case I have for "Reverse Schedule" is in creating loop lines (with mirroring turned off) and having some convoys operate "clockwise" while others operate "anti-clockwise." That minor convenience is probably not worth all the weirdnesses and complexities. Support.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 456
  • Languages: EN
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #2 on: October 19, 2020, 11:35:01 PM »
The only use case I have for "Reverse Schedule" is in creating loop lines (with mirroring turned off) and having some convoys operate "clockwise" while others operate "anti-clockwise." That minor convenience is probably not worth all the weirdnesses and complexities. Support.
This use-case could be supported by copy (i.e. creating a duplicate line) and reverse (i.e. reversing the schedule itself rather instead of traversing it in reverse order) operations on lines.

Offline Vladki

  • Devotee
  • *
  • Posts: 3497
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #3 on: October 20, 2020, 12:00:20 AM »
I object. The reverse and alternate directions are very useful for bus lines. The alternate direction for circular lines, where you want half of the convoys to run in opposite direction. And reverse for linear lines. Both are extremely helpful when you are extending or modifying a line. In standard, once you "replicate backwards" you have to modify both directions.

I like the reversal of lines as is.

It can be removed for trains and similar, where it is mostly useless, but keep it for road, air and ships.

Offline Ranran

  • Devotee
  • *
  • Posts: 1283
  • Languages: ja
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #4 on: October 20, 2020, 12:18:53 AM »
I would rather not support it either.
As already pointed out, convenience is born in some waytypes.
However, there are some parts that can be understood in terms of code maintenance.

I have a plan to add a symbol to distinguish between reverse order and return trip.

For example
Next stop: B
Next stop: B (return trip symbol)

The former can be distinguished from A to B and the latter from C to B.

Convoy A - Line 1
Convoy B - Line 1 (reverse order symbol)
Convoy C - Line 2
Convoy D - Line 2 (return trip symbol)

Line 1 is not a mirror schedule, but Convoy B is patrolling in the opposite direction.
Line 2 is a mirror schedule, but you can see that Comvoy C and Comvoy D are moving in opposite directions.

Freddy's idea would make it impossible.
Certainly this does not help on lines such as railways that use different platforms.

Another possible issue is migrating from existing saves. That's not impossible, but I think it will increase the coding effort.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 456
  • Languages: EN
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #5 on: October 20, 2020, 12:45:57 AM »
Vladki, your objection is quite valid, and I now realise that progressing this idea would require developing solutions that address your use-case. These would be features that operate as part of schedule editing instead of being the responsibility of convoys.
Ranran, your symbol idea would need to have a separate symbol for the non-return or non-reverse directions. Otherwise the absence of a symbol could be confused for one of those two. I don't think that idea, nor the one-time save version effort of conversion would justify the current system which causes many problems, though Vladki's use-case does.

Offline Freahk

  • Devotee
  • *
  • Posts: 1355
  • Languages: DE, EN
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #6 on: October 20, 2020, 02:27:02 AM »
I do practically always use "reverse route" on bus, ship and air lines. It's a very useful features, as long as there are no oneway avenues involed, in which case I do really miss the "copy backward" button from standard.

On any rail-like waytpe, extendeds reverse route feature is indeed quite useless, except from some rare edge cases. Standards "copy backward" is just as useless here.

Imho, a simple checkbox in the line window, which by default disables all reverse route related features on that line should fix the most critical issues.
"Alternate directions" should at any time ensure, that every second vehicle is reversed.
"Mirror schedule" should, as-is simply toggle vehicles reverse route state at the terminals
"Reverse route" in the vehicle window should work as-is
"Enable reversal features" or something like that in the route window should enable the posibility to use these above features. Disabling it should uncheck and hide lines "Alternate Directions", "Mirror schedule" as well lines vehicles "Reverse route" checkboxes.

I don't see where the "eliminating" point really is an advantage?
In the points of simplifying code and getting closer to standard, I am in principle with you, but in a different way. The former might be achieved by cleaning up the code. As this feature improves usability quite a lot (at least in my opinion), standard should consider backporting it once the code is clean and it's working properly.

The "unexpected behavior" points are solved by the above suggestion, except from the convoy replacement feature, which should indeed retain the "reverse route" state.
« Last Edit: October 20, 2020, 02:47:03 AM by Freahk »

Offline freddyhayward

  • Devotee
  • *
  • Posts: 456
  • Languages: EN
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #7 on: October 20, 2020, 03:54:03 AM »
 
The "unexpected behavior" points are solved by the above suggestion, except from the convoy replacement feature, which should indeed retain the "reverse route" state.
It wouldn't solve the problem where sending vehicles from the depot to the first timetabled stop on a mirrored line will lead to duplicate departures. The code is inherently more complex because anything that needs to increment schedules also needs to keep track of the reversal status. It can't just be cleaned up.
What I am thinking of is shifting reversing status away from convoys and towards lines. We might hold two different schedules per line: a base_schedule and a flattened user-facing modified_schedule. This will allow for non-destructive editing of the modified_schedule, and for destructive changes of the base_schedule to be reflected in the modified_schedule. All code that uses schedules without editing them (e.g. the path explorer) will also use the modified_schedule.

Mirrored schedule example:
Code: [Select]
Current representation:
[A, B, C, D, E, F], mirrored, (+ per-convoy reversal status)

New representation:
[A, B, C, D, E, F], mirrored
(editing stops A-F will modify e-b and vice-versa.)
modified schedule: [A, B, C, D, E, F, e, d, c, b]

Two loops example:
Code: [Select]
Current representation:
[A, B, C, D, E, F] (+ per-convoy reversal status)

New representation:
(editing line 1 will edit line 2 and vice versa. if line 1 is deleted, line 2's modified schedule becomes its base schedule)
Line 1: [A, B, C, D, E, F]
Line 2: [inverts other line: Line 1
line 2 modified schedule: [f, e, d, c, b, a]
I can see that this is a coding effort, and you might think: "doesn't this just add more complexity?" Yes it does: it adds complexity to the schedule editing feature, but also reduces complexity in all schedule traversing logic. It allows the status of any position within a schedule to be represented by a number, instead of a number plus reversal status. Given an index, one can know with certainty what the previous stop was, and what the next stop will is.

Offline Vladki

  • Devotee
  • *
  • Posts: 3497
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #8 on: October 20, 2020, 10:24:22 AM »
I do not see many of these as problems:

In summary, the 'mirror schedule' feature offers a small amount of convenience at the cost of reduced control and increased complexity. Replacing it with 'copy backward' from standard and potentially adding utilities for copying and reversing lines would bring many improvements. This change would:
As said before, IMHO it is a lot of convenience especially for road, air and ship transports.

Quote
- Eliminate the following:
    - the 'Reverse schedule' button for all convoys.
    - the 'Alternate directions' option in the schedule window
I'm OK with removing these for rail-like transports, or (as Freahk) suggests - disabling the reverse button on convoys if neither reverse or alternate is checked in line schedule.

Quote
    - the distinction between normal and reversed unidirectional journey time records.
What is the problem with this?

Quote
- Greatly simplify all code relating to schedule traversal making it less bug-prone and easier to contribute to.
- Bring schedule-related code closer to standard making it easier to port over any fixes or improvements.
I would prefer if the code is cleaned up enough so these features can be ported to standard.

Quote
- Prevent unexpected behaviour when:
    - replacing convoys where the 'reverse schedule' setting is reset.
    - setting convoys to a different line where the 'reverse schedule' setting is retained, even when the new line does not have 'mirror schedule' enabled.
    - disabling 'mirror schedule' on a line where half the convoys will now travel in the wrong direction until the player notices.
Again these call for improvement, not removal.
- Replaced convoy should retain it's reversal status. (And there are more improvements regarding replacement in depot possible, e.g. find nearest suitable stop to go to/from depot, etc...)
- convoys changing a line should either reset reversal (if the line has not chcecked reversal/alternate) or set it so that half are reversed and half are not.
- disabling reversal/alternate on line, should reset reversal on all convoys.
- Enabling reversal/alternete should set reversal on half of line's convoys
- I would even vote for a button to set reversal on all vehicles.

Quote
    - sending new vehicles from the depot to wait for schedule, where departure slots are duplicated because of differing 'reverse schedule' settings.
I'm not sure I understand this correctly. I think it is OK if vehicles with differing reversal status are departing at once.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 456
  • Languages: EN
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #9 on: October 20, 2020, 11:03:45 AM »
The trouble is that this feature has an inherent complexity that cannot be 'cleaned up', in fact the improvements that you suggested would add to the existing abundance of special edge cases required to deal with the issues caused by it. Have you read my reply to Freahk? I have suggested an alternative that preserves almost all of the convenience of the mirror schedule feature.
As for your last point, suppose you have a daily mirrored ferry service. The ships wait at the first stop at the top of the schedule. Therefore all ships waiting there for the first time will have 'reverse schedule' unchecked, but all ships waiting there for subsequent times will have it checked having arrived from the return journey. Sure, this can be fixed by yet another special case, but as the spaghetti increases in length it becomes harder to untangle.

Offline Vladki

  • Devotee
  • *
  • Posts: 3497
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #10 on: October 20, 2020, 11:19:49 AM »
Yes I read you suggestion, but that looks also quite complicated - having one schedule for the player to manage, and another one, generated from the first, for the convoys to follow...

Offline freddyhayward

  • Devotee
  • *
  • Posts: 456
  • Languages: EN
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #11 on: October 20, 2020, 11:36:09 AM »
Yes I read you suggestion, but that looks also quite complicated - having one schedule for the player to manage, and another one, generated from the first, for the convoys to follow...
Both systems generate a secondary schedule, except that mine stores it as a schedule, while the current system stores it within several layers of code.

Offline Freahk

  • Devotee
  • *
  • Posts: 1355
  • Languages: DE, EN
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #12 on: October 20, 2020, 02:59:05 PM »
It wouldn't solve the problem where sending vehicles from the depot to the first timetabled stop on a mirrored line will lead to duplicate departures.
Ah, that's what you meant. Seems like I have missunderstood this point. That's abug which needs to be fixed.
Why can't his be cleaned up? We can safely assume convoys in a mirrored route to always arrive reversed route state at the first stop in the route, just like we can always asume those to arrive in non-reversed route state at the last stop. So we can just ignore their actual reversed state at the first and last stop of a mirrored schedule.

Except from that, cleaning up does not neccessarily mean to stick with the exact internal implementation. It just means to stick with the concept and behavior from the users perspective.
- vehicles can run on a s chedule in opposite direction
- schedules can make vehicles to reverse their route at each end of the schedule
- vehicles can be sent out of the depot in alternating "reverse route" state.

I see the point in your suggestion. Operating on the base schedule plus reversed state is indeed rather error prone.
It might or might not be a good option to internally store return routes explicitly, I am not sure about this.
We will still need to represent the "reversed" state to the user.
This approach makes route iterations more easily to handle, but it adds complexity elsewhere.
I agree overall this might be slightly less error-prone, but I do not think this solves the key issue behind all of this.

At this moment, at 198 locations in the code the schedule_t::entries is used directly. Only 88 of these come from the schedule_t class by itself.
If we really want to improve reliability, we should clean this up.
At first, analyse what all these accesses actually do.
Then break these operations down into a small set of methods with well-defined behavior and make all these places in the code to use those methods.
Finally, set the schedule_t::entries attribute to be private, so new code cannot do the same mistake again.

Maintaining a small set of well-defined methods is much easier than maintaining hundreds of locations in the code that basically all do the same.

When designing these methods, we can think about if it's better to pass an index plus reversal state or to pass only an index, disregarding how the datastructure is organised internally.

In Object oriented design, you virtually never want attributes to be publicly accessible for those two exact reasons.
1. You are limited to a specific implementation, as code located elswehere will rely on it.
2. Code handling the internal state of your object will be spread all over your codebase, which is a maintainance hell.
« Last Edit: October 20, 2020, 03:15:28 PM by Freahk »

Offline Ranran

  • Devotee
  • *
  • Posts: 1283
  • Languages: ja
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #13 on: October 20, 2020, 05:27:28 PM »
Sadly it feels like a coder's ego. I think the more useful features we add, the more complicated our code will be. (I'm not saying that it is good to reduce maintainability unnecessarily)

Think from the player's point of view.
Currently, there are passenger routes to and from 10 stops on the ship(or bus) line. You will see 10 stops at the bottom left of the schedule list.
I feel that it is bad to increase it to 19. As such the list is very crowded. I don't like it because it's inconvenient.

And it takes more time to restore and delete. For example, if you accidentally press copy backward, you will have to delete the increased amount.
You have to select twice to remove one station from the round trip. It's also a hassle to check if they were deleted correctly or in the wrong order on long routes.
Similarly, the load and wait setting must be done twice.

And for the average player, it would be easier to understand the round-trip route as one line. Because in the real world, route maps are represented that way.
The Eurostar route map should not draw the going and returning separately. That is the route map of the line drawn in the player's brain.

Therefore if possible, I would like to fix the bug while maintaining the current style.

Quote
your symbol idea would need to have a separate symbol for the non-return or non-reverse directions
I'm sorry I don't understand the need for that distinction. Because it is intended to distinguish within the same line. A reverse order symbol and a return trip symbol cannot exist on the same line at the same time.
Also, the label of the current switch button switches depending on whether the schedule is a mirror.


Offline sdog

  • Devotee
  • *
  • Posts: 2052
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #14 on: October 20, 2020, 06:30:14 PM »
When reverse schedule was introduced it fixed routing problems we had with ring lines. Pax packets go the right way in ring lines. Whereas in standard back then having a clockwise and counter clockwise line caused a large portion of pax being routed the long way around the circle. On case you want to change it, check if present routing works correctly on circle lines.

Besides, for me this is one of the three reasons I rather play experimental than standard. (The other are the vehicle replacer and walking pax.)

Offline Freahk

  • Devotee
  • *
  • Posts: 1355
  • Languages: DE, EN
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #15 on: October 20, 2020, 07:53:23 PM »
I think it's quite convinient to set such services up as a single line.
As far as I understand, Freddys suggestion does not disallow this, nor does mine.
Freddys suggestion is just a different way to store the data.
« Last Edit: October 20, 2020, 08:27:29 PM by Freahk »

Offline freddyhayward

  • Devotee
  • *
  • Posts: 456
  • Languages: EN
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #16 on: October 21, 2020, 02:23:18 AM »
This suggestion does not seem to be very popular, for some very valid reasons. I think that at this point, the best approach is to attempt a number of improvements suggested by others including:
* Force all convoys being sent from the depot to the first stop in a mirrored schedule to be reversed, and all convoys being sent to the last stop in a mirrored schedule be non-reversed.
* Always retain reversal status when replacing vehicles.
* Implement more line-wide actions that set the reversal status of vehicles - though this will have to be carefully thought through to avoid more anomalies.
* Clean up the code. I suggested that this would be hard to do, but maybe there is some progress to be made there.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10303
  • Languages: De,EN,JP
Re: Proposal to replace 'mirror schedule' with standard's 'copy backward'
« Reply #17 on: October 21, 2020, 02:55:46 AM »
Quote
Whereas in standard back then having a clockwise and counter clockwise line caused a large portion of pax being routed the long way around the circle.

This is simply not true, at least if you have both lines. (And since at least 8 years or so.) The routing in standard does not care whether a line goes clockwise or not. The pax will board the next vehicle with free space left to their destination, with the first loaded for next stop, then for the second and so on. This automatically ensures that most of them go the short way round, if there is enough capacity left on that line.

The standard station routing will always try to minise the number of stops. However, if the physically long route is just one stop, then indeed standard will do the "long" route. This is because of Extended routing weighted with travel times, not stops, but has nothing to do with reversing schedules. So testing circle lines should only reveal bugs but shoudl no reveal new insights.

Personally, I think having a copy line backwards button is much more useful, as it clearly shows then which convois are running forward and backward and may even introduce a slightly different route for counterclockwise traveling. If this does not make it in extended, it might see it in standard.