Topic: Proposal to replace 'mirror schedule' with standard's 'copy backward'

[freddyhayward]

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.

[wlindley]

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.

[freddyhayward]

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.

[Vladki]

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.

[Ranran]

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.

[freddyhayward]

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.

[Freahk]

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.

[freddyhayward]

 

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.

[Vladki]

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.

- 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.

    - the distinction between normal and reversed unidirectional journey time records.

What is the problem with this?

- 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.

- 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.

    - 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.

[freddyhayward]

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.

[Vladki]

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...

[freddyhayward]

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.

[Freahk]

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.

[Ranran]

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.

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.

[sdog]

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.)

[Freahk]

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.

[freddyhayward]

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.

[prissi]

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.

[knotwork]

I only in last couple of days installed (Ubuntu, apt-get install) both OpenTTD and Simutrans. So I am coming new/fresh to all of this.

It was my impression when I played that vehicles on a route were automatically turning around and going back through the route when they reached the end of the list of destinations.

Therefore when I made a circular route, I assumed I would start having buses going both ways on the route as soon as the first bus embarking upon the route reached the end of list of stops on the route and automatically turned around to go back.

Therefore at some point when it occurred to me to wonder what if one didn't want to return-journey but just go down the list again from the start I went looking for some kind of "jump to stop number whatever" or at minimum a "go directly to the first destination on the list"... Basically I reasoned that there surely must exist a go-to statement one could put on the list so as to avoid the automatic return journey through the list (what you are calling the reverse mode, that I had somehow gotten the idea was the automatic behaviour).

I think maybe OpenTTD, which I happened to try first, doesn't have a copy in reverse, so that it maybe was not until I got to trying Simutrans that I saw such a concept; which made me wonder why the heck one would copy it in reverse if all vehicles always automatically turn around and go back? Which led to the startling and annoying (only because I had built assuming to return journey was implicit?) discovery that lo and behold this button seems to be hinting that maybe they do not automatically turn around at the end of the route! Oh dear! The mechanics must (?) have been set up assuming circular routes? And further assuming therefore to have buses going both ways on your circular route you would have the buses going anti-routewise be a separate bus-line / bus-route? Hmm, weird.

Weird because if you do automatically reverse / return-journey at the end of the list that works great for linear routes and also for circular routes that you want buses going both ways on.

Now remember I was new to all this, and OpenTTD did not show a specific tile as a destination.

Which leads me to wonder why adding mail-trucks to the bus-routes was working at all?

Surely if the routes were to specific tiles, rather than to "generic" stop-names where a name refers to any/all stop-tiles of all kinds whether bus stops or mail stops or even (it had seemed to me) freight-stops at that name of destination, my mail would never have been picked up nor delivered, being as how my bus route if considered as specific tiles was, surely, to bus-stop tiles not to mailbox tiles?

Now I am really wondering!

Like maybe for some reason merely passing a stop-tile while enroute to a different stop-tile mail trucks were stopping anyway at the mailbox since they happened to pass it? If so then any of my named-destinations that maybe had vehicles passing in one or both directions not happening to directly pass right by the nearby and same-named-destination mailbox might never be having their mail picked up? I worry now!

Why is this being made so complicated?

If it is working (I do carry mail, despite only going from bus-stop-tile to bus-stop tile?) then why specify a tile at all, oughtn't buses look for a bus-stop within the named catchment, mail trucks look for a mailbox ditto, and freight trucks look for a freight dock ditto?

And if that were the case, wouldn't it make sense for all routes to automatically be re-traced (return-journey'd; reverse-directioned) by default unless a "goto" is used to force them back to the first destination instead of what amounts to "going round in circles whether route is circular or linear" ?

-MarkM-


 

[freddyhayward]

I'm not sure exactly what you're asking, maybe these points address some or all of it?
First, if you're using simutrans standard (the only version available via Ubuntu apt-get install), then there is no automatic reversing. Vehicles will always travel from the last stop directly to the first stop. Given stops A, B, C, D, E, F in a line, if you wanted to stop at all of them on the return trip you would need to set the schedule as A, B, C, D, E, F, E, D, C, B, which 'copy backwards' achieves. Extended does does this automatically if you check 'mirror schedule'. Neither version has implicit stops ilke OpenTTD does.
Second, there is no distinction between passenger, mail and freight tiles in either version. If a stop has any capacity for mail, freight, or passengers, then they will be enabled for all the tiles belonging to that stop.
Third, there is no 'go-to' feature in either version and there probably never will be.

[knotwork]

Actually OpenTTD has "goto" button with one of the options on that button's menu "conditional order jump".

Apparently it is used to do things like "if full skip next stop" or, I had assumed, if you wanted to not go back the way you came, you'd use it to "jump to #1". So I am guessing you mean Simutrans doesn't have an orders jump, or doesn't have conditional orders, or something along those lines...

Actually now that I think about it I might be able to use that if factories are in similar direction from consumer use it in collecting things to "if full, go directly to dropoff (consumer)" and have supply trucks circle producers until full before taking full load to consumer...

-MarkM-

[freddyhayward]

So I am guessing you mean Simutrans doesn't have an orders jump, or doesn't have conditional orders, or something along those lines...

Yes, simutrans does not have either of these.

Actually now that I think about it I might be able to use that if factories are in similar direction from consumer use it in collecting things to "if full, go directly to dropoff (consumer)" and have supply trucks circle producers until full before taking full load to consumer...

Simutrans does have this feature. You can have vehicles wait at one stop until fully loaded and then have them go to the next stop. Perhaps you could call it a 'conditional order' but it can't be used to skip or jump orders.

[knotwork]

Part of my problems could be not only that I started into OpenTTD and Simultrans at pretty much the same time but also that the guides I have studied likely date back different numbers of years so possibly many things in many guides are long out of date.

But I did get the impression that waiting to become full was a problematic strategy, because of something I actually did see for myself the moment I tried it: a truck waiting to fill would not let a truck arriving to deliver get past it to deliver inputs so that outputs the waiting truck was waiting for could be available.

It is good that I watched that truck after setting it to wait to fill, as I was right "there" to send it somewhere else for a moment to let the delivery happen before sending it back to see if maybe that delivery had allowed the factory to produce enough output to fill the truck.

So having had the experience happen exactly as some guides warning me against waiting for enough stuff to be loaded described, naturally the idea of simply going from supplying factory to supplying factory until full before heading to consuming factory was seeming interesting to me.

I have also, mostly I think in connection with airports, read a lot of stuff about building very complicated layouts which have a "reserved" parking spot for every truck so each has a place to wait out of the way of deliveries that the factory is going to need to receive before it has any chance of being able to fill you up.

I have also though been speculating that maybe instead of using one destination-name per factory maybe factories might be able to have more than one distinct destination, if so I could have "Blah Steel mill receiving" and "Blah Steel mill dispatching" kind of idea to prevent pickups blocking deliveries...

...At that time though I had the impression, from Simutrans having specific tile as destination rather than the destination by name as a whole, that if I wanted to just add more loading bay tiles I would then have to change each truck to know which loading bay it was to use. (If not then why have specific tile specified at all?)

Now I am wondering if maybe you specify a tile so that you can point to the head of the queue, to prevent incoming trucks stopping at the first bay they go through blocking others behind them from getting to the ones extending farther ahead...

-MarkM-

[freddyhayward]

You might be looking for choose signs, which allow trucks and buses to go to an available spot.

[Vladki]

Knotwork: some of what you say is possible:
You can build two or more separate stops near the factory, and use one for delivery and the other for pickup.
You can build one stop with two or more loading bays and schedule delivery to one of them and pickup to another. Or use the choose sign to allow vehicles to pick any free loading bay of the same stop.  I think that openttd behaves as if there is choose sign everywhere, but I am not sure.

There are no conditional skips in schedule. Only wait for x% load or wait for some time. So if you have multiple suppliers, you have to pick from all without waiting for load (or wait for appropriate fraction of load at each). Remember that they do not have the same production rates, and these can vary if you supply them with workers, mail and electricity.

Same applies if you have multiple consumers for one producer.
Because of the uncertainty and unprofitability if vehicles run half empty, it is more common to set up simple point to point connections.

About openttd, if i remember correctly, openttd vehicles stopped at whatever stop they were passing through, and there was special order to go non-stop. In simutrans vehicles ignore stops that are not in their schedule. That's why you have to exactly specify the reverse route.

I do not remember any conditional skips in openttd either, but I haven't played that for years.

Also the mirror schedule function is not good for trains, as you usually want trains to stop at different platform on the way back.

Fro circular lines there is the button alternate directions (in extended) which sends each new vehicles in opposite direction than the previous one. Also you can manually send any vehicle on reverse route (checkbox in convoy details).

It is common to send mail trucks along bus routes, the easy way to do it is to build stops on corners, one corner a bus stop, another mailbox. It does not matter on which one you stop, pax and mail can load on both (they are one stop). If there is a free tile nearby you can build a post office instead of post box. Also some paksets have combined bus stop with mailbox on one tile.

[jamespetts]

I notice that I had missed out on commenting on this earlier.

I added the mirror schedule feature to replace the "copy backwards" feature in the early days of what was then Simutrans-Experimental because I found the copy backwards feature to be virtually unusable; any alteration of a schedule would require duplicating the alteration in the backwards direction (and remembering to do this), and it was not undoable: one would manually have to delete each and every stop in a schedule in the backwards direction in order to make the schedule unidirectional again. Pressing the button twice by accident caused hopelessly jumbled schedules that would take a huge amount of time and effort to fix.

Note that there are plans for more sophisticated schedule options in the vehicle-management branch on Github, although that will need to be brought up to date with the latest master branch once the merge from Standard project on which Ranran is working has been completed. It is very important that any changes to scheduling be fully compatible with these plans and the work towards implementing them so far done on that branch.

[Freahk]

The mirror schedule and alternate directions feature are pretty useful one, but rather error-prone due to complexity spread all over the codebase.

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.

That's an old quote, but if nothing was significiantly changed here, it likely remains the same issue.

Instead of rolling back to "copy backward", the code should be reviewed, data strictly hidden from the public and public methods to operate on that data should be used instead, which handles all the complexity that comes with the reversed state and stuff like that internally.

That's also mandatory if we don't want the scheduling code to become as unmaintainable as the signalling code.
It will be a little more work to design the code but will save a lot of work in the future.

If someone is interessted in this and I got some more free time for simutrans (which might be in late January or February), we can review the code together, draft an object oriented design of schedules, based on that review and finally implemend that design.

[jamespetts]

If someone is interessted in this and I got some more free time for simutrans (which might be in late January or February), we can review the code together, draft an object oriented design of schedules, based on that review and finally implemend that design.

That would be a splendid thing, but whoever does this please bear in mind compatibility with the vehicle-management branch.

[Ranran]

As I said before, I'm trying to distinguish between reverse route and return path. (I don't know if the return path is correct English.)
That is, it distinguishes between performing a return trip of a mirrored ABCD schedule and repeating a DCBA.
The text of the check button will switch according to the schedule. I think this makes things clearer.
Somehow the arrows I've already tried to implement seem to be built in. Make it visible.
Currently only convoy info has changed. Please check it.

[freddyhayward]

As I said before, I'm trying to distinguish between reverse route and return path. (I don't know if the return path is correct English.)

"Return Trip" and "Reversed Route" would be a good distinction.

[Vladki]

I don't understand why "Return Trip" and "Reversed Route" should be different things?

[jamespetts]

I have now incorporated Ranran's renaming, with some modified translation texts.