[patch] Allow convoys to follow their schedule in reverse automatically

[yobbobandana]

Edit: final patch link: SVN3445-Allow-convoys-to-auto-reverse-v5.diff

Hi,

I had a feature that I would have liked to use in my games... so I coded it in myself . I'm now wondering if this would be suitable for inclusion into the main simutrans code?

(1) The issue I had was that I found the "mirror schedule" button a little difficult to use.

It would be better, I thought, to have a toggle flag, in stead of adding all the stops to the schedule twice. This would make the later adding of stops to return schedules much easier as you wouldn't have to search thru and add each stop twice. The vehicles would automatically follow the schedule in reverse upon reaching the end.

After I added this functionality I realised I could use it to fix another issue I had:

(2) With circular bus routes, I often make double schedules, one simply duplicating the first in reverse to minimise congestion.

At first I thought to allow buses to choose a random direction and stick to it, but then I realised that it would be even better if buses would sometimes switch directions.

So I also added a "circular route" toggle for schedules. If it is set, each vehicle has a 25% chance of switching direction each time it completes the schedule.

I found this to be really effective at eliminating congestion from my circular bus routes . With is in effect, I just tell all my buses to go at once, and they spread around of their own accord over time, in stead of all bunching together behind the slowest one.


So now I have two questions:
a) would this be suitable for inclusion in simutrans?
b) did I miss thinking about something, such that this change will make some other usage case harder? Was there some other use of the "mirror route" button that wouldn't be served with both a "return trip" toggle and a "circular route" toggle?

change summary:
(1) change mirror schedule button into a toggle switch
(2) add another toggle switch that causes vehicles to sometimes switch directions after finishing a circuit.

Here is the patch, if anyone wants to look at it

[VS]

Interesting idea I think we haven't seen that one yet...

[wlindley]

I like.  The only case not covered is for trains on double-track lines, on which you need to define a stop for each platform location, but with the way choose signals work now, even that might not be a problem anymore (so long as each station on a 'replicate backwards' route has a choose signal in the 'reverse' direction... yes?

[prissi]

Choosing is only done, when the initial platform is free. Furthermore, first a route to the initial platform is calculated.

Main thing I do not like is the 25% chance; I would like to keep things predictable and do not run my vehicles at random. I would rather have a line setting and then every second vehicle would run the line conterclockwise.

[skreyola]

:support: vehemently! I HATE clicking "Remove Stop" a dozen times to add a stop to a recprocating line.

Main thing I do not like is the 25% chance; I would like to keep things predictable and do not run my vehicles at random. I would rather have a line setting and then every second vehicle would run the line conterclockwise.

This.
:support:

[Fabio]

Main thing I do not like is the 25% chance; I would like to keep things predictable and do not run my vehicles at random. I would rather have a line setting and then every second vehicle would run the line conterclockwise.

It could have a percentage settings: 0%, 25%, 50%, x% of the vehicles runs backwards. Very predictable

[skreyola]

It could have a percentage settings: 0%, 25%, 50%, x% of the vehicles runs backwards. Very predictable

Or, to be more predictable/less random: Every 1/<2> convoy added to the line will run reverse.

[jamespetts]

This is a good idea, and I agree with Prissi about predictability - it is better to be in control, I think.

[yobbobandana]

Okay so, in the interests of predictability I changed the behaviour as prissi suggested. For circular routes, vehicles are alternated between forward and reverse directions as they are added to the line.

I also added a toggle box in the vehicle info window, so you can see whether individual vehicles are travelling forward or reverse. You can also directly change it for each vehicle . This should allow easy management of individual vehicles.

It would be easy to add functionality to change the proportion of vehicles going forward/reverse, but I think with the ability to manage individual vehicles it should be okay.

I couldn't bring myself to remove the random direction changing entirely, so I relegated it to an obscure option (defaults to off)... I don't like adding options, but it really worked wonders on my gridlocked bus network, and I'll certainly be playing with it on.

What do you think?

[sdog]

This is patch should improve gameplay greatly! Something i always wished, but never dared to ask.

Please add this functionality also for non circular, return routes (the ones formerly mirrored). Every second vehicle will be sent on the return branch. Also allow the player to toggle this on the vehicle window, this makes it easier to break up bunched vehicles by short-turning them.

please also add information if it is on a circular or normal return route:

"circular route  [ ] reverse route"

"round-trip route  [ ] retoure"

[yobbobandana]

Please add this functionality also for non circular, return routes (the ones formerly mirrored). Every second vehicle will be sent on the return branch.

Ahh, good idea. I updated it to do this properly.  If you set both "circular schedule" and "replicate backwards/round trip" it will send half the vehicles to the end of the route when they leave the depot.

Also allow the player to toggle this on the vehicle window, this makes it easier to break up bunched vehicles by short-turning them.

please also add information if it is on a circular or normal return route:

"circular route  [ ] reverse route"

"round-trip route  [ ] retoure"

I think (unless I misunderstand) both of these are already in my patch - you can now switch any vehicle's direction from the vehicle info window.

The other info is found under the vehicle's schedule .

Unless you mean for the circular/round-trip status to be displayed in the vehicle's info window, but I didn't want to add too much extra info if it's ok to access via the "schedule" button.

Anyway here's the v3 with the proper behaviour for setting both "circular" and "round trip".

(PS: I'm still not sure of the correct terminology to use for these lots of words with very similar meanings)

[sdog]

i'm just patching it into experimental, and i'm so incredibly surprised how incredibly clever patch is. before i tried it only patch on identical source files, which was rather boring. But know patch spots the offsets not only the offsets (not surprising) but fuzz actually fits it in at good spots after quite some changes!

I think (unless I misunderstand) both of these are already in my patch - you can now switch any vehicle's direction from the vehicle info window.

I missunderstood you there before.


let the people at simutranslator decide on the proper names :-P

Update
briefly tested it in standard without, it worked, no crashes.

"Circular route" is now a misnomer i think. It only causes every other vehicle to start at the end of the list. Both boolean can be set at the same time. While a real circular route is the default anyway.

At the vehicle screen the buttions for 'statistics' and 'details' where uresponsive, is this related to the recent gui work of Prissi? (haven't tried the latest nightly)

[jamespetts]

This looks very interesting! Now all that we need is a way of automatically marking railway station platforms as "up" and "down", with the automatically selecting the correct one when going in the relevant direction, and the system could work for trains, too! (Although this, I imagine, will be quite a complicated thing to implement, so perhaps a pipe dream...).

[sdog]

silly ingame workaround to use this for trains on double tracks:

three platforms, the central platform only one tile. Stops are set to that platform. choose signals (C) on both entrances to the station, after that a connection to the central platform, no route back from the central platform to the opposite direction. Now block the central platform with a crappy, cheap tain all the time.  ;-P


->--C--=====---------
          `---=-----\
--------=====---C----<--


Less jokingly, it will already work with Choose and end End of Choose signals well enough. Destination is set to the central platform.

->-C\---===-E--------
         \--===--\
-------E-===---\C--<-

[skreyola]

@sdog: It would be much cheaper (over 1,000c) to just make a double platform with one-way choose signals, like this:
-----C-V-====-V----->----
-<-----^-====-^-C-------
because you don't need to buy end of choose signs (which I think do nothing in your example) and no need for a third platform/dummy engine. All platforms will be utilized, and the lanes will be respected.

@yobbobandana: Awesome patch. Can't wait to see it in the game.

[sdog]

The problem with the two platform setup is for low utilisation that one train most of the time has to switch ways, while the other keeps his side, breaking the symmetry and delaying the back route, causing load imbalances. This is particulary bad for circular lines! Since rather small shifts in travel time between two rings can cause passengers to take the longer way, on the opposite train (counterrotating ring).

For higher utilisations it chokes the network, as trains will often switch their sides with each other. Causing any of the trains to wait. As the state could suddenly change and trains use their own way for a while, this also leads to fluctuations.

From the view of construction or running costs the 3 platform setup isn't that bad, since no station extension buildings are required to bridge the gap between both lines. (I think most players leave one or two rows empty between double tracks, for later branches, etc.)

[yobbobandana]

This looks very interesting! Now all that we need is a way of automatically marking railway station platforms as "up" and "down", with the automatically selecting the correct one when going in the relevant direction, and the system could work for trains, too! (Although this, I imagine, will be quite a complicated thing to implement, so perhaps a pipe dream...).

One option I had thought of for this, is to just change the routefinding code to stop early if it finds a connected part of the station it's routing to. Always for me in this situation the trains pass straight thru the station I want them to stop at (very frustrating).

I implemented this quickly to test. But I'm sure there are many situtations in which it would cause unwanted behaviour. For example if you actually want your train to pass thru a connected part of the station before reaching its intended platform. Or if the first platform it finds is too small, or other concerns.

I pushed this change to the testing branch of my simutrans-experimental github repo if anyone wants to look...
patch in question:
http://github.com/mesilliac/simutrans-experimental/commit/513177e029de9710fe89ac1c5e76ec7d0c506f55
branch link:
http://github.com/mesilliac/simutrans-experimental/tree/testing

Actually I was developing this reverse routing change there too which brings me to

i'm just patching it into experimental

sorry I didn't say that I was already pushing to my github testing branch! But the code I submitted as the SVN diff was actually cleaner and a little different, so if you've successfully patched it in to simutrans-experimental, your version is almost certainly better to use than the patches from my dev branch . In particular I never sorted the save game stuff for experimental.

@skreyola: thanks

[sdog]

[about patching to experimental] In particular I never sorted the save game stuff for experimental.

That's the point where i failed last night. But it was mostly a try, in order to get more familiar with the code and the tools.

[skreyola]

@sdog: How about this, then?

Code Select Expand


---->-\     /---->-
       >===<
-<----/     \-<----

Symmetrical travel time, only one platform (until three are needed for volume)...

[sdog]

Stop routefinding early if a connected station is found.

->---==x=--->---  (a)
-<---====---<--- (b)

i thought this would mean if at this set up the destination is set to the 'x'. The train would on the reverse path, when it gets into the station stop its routfinding and call [sic?].

I compiled from your commit to experimental 30a41880ec55a131cda9 (about 23h utc - where can i find the actual time btw) and it doesn't work as in the example. It circles the whole network to get on the (a) line to stop at the destination. Like standard simutrans behaviour.

Vehicles that wait at a stop must use the exact platform specified.

That's a very good idea!

loading an old savegame did not work:

Code Select Expand


FATAL ERROR: loadsave_t::rdwr_str()
string longer (390) than allowed size (256)


Program received signal SIGABRT, Aborted.
0x00007ffff6c1fa75 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff6c1fa75 in raise () from /lib/libc.so.6
#1  0x00007ffff6c235c0 in abort () from /lib/libc.so.6
#2  0x000000000063ad24 in log_t::fatal (this=0xa7c3c0,
   who=0x67392b "loadsave_t::rdwr_str()",
   format=0x673a28 "string longer (%i) than allowed size (%i)")
   at utils/log.cc:242
#3  0x0000000000466366 in loadsave_t::rdwr_str (this=0x7fffffffb240,
   s=0x7fffffffac30 "", size=256) at dataobj/loadsave.cc:739
#4  0x00000000005af24f in convoi_t::rdwr (this=0x7fffe2072f40,
   file=0x7fffffffb240) at simconvoi.cc:2866
#5  0x00000000005a374b in convoi_t (this=0x7fffe2072f40, wl=0x7fffe843cc30,
   file=0x7fffffffb240) at simconvoi.cc:199
#6  0x000000000062a56d in karte_t::laden (this=0x7fffe843cc30,
   file=0x7fffffffb240) at simworld.cc:4649
#7  0x0000000000628882 in karte_t::laden (this=0x7fffe843cc30,
   filename=0x7fffe83f7a30 "\360\276\246\352\377\177") at simworld.cc:4293
#8  0x0000000000518c55 in loadsave_frame_t::action (this=0x7fffe828a030,
   filename=0x7fffe83f7a30 "\360\276\246\352\377\177")
   at gui/loadsave_frame.cc:51
#9  0x000000000053c2ca in savegame_frame_t::action_triggered (
   this=0x7fffe828a030, komp=0x7fffe828a620, p=...)
   at gui/savegame_frame.cc:397
#10 0x00000000004ab513 in gui_action_creator_t::call_listeners (
---Type <return> to continue, or q <return> to quit---
   this=0x7fffe828a620, v=...)
   at gui/components/../../ifc/gui_action_creator.h:36
#11 0x00000000004c5aea in gui_table_t::infowin_event (this=0x7fffe828a608,
   ev=0x7fffffffb890) at gui/components/gui_table.cc:146
#12 0x00000000004c3252 in gui_scrollpane_t::infowin_event (
   this=0x7fffe828a808, ev=0x7fffffffb8f0)
   at gui/components/gui_scrollpane.cc:101
#13 0x00000000004fce12 in gui_container_t::infowin_event (this=0x7fffe828a038,
   ev=0x7fffffffb970) at gui/gui_container.cc:93
#14 0x00000000004fe6ef in gui_frame_t::infowin_event (this=0x7fffe828a030,
   ev=0x7fffffffba00) at gui/gui_frame.cc:89
#15 0x000000000053cf94 in savegame_frame_t::infowin_event (
   this=0x7fffe828a030, ev=0x7fffffffba00) at gui/savegame_frame.cc:534
#16 0x00000000006136cf in check_pos_win (ev=0x7fffffffbb30) at simwin.cc:938
#17 0x000000000062e3ed in karte_t::interactive (this=0x7fffe843cc30,
   quit_month=2147483647) at simworld.cc:5617
#18 0x00000000005e4291 in simu_main (argc=1, argv=0x7fffffffe2d8)
   at simmain.cc:1075
#19 0x0000000000669491 in main (argc=1, argv=0x7fffffffe2d8) at simsys_s.cc:748


wait, made an mistake when copying the binary, i think. tested old version perhaps
just didn't realise it's already 01:30, eg. a new date. above happens with latest build.

[yobbobandana]

Ahh, sorry! It turns out I completely broke it with that second commit (30a41880...). It should now work just like you drew.

*ahem*, turns out it wasn't doing anything at all

I also hopefully fixed the savegame loading. Saves from the current git will probably still break, but any from 8.0 or prior should work. Thanks for the backtrace .

Re: the original auto-reversing patch:

I'll probably leave out these routing changes for trains. I can put them in a separate patch if they work out well.

So probably the only changes to the -v3 patch I attached above will be to change the name of the "circular" button to something better... "alternate direction" maybe?

Also I can remove that random direction switching option if anyone objects to it being there. I'm probably the only one who would ever use it, and it's already in my copy... .

[jamespetts]

The platform issue probably needs considering in more depth. There are some situations where a user needs to specify a particular platform, and some situations where a user needs for a train to use one platform in one direction and one in another. But it's not enough simply to allow the user to say "any platform" for certain stations, because there are some stations where a user needs a train to go into one particular platform in one direction, and another in another. Take the example of a four-track mainline: an up and down fast line and an up and down slow line. The fast trains need to stop at the up fast platform on the way out, and the down fast on the way back, and the local stopping trains need to stop on the up slow on the way out and the down slow on the way back. The only solution that I can see to this is to allow platforms to be grouped into pairs somehow, but this strikes me as both complicated to implement and fiddly to use. This is not an issue with an easy solution, I think - as yet unthought-of innovation is required.

Edit: I have noticed that yobbobandana's latest Git push has the following code:

Code Select Expand


if( file->get_version()>=102003 && file->get_experimental_version()>=8.1 ) {


This, I am afraid, is an error:  file->get_experimental_version() returns an integer, not a floating point number. The saved game versions are only incremented with increments to the major version number. Changes to the minor version number do not allow changes to the saved game file format.

[yobbobandana]

The platform issue probably needs considering in more depth.

I'm considering opening another thread if the changes I'm testing lead to something useful.

it's not enough simply to allow the user to say "any platform" for certain stations, because there are some stations where a user needs a train to go into one particular platform in one direction, and another in another. Take the example of a four-track mainline: an up and down fast line and an up and down slow line. The fast trains need to stop at the up fast platform on the way out, and the down fast on the way back, and the local stopping trains need to stop on the up slow on the way out and the down slow on the way back.

I'm not sure I follow. In this situation with different tracks, isn't it quite easy to set up one-way signals directing the trains into the appropriate stations? If the tracks frequently interconnect the player can also use waypoints to designate exactly which way the separate lines should go.

Initially I had intended for the alternate platform selection to only work for lines that were set to "auto-reverse", and manually selected lines would go to the exact platform as per normal. But as it was quite a simple solution it would be nice if it could be made more generally useful.

Re: the experimental version number:
Ahh, I must have done it once to test, and then copied myself later.

[jamespetts]

I'm not sure I follow. In this situation with different tracks, isn't it quite easy to set up one-way signals directing the trains into the appropriate stations? If the tracks frequently interconnect the player can also use waypoints to designate exactly which way the separate lines should go.

Aren't waypoints indistinguishable from station platforms for routing purposes?

Edit: On a very brief initial test (on -devel - push to come soon), I notice that the "circular schedule" label over-runs the schedule dialogue box a little. Perhaps that dialogue box needs to be made a little bigger?

Edit 2: On quitting with your patches applied, I get a crash in the following code:

Code Select Expand


schedule_t *fpl = cnv->get_schedule();


At line 937 of simvehikel.cc: "cnv" is null.

[sdog]

likely related crash:

http://forum.simutrans.com/index.php?topic=5282


ps: james, maybe merge it here, if you think it shouldn't be in the experimental forum.

[yobbobandana]

Aren't waypoints indistinguishable from station platforms for routing purposes?

Well, the distinction is that if a schedule-point is not part of a station then it is a waypoint .

I notice that the "circular schedule" label over-runs the schedule dialogue box a little. Perhaps that dialogue box needs to be made a little bigger?

I've changed the label to "also reverse" which fits and is a better descriptor. Is there a way to expand the button automatically to fit the text? I'm not sure every translation could fit within the 1-button-length size.

On quitting with your patches applied, I get a crash in the following code:

Code Select Expand


schedule_t *fpl = cnv->get_schedule();

At line 937 of simvehikel.cc: "cnv" is null.

I'm not getting this problem at all. I'll see if I can track it down.

[yobbobandana]

Okay, I think this is pretty much complete:

Final patch change summary:

* Line Management: Change "return ticket" button into a checkbox. Now in stead of adding extra stops to the line, it causes vehicles to automatically follow the route in reverse upon reaching the end.
* Line Management: Add an "also reverse" checkbox. When set, this causes every second vehicle added to the line to permanently follow it in the reverse direction.
* Vehicle Info: Add a "reverse route" checkbox to the info window for vehicles. This shows whether the vehicle is currently following its schedule in forward or reverse order. It may also be directly toggled by the player to change the direction.

[prissi]

Nearly For long block signals, the route must be also reversed (simvehikel.cc around line 2430).

[yobbobandana]

Nearly For long block signals, the route must be also reversed (simvehikel.cc around line 2430).

Huh, so it turns out I had no idea what long block signals were actually supposed to do! I can't believe I was playing without them...

This should fix it so that they are properly handled for reversed and mirrored tracks.

The v5 patch includes everything, the "change-since-v4" is just this change to support long block signals.

[prissi]

Aparently the loading first for next stop needs also work in this patch.

[sanna]

Aparently the loading first for next stop needs also work in this patch.

See this thread: http://forum.simutrans.com/index.php?topic=5332.0

[yobbobandana]

Yes, here is the updated patch with the correct loading behaviour.

[jamespetts]

Can I just check in relation to the Experimental version of this patch, as I have not had time to test it: does this work with Experimental's routing features properly?

[yobbobandana]

Can I just check in relation to the Experimental version of this patch, as I have not had time to test it: does this work with Experimental's routing features properly?

Short answer: no, I'll get working on it.

I'll probably refactor this patch a ltitle to generalise iterating over all stops in a schedule. It seems there are a few more places (in both standard and experimental) that assume iterating over the schedule and wrapping at the end will give all halts in order. Although this behaviour is mostly fine, correctly handling it for the cases where it's not fine will take a little thought.

(It'll also make my later modifications a ltitle neater.)

[yobbobandana]

Okay, here's an updated patch.

Changes:
* Moved my increment_fahrplan_index helper function to schedule_t::increment_index in fahrplan.cc
* Updated the loading code to use this to iterate over stops (correctly handles fwd/reverse/mirroring etc)
* Updated the code that updates a convoy's schedule to use increment_index to check consecutive stops
* Updated the code that calculates goods destinations (warenziele) to use increment_index to check distance
* Updated the map display to not draw a line between end-points for mirrored schedules.

With this, all places in the code that previously used fpl->eintrag[i%count] should theoretically work correctly for circular/mirrored schedules.

The only problem I'm having is constructing adequate test-cases for the routing behaviour. It seems to do what it should in all cases I've tried. But in particular I'm not sure how to test the code in haltestelle_t::rebuild_destinations() that adds stops to "warenziele" ordered by distance. I couldn't see how this affects routing, with or without my patch applied.

Well, theoretically it should do just what it did before I touched it, just generalised to reversable routes...