The International Simutrans Forum

 

Author Topic: [patch] Allow convoys to follow their schedule in reverse automatically  (Read 24686 times)

0 Members and 1 Guest are viewing this topic.

Offline yobbobandana

  • *
  • Posts: 42
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 :D. 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
« Last Edit: June 07, 2010, 12:09:08 PM by yobbobandana »

Offline VS

  • Senior Plumber (Devotee)
  • Devotees (Inactive)
  • *
  • Posts: 4856
  • Vladimír Slávik
    • VS's Simutrans site
  • Languages: CS,EN
Interesting idea :) I think we haven't seen that one yet...

Offline wlindley

  • Devotee
  • *
  • Posts: 1064
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
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?

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10642
  • Languages: De,EN,JP
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.

Offline skreyola

  • *
  • Posts: 337
  • Trivial Troubleshooter
: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:

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
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 :)

Offline skreyola

  • *
  • Posts: 337
  • Trivial Troubleshooter
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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
This is a good idea, and I agree with Prissi about predictability - it is better to be in control, I think.

Offline yobbobandana

  • *
  • Posts: 42
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?

Offline sdog

  • Devotee
  • *
  • Posts: 2052
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"

Offline yobbobandana

  • *
  • Posts: 42
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)
« Last Edit: June 04, 2010, 05:32:49 AM by yobbobandana »

Offline sdog

  • Devotee
  • *
  • Posts: 2052
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!

Quote
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)
« Last Edit: June 04, 2010, 08:36:52 AM by sdog »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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...).

Offline sdog

  • Devotee
  • *
  • Posts: 2052
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--<-

Offline skreyola

  • *
  • Posts: 337
  • Trivial Troubleshooter
@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.

Offline sdog

  • Devotee
  • *
  • Posts: 2052
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.)

Offline yobbobandana

  • *
  • Posts: 42
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 :)
« Last Edit: June 04, 2010, 06:33:09 PM by yobbobandana »

Offline sdog

  • Devotee
  • *
  • Posts: 2052
Quote
[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.

Offline skreyola

  • *
  • Posts: 337
  • Trivial Troubleshooter
@sdog: How about this, then?
Code: [Select]
---->-\     /---->-
       >===<
-<----/     \-<----
Symmetrical travel time, only one platform (until three are needed for volume)...

Offline sdog

  • Devotee
  • *
  • Posts: 2052
Quote
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.

Quote
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]
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.
« Last Edit: June 05, 2010, 05:28:45 AM by sdog »

Offline yobbobandana

  • *
  • Posts: 42
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... :).

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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]
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.
« Last Edit: June 05, 2010, 01:16:21 PM by jamespetts »

Offline yobbobandana

  • *
  • Posts: 42
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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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]
schedule_t *fpl = cnv->get_schedule();

At line 937 of simvehikel.cc: "cnv" is null.
« Last Edit: June 05, 2010, 10:11:30 PM by jamespetts »

Offline sdog

  • Devotee
  • *
  • Posts: 2052
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.

Offline yobbobandana

  • *
  • Posts: 42
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]
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.

Offline yobbobandana

  • *
  • Posts: 42
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.


Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10642
  • Languages: De,EN,JP
Nearly ;) For long block signals, the route must be also reversed (simvehikel.cc around line 2430).

Offline yobbobandana

  • *
  • Posts: 42
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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10642
  • Languages: De,EN,JP
Aparently the loading first for next stop needs also work in this patch.

Offline sanna

  • *
  • Posts: 234
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

Offline yobbobandana

  • *
  • Posts: 42
Yes, here is the updated patch with the correct loading behaviour.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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?

Offline yobbobandana

  • *
  • Posts: 42
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.)

Offline yobbobandana

  • *
  • Posts: 42
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...

knightly

  • Guest
Hi Yobbobandana

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.

rebuild_destinations() is triggered when something that affects routing is changed. For instance, it is triggered when you add/remove stop(s) to/from a schedule/line, or when you add a new stop or remove an existing stop on the map, etc.

BTW, I would suggest not to use "circular", as it is ambiguous. In fact, the original route implementation is already circular : A > B > C > D > A > B > C > D > ... , with the stops forming a closed loop. In your case, I would rather suggest to use "bidirectional" -- that makes it clear that the route is served by vehicles heading opposite directions.

Edit :

For rebuild_destinations(), you would expect that a line that serves A > B > C > D > E > F > G > H with F as the origin to have the following order of stops in the warenziele :
    Current implementation :  G H A B C D E
    Bidirectional but not mirrored : (E G) (D H) (C A) B
    Mirrorred (regardless of bidirectional) : (E G) (D H) C B A
Stops grouped in brackets mean that their order are interchangeable [i.e. (C A) means both A-C or C-A are acceptable]. Of course, this is only for ST Standard, which currently does not consider inter-stop distance or travelling time; for EXP, you need to check, for the bi-directional but not mirrorred case, which route, normal or reverse route, is faster to reach a stop.

Edit :

Forgot to mention : you may need to call welt->set_schedule_counter() when bidirectional or mirror flag is toggled, in order to trigger recalculation of warenziele and routes.

Hope this helps!

Knightly
« Last Edit: June 22, 2010, 09:27:22 AM by Knightly »

Offline yobbobandana

  • *
  • Posts: 42
Hi Knightly, thanks for your help :).

I've verified that stops are indeed added to warenziele in the correct order for bidirectional/mirrored schedules.

For bidirectional schedules it treats them as a single schedule that passes all stops in both directions. The current code handles this well already, and it looks like I can do the same thing easily for Experimental.

So for example A>B>C>D>E from stop D will check destinations E>A>B>C>reset_distance>C>B>A>E, replacing destinations B and C on the way back. If the route was mirrored it would check E>reset_distance>C>B>A>B>C.

You are quite right about the term "circular", I couldn't think of a good word to replace it with but bidirectional works well :).

I just double-checked and welt->set_schedule_counter() seems to be called automatically. Changing the bidirectional/mirrored flags on a schedule will treat it as a new schedule, which seemed the easiest thing to do.

Here is an updated patch:
 * Replaces "circular" with the more apt "bidirectional".


knightly

  • Guest
[Previous comments removed]

Edit :

I think some special handling is necessary with bidirectional (but not mirrorred) lines and reversing.

For instance, what if a bidirectional line has only one convoy? Then this line is actually unidirectional. Warenziele entries would then have to be in line with the direction (normal or reverse) of the single convoy. And if its direction is reversed later, warenziele needs to be updated.

And what if a bidirectional line has more than one convoy, but the player has manually switched the directions such that all of them are heading the same direction? In that case, the line has become unidirectional.

How about a non-bidirectional line having more than one convoy, and the player manually switches one of them to the reverse direction? It becomes a bidirectional line and warenziele needs to be rebuilt.

Unlike the mirror flag, setting the bidirectional flag of a line/schedule alone does not automatically make it bidirectional. Setting the bidirectional flag only indicates the wish to enforce bidirectionality; actual directionality depends on the directions of convoys associated with the line. Thus, some extra logic is needed to keep track of the actual directionality of a line, and increment schedule counter whenever the directionality changes.

On the other hand, it is also necessary to increment schedule counter when the player reverses the direction of a lineless convoy.

Edit :

Conceptually, bidirectionality (both the directive to enforce it by alternating initial direction of individual convoys, as well as the actual state of it) is a property of lines only. They should not appear in the schedule copies of individual convoys (and definitely not in the schedules of lineless convoys). Thus I would suggest to move the bidirectionality flag from schedules to lines.

Besides, I would also suggest to relocate the reverse flag from convoys to schedules, as each convoy has its own copy of the schedule. In that way, the following code :
Quote
void convoi_t::advance_schedule() {
   // check if the convoi should switch direction
   if( fpl->is_mirrored() ) {
      if( fpl->get_aktuell()==0  ) {
         reverse_schedule = false;
      }
      else if( fpl->get_aktuell()==fpl->get_count()-1 ) {
         reverse_schedule = true;
      }
   }
   // advance the schedule cursor
   if( reverse_schedule ) {
      fpl->advance_reverse();
   } else {
      fpl->advance();
   }
}
could be encapsulated inside schedules. Convoy code should not know how mirrorring is implemented, or decide whether to advance schedule index normally or in reverse.

Edit :

A minor suggestion : maybe it's more convenient to pass arguments by reference (instead of pointers) to schedule_t::increment_index(). In that way, you don't need to take the address of the variables, and later deference them again in the function body.
« Last Edit: June 24, 2010, 08:13:06 AM by Knightly »

Offline yobbobandana

  • *
  • Posts: 42
A minor suggestion : maybe it's more convenient to pass arguments by reference (instead of pointers) to schedule_t::increment_index(). In that way, you don't need to take the address of the variables, and later deference them again in the function body.

I preferred to pass by address just because it makes it more obvious that the variables will be changed, but I should've checked what the style was in other places :). I've updated this and as you say it's cleaner as such.

Besides, I would also suggest to relocate the reverse flag from convoys to schedules, as each convoy has its own copy of the schedule. In that way, the following code :could be encapsulated inside schedules. Convoy code should not know how mirrorring is implemented, or decide whether to advance schedule index normally or in reverse.

I've moved the logic out of simconvoi.cc (it just uses increment_index now), but I still currently have the reverse flag kept as part of the convoy... If I move it to part of the schedule then there is the question of if the direction is not the same, is it the same schedule? In particular, I would probably leave the direction out of sprintf_schedule and sscanf_schedule, but I'm not sure whether this would be desired in all cases.

Well, I'll see what it looks like after I'm done with the next part.

Conceptually, bidirectionality (both the directive to enforce it by alternating initial direction of individual convoys, as well as the actual state of it) is a property of lines only. They should not appear in the schedule copies of individual convoys (and definitely not in the schedules of lineless convoys). Thus I would suggest to move the bidirectionality flag from schedules to lines.

True, the bidirectional flag should be part of the line. In terms of the UI though, even for lineless convoys you can "promote" their schedule to a line, so I'd need to find some better place of editing this. So far methods of editing the line just give you the schedule to edit, so in terms of the UI lines and schedules are almost identical.

So I'm not too sure where it could be edited from.

Similarly for the direction flag, I couldn't see how to easily add it to the schedule editing UI without adding another row to the buttons at the top.

I could possibly add another row for the active direction, and hide the "bidirectional" button for individual convoys. Then the bidirectional flag could sensibly be added to the line, and the direction flag to the schedule. I do like setting the direction from the convoy info window though.

I think some special handling is necessary with bidirectional (but not mirrorred) lines and reversing.

For instance, what if a bidirectional line has only one convoy? Then this line is actually unidirectional. Warenziele entries would then have to be in line with the direction (normal or reverse) of the single convoy. And if its direction is reversed later, warenziele needs to be updated.

...

Unlike the mirror flag, setting the bidirectional flag of a line/schedule alone does not automatically make it bidirectional. Setting the bidirectional flag only indicates the wish to enforce bidirectionality; actual directionality depends on the directions of convoys associated with the line. Thus, some extra logic is needed to keep track of the actual directionality of a line, and increment schedule counter whenever the directionality changes.

On the other hand, it is also necessary to increment schedule counter when the player reverses the direction of a lineless convoy.
Ahh yeah you're right... thinking about it I'll probably need to keep track of the served directions on a per-goods-type basis too, to catch a situation like all the buses going one way and all the mail vans going the other.

Well this will be my challenge for this weekend :).

knightly

  • Guest
I preferred to pass by address just because it makes it more obvious that the variables will be changed, but I should've checked what the style was in other places :). I've updated this and as you say it's cleaner as such.

I see your point, and thanks for updating ;)


If I move it to part of the schedule then there is the question of if the direction is not the same, is it the same schedule?

According to your scheme, 2 schedules should be the same if they differ only by direction. Just as the current stop index (aktuell) is not checked in schedule_t::matches(), you don't need to check direction in that function.


In particular, I would probably leave the direction out of sprintf_schedule and sscanf_schedule, but I'm not sure whether this would be desired in all cases.

If I understand it correctly, sprintf_schedule() and sscanf_schedule() are for converting schedules to/from strings, a means of passing schedules when they are updated. It doesn't seem to be harmful at all to include direction as well. In sum, you may treat direction as a transient state much like aktuell. The advantage of putting the direction flag in schedule_t is that, you can encapsulate all processing and relevant data inside the same class, and you don't need to pass the direction flag every time.


True, the bidirectional flag should be part of the line. In terms of the UI though, even for lineless convoys you can "promote" their schedule to a line, so I'd need to find some better place of editing this. So far methods of editing the line just give you the schedule to edit, so in terms of the UI lines and schedules are almost identical.

Similarly for the direction flag, I couldn't see how to easily add it to the schedule editing UI without adding another row to the buttons at the top.

So I'm not too sure where it could be edited from.

I could possibly add another row for the active direction, and hide the "bidirectional" button for individual convoys. Then the bidirectional flag could sensibly be added to the line, and the direction flag to the schedule. I do like setting the direction from the convoy info window though.

IMHO it is not a good idea to forsake what would otherwise be the conceptually correct code structure just because of UI constraints. UI constraints can be overcome or circumvented. For instance, the bidirectional option can be placed in the header of the lower-right panel (where convoys are listed) inside the line management frame. Once the bidirectional option is removed from schedule gui, you have a free slot to put the direction option. Alternatively, you may still keep the direction option in the convoy info window for convenient checking and update -- you only need to change event handling code by calling the appropriate schedule_t functions.


Ahh yeah you're right... thinking about it I'll probably need to keep track of the served directions on a per-goods-type basis too, to catch a situation like all the buses going one way and all the mail vans going the other.

Good point about the good categories :) So, the bi-directional problem is really more complicated then it seems in the first place ...


Well this will be my challenge for this weekend :).

Good luck ;)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
If I understand it correctly, sprintf_schedule() and sscanf_schedule() are for converting schedules to/from strings, a means of passing schedules when they are updated. It doesn't seem to be harmful at all to include direction as well. In sum, you may treat direction as a transient state much like aktuell. The advantage of putting the direction flag in schedule_t is that, you can encapsulate all processing and relevant data inside the same class, and you don't need to pass the direction flag every time.

These two methods are used for passing data accross a network/the internet for multi-player games (a feature that is currently work-in-progress in Standard). For the schedule feature to work with multiplayer games, any extra data must be transmitted through these methods.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10642
  • Languages: De,EN,JP
Since discussion is still going on, I will not commit it this week.

But in principle, a reverse flag should be a schedule option. For a line, it should indicate bidirectional operation. Thus the flag could be only interpreted differently for lines. Programmwise one could thing of an union (for those booleans). The prinf_schedule would just handle an additional boolean and only the context would give its meaning (make every second convoi with schedule revers flag set) or actually drive schedule reverse.

Offline yobbobandana

  • *
  • Posts: 42
I finished updating this yesterday, but as I ended up redoing almost the entire patch, it still needs testing and sanity-checking on my end.

I'll go over the changes I've made, so if anyone sees an obvious problem, or better way of doing it, let me know.

Tracking which goods are serving which directions for a line:

Currently goods served by a line are tracked via the uint8 vector "goods_catg_index".

I added two more of these to line_t: "fwd_goods_catg_index" and "rev_goods_catg_index" to track the goods served in each direction on the line.

The obvious alternative was adding a single vector representing the directions served for each entry in goods_catg_index, but it would have been more clunky to implement.

The worst effect of this is probably slowing down "line_t::recalc_catg_index()" as non-mirrored lines with both directions served will need to check all three of the vectors for changes.

With them, it's pretty easy to check whether any specific goods type is served in a specific direction by the line, and also whether a direction is served at all (just check if the appropriate vector is empty). I added functions for this and haltestelle_t::rebuild_destinations() now uses them.

Variable changes

bool convoi_t::reverse_schedule -> schedule_t::advance_reverse (direction flag)
bool schedule_t::bidirectional -> line_t::also_reverse (convoys added to line in both directions)
bool line_t::start_reversed -> removed in favour of using the line's schedule's advance_reverse flag

UI changes

Moved the "also reverse" button from fahrplan_gui_t to line_management_gui_t (so it doesn't show for individual convoys).

It's still in the same place, but I'll probably move it so that the advance_reverse flag can be edited from the schedule gui.

convoy_info_t still has the button to switch the convoy's direction. It updates the warenziele properly now when toggled.

Other

There were a raft of small changes too, mainly to support the variable reshuffling.

I'll post the updated patch once I've made sure it works as intended.


Offline yobbobandana

  • *
  • Posts: 42
Here's the updated patch.

I added another row to line_management_gui_t and put the "also reverse" button there. This allowed a button for the schedule's advance_reverse flag to be added to fahrplan_gui_t.

In the extra space I added a text box so that the line's name can be viewed and edited (useful for setting the name of a new line).

However I have a strange problem that the textinput element only accepts modifications if the depot window isn't open. I couldn't see any reason for this.

I changed line_management_gui_t::infowin_event to return the swallowed flag from fahrplan_gui_t::infowin_event so that key events were swallowed properly, but I might have done this incorrectly as I'm not too sure how the focus and event swallowing works. When the depot window isn't open, it works fine...

What do I need to do to make sure the textinput for the line's name correctly swallows keyboard events and edits the name?

Apart from this issue, everything I tested seemed to work.

Here's a screenshot of the updated line_management_gui and the patch.

PS: it's quite confusing that there are two different windows titled "Line Management".

knightly

  • Guest
Hi Yobbobandana

May I know, why do you change from "bidrectional" to "also reverse"? IMHO the meaning is not clear with "also reverse".

As to updating warenziele and routing, since now network mode is in place, any change that needs to be passed to connected players should go via the network interface with a tool. For instance, you have a button in the convoy info window to toggle the direction of the schedule, and the associated code does eventually initiate world update. However, other players will not be aware of the change as they are not notified of the change. For "also reverse", it is not part of schedule_t, so you need to include it as part of the change line tool parameter. For details, you may take a look at the WIN_CLOSE case in fahrplan_gui_t::infowin_event(), line_management_gui_t::infowin_event(), as well as convoi_t::call_convoi_tool(), wkz_change_convoi_t::init() and wkz_change_line_t::init()]

Hope this helps

Knightly

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Yobobbandana,

is this now fully compatible with Experimental? This should be a very useful additional feature when complete (if not complete already)...

Offline Zeno

  • ENASSA Designer
  • Devotees (Inactive)
  • *
  • Posts: 1997
    • Zeno's Simutrans Creations
  • Languages: ES, EN, CAT
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #46 on: August 21, 2010, 10:35:44 AM »
May I ask what happened with this patch? I wonder if it's just stopped due to holidays or if it's been abandoned...

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10642
  • Languages: De,EN,JP
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #47 on: February 02, 2012, 08:56:21 PM »
It is part of experiemental. I tested this behaviour, and it had quite some unexpected behavoir, especially with trains. Thus I decided to not incorporate this in standard.

Offline sdog

  • Devotee
  • *
  • Posts: 2052
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #48 on: February 02, 2012, 09:11:40 PM »
It is part of experiemental. I tested this behaviour, and it had quite some unexpected behavoir, especially with trains. Thus I decided to not incorporate this in standard.

I think there is a point to this. Still this is the feature of experimental i miss the most when playing standard.


update the selection of correct platforms was moved from this patch into it's own development. (both are implemented in experimetnal though) discussion can be found here: [size=78%]http://forum.simutrans.com/index.php?topic=5285.msg51703#msg51703[/size]


The unexpected behaviour mostly comes from the exception in the code where a train does not call at the first suitable platform but continues to the platform specifically in the list when the latter is near enough. I should like to suggest to get rid of that exception alltogether.

Just let trains always call at the first suitable platform when reverse route or circular route flags are set, and the stop has no "wait 'till loaded" property.

The other source of unreliable behaviour is more difficult to fix, completely seperated circular lines do not work, if there is no connection between both ways, as a train has to way-find the route to the platform in the schedule. It will be much less of a nuisance when the previous thing is done. Since in that case players can connect bi-directional tracks directly after and before stations without disabling the patch.


ps.: this mostly is directed at experimental, but perhaps if it works better reliably it might be re-evaluated for standard?
« Last Edit: February 02, 2012, 09:34:02 PM by sdog »

Offline omikron

  • *
  • Posts: 110
  • Languages: EN, DE, NO, FR, EE
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #49 on: February 02, 2012, 09:15:47 PM »
The trains in experimental actually do stop at the first platform of the destination they pass through and ignore the scheduled stop.

See here: http://forum.simutrans.com/index.php?topic=9087.0

omikron

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10642
  • Languages: De,EN,JP
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #50 on: February 02, 2012, 09:49:59 PM »
Standard had a defined behaviour in mind. Without choose signals any train (or car) will go exactly where ordered. This patch breaks this and can easily generate unsolvable deadlocks. I even posted about this several month ago in the experimental forum section.

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #51 on: February 02, 2012, 11:40:12 PM »
If there is ever going to be an automatic return path for trains, it'll have to be enforced in schedule, not during running.

I wonder, when I select the button for the return trip, couldn't the trip be simulated, ADDING TO SCHEDULE the first platform met?  It wouldn't be worse than now, and after schedule dialog is closed, the path will still be 100% deterministic...

Actually, pushing this idea a bit further, every new stop could be tested and an error risen if the previous stop and the new one are not connected...

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #52 on: February 03, 2012, 12:07:28 AM »
I wonder, when I select the button for the return trip, couldn't the trip be simulated, ADDING TO SCHEDULE the first platform met?  It wouldn't be worse than now, and after schedule dialog is closed, the path will still be 100% deterministic...

Won't this cause the exact same problems whenever the schedule is modified that this patch was designed to obviate in the first place?

Offline sdog

  • Devotee
  • *
  • Posts: 2052
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #53 on: February 03, 2012, 05:39:45 AM »
@fabio
but then it would be the same inconvenient situation as now, where stops appear twice in a schedule. making changes in the schedule very difficult and the schedule list confusing.

much more "Tracking which goods are serving which directions for a line" would not work: http://forum.simutrans.com/index.php?topic=5262.msg52721#msg52721

Ring lines would still be impossible, as they are in standard now.

@prissi
"Standard had a defined behaviour in mind. Without choose signals any train (or car) will go exactly where ordered. This patch breaks this and can easily generate unsolvable deadlocks."

Together with the "call at first suitable platform that is passed" patch the train will still go the same route it would without those patches.  The only difference is, that it does not go all the way. The behavious is still well defined and deterministic. Wouldn't deadlocks become less likely, when trains allready halt when encountering a suitable platform instead of turning through stations to get to the designated platform?

Offline Zeno

  • ENASSA Designer
  • Devotees (Inactive)
  • *
  • Posts: 1997
    • Zeno's Simutrans Creations
  • Languages: ES, EN, CAT
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #54 on: February 03, 2012, 08:50:30 AM »
Mmmm... what about adding two tabs, one for the first run and other for the return path? This would avoid the confusion of having everything twice in the list and also the need of calculating the back path "on demand".

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #55 on: February 03, 2012, 10:51:56 AM »
Mmmm... what about adding two tabs, one for the first run and other for the return path? This would avoid the confusion of having everything twice in the list and also the need of calculating the back path "on demand".

I suspect that this would be very confusing for new players.

Offline Zeno

  • ENASSA Designer
  • Devotees (Inactive)
  • *
  • Posts: 1997
    • Zeno's Simutrans Creations
  • Languages: ES, EN, CAT
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #56 on: February 03, 2012, 11:06:30 AM »
You're probably right. That second tab should be available only when clicked the "reverse" option, so the return path would be created in the second tab. I suspect that it would be hard to keep control there, as long as the route would be splitted somehow to allow editing in two different paths...

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #57 on: February 03, 2012, 11:09:43 AM »
Duplicated backwards stops (possibly using the pathfinding algorithm) could be flagged and appear e.g. in blue in schedule list.
Pressing Duplicate/mirror button, the last one in schedule will be flagged as end_of_line; start_of_line and end_of_line could appear in red. As it is now, start_of_line and end_of_line are not duplicated (for good reason)

Blue duplicated stops could then be customized as desired by the player (giving the same freedom as now, just default would be a more useful one). Maybe a Move stop button (move -> select in list stop to be moved -> click on the map where to relocate it) would be convenient as well.

Add stop button would add the stop BETWEEN end_of_line and first of duplicated, assuming the flag of end_of_line and duplicating the one which was previously end_of_line (becoming blue).

Insert stop button would work instead as it does now, and so would remove stop. This could allow for (partly) split paths.

Colours would give players a decent hint of what is first run and what is return trip and, most importantly, all this implementations would not affect ANYTHING outside schedule dialog.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #58 on: February 03, 2012, 11:18:34 AM »
But then, what happens when a player has edited the reverse portion of the route, then wishes to add a stop to the middle of the outward portion? How exactly will the programme handle that?

Offline Zeno

  • ENASSA Designer
  • Devotees (Inactive)
  • *
  • Posts: 1997
    • Zeno's Simutrans Creations
  • Languages: ES, EN, CAT
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #59 on: February 03, 2012, 11:28:07 AM »
Well, when adding a new stop A after B and before C then the program should add a stop on the reverse after C, if C is found. We should expect it to be automatic, not to be intelligent :D

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20776
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #60 on: February 03, 2012, 12:06:19 PM »
Suppose that we have a schedule like this:

A>B>C>B>A>B>D

and it is reversed. Suppose that we add a stop between B and C. How will the program deal with this if this suggestion is implemented?

Suppose further that the reverse portion only has been edited thus:

D>B>X>B>A>B>C>B>A

How would that be accomodated in the forward part of the shcedule if it, in turn, were amended thus:

A>B>C>B>A>B>Y>D

?

How, in other words, would the programme know (1) whether to add "Y" to the reverse; and (2) whether Y should go before or after X if it is added?

Offline wlindley

  • Devotee
  • *
  • Posts: 1064
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #61 on: February 03, 2012, 12:28:38 PM »
How is it "not deterministic" to have, just like in Experimental, a flag that says whether to reverse the list, and a flag that simply says whether the next stop is "up" instead of "down" the list?  Why are we debating all this complexity, when Experimental's implementation is so simple and functional?

Offline omikron

  • *
  • Posts: 110
  • Languages: EN, DE, NO, FR, EE
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #62 on: February 03, 2012, 12:51:36 PM »
Apparently because prissi thinks it is not easily communicable to novice players, and I would agree with him. However, reversing as it works currently is not necessarily that much easier to undersyand and definitely more annoying since you have to change everything manually..

It is, however, possible to use both sets, as in exp currently. One may manually schedule the return trip, or one could use the 'mirror' function, if one understands how it works.

omikron

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10642
  • Languages: De,EN,JP
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #63 on: February 03, 2012, 02:27:33 PM »
Instead of the return tircket option in the schedule one could add a return trip. THen one can promote this to a linge again and it will hail those stops.

But concerning automatic choosing: This will run into problems as soon as your stations are on sidetracks and the main track is a through track. With such a layout trains will go always to their station assigned, i.e. run always nearly a full circle on a circle line or go various turn on a two-way line. Exactly like those runaways trains in OpenTTD searching for depots at strange positions.

Offline wlindley

  • Devotee
  • *
  • Posts: 1064
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #64 on: February 03, 2012, 04:09:34 PM »
Ah.  How about having only one check-box "Add Reverse Trip" which would show, in a different color, the reverse stations after the final station.  The "next stop" indicator could be set to any of those automatically-computed stations, but they would not be editable.  Editing the actual stations would adjust the reversed stations.

Offline omikron

  • *
  • Posts: 110
  • Languages: EN, DE, NO, FR, EE
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #65 on: February 03, 2012, 04:12:53 PM »
That's a good idea, wlindley, but it doesn't solve the problem with different platforms. We would have to add the exp-behaviour in that case, and it woudl all be back to the old debate.

omikron

Offline wlindley

  • Devotee
  • *
  • Posts: 1064
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #66 on: February 03, 2012, 04:33:16 PM »
=Sigh=   Can't we have it all, -- and room for a pony?

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #67 on: February 03, 2012, 04:42:34 PM »
If we use routing for finding next return stop (to be added to the schedule list), couldn't we do like this?

Find Platform:
   - try default platform
   - if default platform is one way (wrong direction), try another platform
   - if next next stop is met in the path, try another platform
and so on

Offline sdog

  • Devotee
  • *
  • Posts: 2052
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #68 on: February 03, 2012, 05:48:49 PM »
The automatic platform choosing is not absolutely nevessary for this. It can be easily worked around. (See posts on first page)

A slight change to platform chose signals would also be a possibility.

Please dont forget, that the current replicate backward causes the same chaos on bi-directional train lines.
Regardless of those platform difficulties, isn't it by far the clearest UI sollution to run the schedule in reverse, instead of adding duplicated stops automatically?


Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10642
  • Languages: De,EN,JP
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #69 on: February 03, 2012, 07:34:06 PM »
I tried to remove the replicate backwards button countless times. But player voted for it.

Offline sdog

  • Devotee
  • *
  • Posts: 2052
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #70 on: February 03, 2012, 10:52:58 PM »
as it is now, it is a tripwire for moderately new players, starting first complex rail lines. Absolute newbs get confused by filling up their schedule with lots of copies of the schedule, by pressing the mirror button several times.

This is perhaps mostly a request from former openTTC players (the UI there is a hopeless case though, players who learned to get used to that are probably spoiled for the rest of their gaming lives :-P).

After reading your comments, i think you're quite right there (even while i don't like it) simutrans has the concept of fixed schedule-platform assignment. Any rule deviating from this in a non transparent way, endangers useability. (one can see this from howto or workaround pages for one special case spawning). The way that was chosen was also very indirect and prone to errors. (calculate a very long route to the opposite platform, for any stop, break a rail section somewhere on the outgoing route and all returning trains get broken too, without a sign where it comes from -- got frustad more than once in experimental by this)

If the patch would be used as it is now, without tinkering with platforms, it still would have the pitfall the mirror schedule has now: on a bi-directional train route, the trains would circle the whole line. But: this can be fixed by the players after one trial, they know platforms are fixed, and the wrong behaviour is very clear. From this point on, they need either an alternative approach (quite a lot possible) or assign stops for retoure routes by hand.

An advantage is, the latter would be clearly distinctive from a return route, very much unlike it is now.

For bus routes, there is no danger at all (only advanced players could make routes where it was an issue).

ps.: prissi, thanks for taking your time to discuss this (let me know if i became to persistent)

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10642
  • Languages: De,EN,JP
Re: [patch] Allow convoys to follow their schedule in reverse automatically
« Reply #71 on: February 04, 2012, 08:40:00 PM »
You are welcome. I just wanted to clean up this section, when I revived this topic, and add an explaination.