Rail choose signal issue

Topic: Rail choose signal issue (Read 18807 times) previous topic - next topic

Rail choose signal issue

August 12, 2009, 08:53:32 pm

While those signals are really useful, they are bugged in annoying way:

If train which doesn't need to stop in the station the signal is "****igned" to, game will bug in irritating way: It will try to find clear route to next destination, which is disastrous if you have complex rail system

1. Path finding is slow. It seem to be simple BFS algorithm. It will be launched again and again in each iteration, horribly lagging everything. Source of this lag is obviously unknown - you need to pause, and check entire system to see where train got stuck.
2. Even if it manages to find route, it will, for unknown reason, fully block it - one can get huge rail block over entire network, even in places where broken train should never be (as they are way too far away from optimal track).
3. It isn't possible to fully avoid accidentally p****ing train through such station - game will always try to find shortest path and you won't know it, until you will watch as your train does full loop. Even if you do, your new extension might make older trains p**** by and get broken.
4. One could say that you can simply add this station to train route. That's actually not a solution - p****ing by station might start acting like transfer station and you will most likely lose money.

I took a look into a code, and it seems like game runs line at simvehikel.cc 2535:

Code: [Select]

				if(!target_rt.find_route( welt, rt->position_bei(next_block), this, speed_to_kmh(cnv->get_min_top_speed()), richtung, /*welt->get_groesse_x()+welt->get_groesse_y()*/50 )) {

. There is "50" parameter, but its useless - it will kill pathfinder if there are more then 50 forks rather then if path is longer then 50 fields. Even this working won't solve the issue - trains will get stuck forever instead of doing long block.

Is there any common solution or some code must be altered to make this work logically?

On screenshot: train on station (one most to the right, entering it) goes between "pollingfield branch station" and "polingcross branch station", and it's optimal route goes by bridge loop. It is however blocked by train right now. So, it goes by huge loop over entire map (4000> fields long)

http://www.ii.uj.edu.pl/~szklarze/simscr33.png
http://www.ii.uj.edu.pl/~szklarze/simscr34.png

Re: Rail choose signal issue

Reply #1 – August 13, 2009, 07:10:20 am

there is an "end of choose signal" as well, just place it immediately after the skipped station (or at least it should work like this).

Re: Rail choose signal issue

Reply #2 – August 13, 2009, 07:20:20 am

This "50" would intend, that the train won't find a route with one tile further than 50 tiles away from the starting tile. At least for me, this "50" works. But the route on your image is longer than 50 tiles, isn't it?

Re: Rail choose signal issue

Reply #3 – August 13, 2009, 07:34:17 am

well, this might be considered a solution - game won't lag anymore, but train will still get stuck at such station. It will report that it has stuck though.

I think that more complex solution could be made - something that will allow trains to p**** such signal in normal way even if it's not their station. Perhaps new choose signal could be made - one with gui to attach it to certain platforms rather then p****ing train schedule. Then it could simply direct all p****ing trains to one of it's platforms.

About seek range: It seem that revision head was fixed in this matter: we have this
route.cc 224

Code: [Select]

&& koord_distance(start.get_2d(),gr->get_pos().get_2d()+koord::nsow[r])<max_depth	// not too far away

while this seem to be broken in current stable, even this code solves nothing: it will check all routes in 100x100 square, rather then routes 50 tiles long. I suppose this is correct way to do such check:

Code: [Select]

Index: route.cc
===================================================================
--- route.cc	(revision 2611)
+++ route.cc	(working copy)
@@ -221,7 +221,7 @@
 			// a way goes here, and it is not marked (i.e. in the closed list)
 			grund_t* to;
 			if(  (ribi & ribi_t::nsow[r] & start_dir)!=0  // allowed dir (we can restrict the first step by start_dir)
-				&& koord_distance(start.get_2d(),gr->get_pos().get_2d()+koord::nsow[r])<max_depth	// not too far away
+				//&& koord_distance(start.get_2d(),gr->get_pos().get_2d()+koord::nsow[r])<max_depth	// not too far away, useless
 				&& gr->get_neighbour(to, wegtyp, koord::nsow[r])  // is connected
 				&& fahr->ist_befahrbar(to)	// can be driven on
 			) {
@@ -250,16 +250,18 @@
 					continue;
 				}
 
-				// not in there or taken out => add new
-				ANode* k = &nodes[step++];
+				if(tmp->count < max_depth) { // insert only if we are close enought
+					// not in there or taken out => add new
+					ANode* k = &nodes[step++];
 
-				k->parent = tmp;
-				k->gr = to;
-				k->count = tmp->count+1;
+					k->parent = tmp;
+					k->gr = to;
+					k->count = tmp->count+1;
 
-//DBG_DEBUG("insert to open","%i,%i,%i",to->get_pos().x,to->get_pos().y,to->get_pos().z);
-				// insert here
-				open.append(k);
+					//DBG_DEBUG("insert to open","%i,%i,%i",to->get_pos().x,to->get_pos().y,to->get_pos().z);
+					// insert here
+					open.append(k);
+				}
 			}
 		}

Re: Rail choose signal issue

Reply #4 – August 13, 2009, 08:28:54 am

This would perform better (only one check instead of four per loop):

Code: [Select]

Index: dataobj/route.cc
===================================================================
--- dataobj/route.cc    (revision 2589)
+++ dataobj/route.cc    (working copy)
@@ -210,7 +211,7 @@
 
 //DBG_DEBUG("add to close","(%i,%i,%i) f=%i",gr->get_pos().x,gr->get_pos().y,gr->get_pos().z,tmp->f);
                // already there
-               if(fahr->ist_ziel(gr,tmp->parent==NULL?NULL:tmp->parent->gr)) {
+               if(fahr->ist_ziel(gr,tmp->parent==NULL?NULL:tmp->parent->gr) || tmp->count > max_depth ) {
                        // we added a target to the closed list: check for length
                        break;
                }
@@ -221,7 +222,7 @@
                        // a way goes here, and it is not marked (i.e. in the closed list)
                        grund_t* to;
                        if(  (ribi & ribi_t::nsow[r] & start_dir)!=0  // allowed dir (we can restrict the first step by start_dir)
-                               && koord_distance(start.get_2d(),gr->get_pos().get_2d()+koord::nsow[r])<max_depth       // not too far away
+                               // && koord_distance(start.get_2d(),gr->get_pos().get_2d()+koord::nsow[r])<max_depth    // not too far away
                                && gr->get_neighbour(to, wegtyp, koord::nsow[r])  // is connected
                                && fahr->ist_befahrbar(to)      // can be driven on
                        ) {

Re: Rail choose signal issue

Reply #5 – August 13, 2009, 08:45:21 am

I would also suggest to place some wait period (ie check once for 50 steps or something). It's too expensive to check it in every step.

Still, we need some way to avoid trains getting stuck. Apart from doing choose signal in different way, we could possibly make schedule visualization - to see true patch between two stops train will (most likely) use - this way we could know if some additional waypoints must be placed. Also, i thing that trains could issue warning message if they fail to find route even in first attempt - it will mean that we need to enlarge station anyway.

Re: Rail choose signal issue

Reply #6 – August 13, 2009, 02:29:00 pm

The signal state is not checked every step. First it is checked every 500ms, then every 2000ms, then every 5000ms, if memory servers me right. Furthermore, after a choose signal the patch must be reserved or all kind of deadlocks would occur. Trust me on this, the choose signal is a longstanding discussion, which cannot really be solve. A finite range could solve some of the issues, but you want essential a choose signal that does the read my mind trick. How on earth does the train at the choose signal knows, that you do not want to choose there? This is only your feeling, but other persons built other networks. And you get a message if the train has to wait too long; or enable the train toolstips.

Re: Rail choose signal issue

Reply #7 – August 13, 2009, 02:45:27 pm

I was thinking on two paired signals: choose signal (new one), and multiple "choose exit signals" manually connected to first one. If train stops before choose sig, it could just use clear way to whatever exit signals. It might check whenever this signal leads to correct way, but i don't think its really necessary - it could be left to player's design skill. This way one could use such signal not only to choose station platform but also for example divide traffic from one rail to multiple parallel ones - by setting choose signal at entry and exit signals somewhere in each line.

What do you think about this?

Re: Rail choose signal issue

Reply #8 – August 13, 2009, 02:59:45 pm

i always supported choose signal also for non-stopping trains, but it had been denied much earlier. obviously i wouldn't mind a reconsidering

Re: Rail choose signal issue

Reply #9 – August 13, 2009, 03:10:07 pm

Perhaps the algorithm:

Train encounters Choose Signal; attempts to choose path to its next scheduled station; however if it encounters and End Of Choose Signal before finding that station, it will treat the Choose Signal as if it were a normal signal...

Can it be that simple?

Re: Rail choose signal issue

Reply #10 – August 13, 2009, 03:10:56 pm

not really - it will then crash into train waiting on station choose signal was ****igned to.

Re: Rail choose signal issue

Reply #11 – August 13, 2009, 03:50:18 pm

The choose signal behaves like a normal signal if the train has a waypoint on the square before the next signal (as it doesn't have an choose functionality for waypoints). I have used this a couple of times but I generally then find that when I change a schedule, the system messes up and so I now generally only use choosesignals for stations at ends of routes.

Re: Rail choose signal issue

Reply #12 – August 13, 2009, 03:55:29 pm

Here come my two cents:

A train at a choose signal does first a BFS (radius maybe 50 tiles). If there is the station (at least one platform of this station found), he wants to go, he wait until a platform is free. Otherwise, he will look if there is an end-of-choose-signal on his 'old' route (which was computed at his last stop). If there is one, he will wait until any way to it is free (and he reserve it). If there isn't one, he will vanish

I would also like it, if a train could choose the end-of-choose-signal (first with free way - and no detour).

Re: Rail choose signal issue

Reply #13 – August 14, 2009, 08:00:14 am

Excuse me if am write something well known, but the problem how to overcome the station with a choosesignal without stopping at it weighs upon me very much.
I cannot accept a solution using a waypoint - this is the same as a ordinary stop.
The solution may be a choose signal as a pair of begin and end signals regardless if there is a stop or station between begin-signal and end-signal.

Re: Rail choose signal issue

Reply #14 – August 14, 2009, 09:35:20 am

The end-of-choose-signal is also a little bit buggy in the current implementation:

Have a look at the appended image.
Train A has a waypoint at platform 2, but not in station 1. If train B blocks platform 2, train A doesn't find a way since there is an end-choose signal behind station 1.
But if train B doesn't block the way to platform 2, train A will find his way (and reserve it) also through the end-choose signal.

I think I will try to implement my suggestion above.

Re: Rail choose signal issue

Reply #15 – October 23, 2009, 08:22:06 am

Quote from: gerw – on August 13, 2009, 03:55:29 pm

Here come my two cents:

A train at a choose signal does first a BFS (radius maybe 50 tiles). If there is the station (at least one platform of this station found), he wants to go, he wait until a platform is free. Otherwise, he will look if there is an end-of-choose-signal on his 'old' route (which was computed at his last stop). If there is one, he will wait until any way to it is free (and he reserve it)

Quote

If there isn't one, he will vanish

Um, can you find an alternative to the vanishing? :-o How about doing a complete route recomputation? The scenario I'm thinking of is one where I'm doing construction and alterations while trains are running. It should be impossible for a train to be directed through a choose signal with no end-of-choose-signal in a sensible layout, but there might be such a situation *during construction*. However, that's the exact case where you should do a route recomputation anyway....

Quote

I would also like it, if a train could choose the end-of-choose-signal (first with free way - and no detour).

Your proposal is an AWESOME idea and would solve ALL of my choose-signal-related problems.

(1) It would allow for trains which are not stopping at a station, with the station surrounded by choose signals, to drive through any platform or take a "byp**** track. This is the main annoyance which means I can only use choose signals for terminal stations except in rare circumstances.
(2) It would allow for trains to overtake the "wrong way" on double track. (The layout requires at least three blocks and probably four so it only works for long lines, but still!)

So, again, great idea. You can think of them as "Control Zone of Local Signal Tower" if you want to think in real railroad terms. :-) The local tower can either get the train to its destination, or hand it off to someone else, and either way its job is done. :-)

Quote from: gerw – on August 14, 2009, 09:35:20 am

The end-of-choose-signal is also a little bit buggy in the current implementation:

Have a look at the appended image.

Not actually sure that's a bug. If the "original route" -- to platform 2 -- is working just fine, I think the choose signal never really activates, which is OK. Try the same image with platform 2 clear, but with a train sitting in the platform in station 1 -- specifically the platform on the "direct" line, which is probably the route which train A picked at its last station. That should cause A to fail to find a route to platform 2. (You can also design a more complicated layout with the same effect which is easier to test on.) If not, then you *have* found a bug, and an important one, because if you don't fix it, your proposed changes won't work right. :-(

Re: Rail choose signal issue

Reply #16 – November 18, 2009, 02:03:08 pm

Ok, so now I have a problem and most likely it has to do with my misudenrstanding of platform choose signals. Pakfile is pak128.

I have a simple system of one-way tracks, but stations have to be more flexible. So let me give you some scheme:

.----x--<s-\/<p>[][][][][][]<p>\/<p-<c-x-- (don't mind the dot)
--x-c>-p>-/\<p>[][][][][][]<p>/\-s>--x----

x - end of platform choose, c - platform choose signal, p - presignal, s - normal signal, \/ and /\ for connections between tracks, [][ - station itself, <> for ways allowed by signals. Between the stations I use the simple one-way signals for 250 each (black ones) instead of normal and this may be the issue.

Problem is when one train (let's say it's local) leaves and is between stations, the second one (express skipping that station) going in the same direction will stop on the platform choose and won't go until the previous is on the next station. More specific - the express can p**** the platform choose when the local p**** platform choose on the next station. I use end-of-choose signs on all tracks connected to the station. What's wrong?

Re: Rail choose signal issue

Reply #17 – November 18, 2009, 02:52:19 pm

Ok, first of all - why all these presignals? There are very few situation in current simutrans where these are actually still needed (used to be much more in the past, with the old signalling system - but we're talking about v88.x here) - I don't see any reason to use them in this setup. You might as well remove them all.

Second: the normal signals are not needed at this position either. The first signal (if you want to break up the distance between this and the next station into different "blocks" at all) should be at least so far behind the junctions that a train can stop at the signal and not block the the junction in doing so. Otherwise they do more harm than good.

Third: end of choose signs don't work the way you think. You might as well remove them all, as they don't do anything useful in this setup, too. Their only purpose is to except certain (e.g short) platforms (when you have several) of a single station from the choosing process (unless the waypoint for the stop is located on that plaform explicitly) - they don't do anything good for through trains.
Actually, non-stopping trains and choose signals are not a good combination. You should avoid doing that as trains will always stop there until they can reserve the whole way to their next waypoint. And an end-of-choose only means it just tries to reserve the direct route (completely!) instead of trying alternatives as well. So the only thing you can try is: set a waypoint for the nonstop trains right behind the p****-through station.

So, try this (much simpler) setting and see if it does what you want to achieve:

o - one way sign (not signal)
c - choose signal
w - waypoint for non-stopping trains

-<o-\/-w-[][][][][][][][]---\/-<c-
-c>-/\---[][][][][][][][]-w-/\-o>-

and as an example for a correct end-of-choose (x) usage:

-<o-\/-w-[][][][][][][][]---\/-<c-
-c>-/\---[][][][][][][][]-w-/\-o>-
.........\-x-[][][]

You see the third platform is shorter than the others, so you would want to avoid the long trains entering it from the choose signal even when the other two are blocked. That's what the x's are for.

Re: Rail choose signal issue

Reply #18 – November 18, 2009, 11:11:36 pm

So stations cut tracks into blocks just like signals? Because I don't see any signals to make each platform safe.

Where I may find some manual describing actual solutions used in Simutrans?

Re: Rail choose signal issue

Reply #19 – November 19, 2009, 10:06:08 am

Yes, stations have (invisible) built-in signals.

I don't know if there's a good manual with good, actual & extensive examples for signalling around.

I was thinking on creating a bunch of mini-size savegames for that purpose one day...

Re: Rail choose signal issue

Reply #20 – November 19, 2009, 11:41:18 am

Go ahead! They would be really helpful, ****uming that some ideas won't change much in years.
Anyway, your layouts work really fine AND it's much cheaper this way, thanks. :]

Re: Rail choose signal issue

Reply #21 – November 19, 2009, 02:41:08 pm

Yes, I will eventually do it, but I'd like it to be part of a wiki-article on signalling...

Re: Rail choose signal issue

Reply #22 – November 19, 2009, 05:13:00 pm

Quote from: DirrrtyDirk – on November 19, 2009, 10:06:08 am

Yes, stations have (invisible) built-in signals.

I don't know if there's a good manual with good, actual & extensive examples for signalling around.

I was thinking on creating a bunch of mini-size savegames for that purpose one day...

Are the invisible signals normal or 2-block? In situations with a choose platform, it would be a problem if they were one block, because a train might come out into the switching area while its destination track is still occupied, preventing other trains from reaching the platforms.

Re: Rail choose signal issue

Reply #23 – November 19, 2009, 05:20:10 pm

They are one block, standard signals, and if everything is set up correctly, there should be no problems.

In fact, I do not really understand the scenario you suggest...

Re: Rail choose signal issue

Reply #24 – November 19, 2009, 05:48:32 pm

I am not sure at all, but can't you override them by building a regular signal on end of platform?

Re: Rail choose signal issue

Reply #25 – November 19, 2009, 05:56:33 pm

You can place other signals there manually, yes - and AFAIK they work as intended as well.

Re: Rail choose signal issue

Reply #26 – November 19, 2009, 06:43:41 pm

Yup, they work. I usually place presignals there, so leaving trains won't block the switching area. On the other hand train may go through a red signal if it won't collide with another train "physically", or at least that's what I have seen somewhere and observed in the game. So simple stations like shown above won't be hit by such a problem, BUT it will occur if some side-track (like from factory) is connected through that area.

Re: Rail choose signal issue

Reply #27 – November 19, 2009, 06:57:21 pm

Quote from: Borek – on November 19, 2009, 06:43:41 pm

I usually place presignals there, so leaving trains won't block the switching area.

That can actually also be achieved by just putting the next signal far enough behind the junction so that the train fits without blocking the area - just what I said earlier. And also just like I said, there is rarely need for presignals (actually I prefer to call them 2-block-signals, since that's what they are - they don't act like presignals) any more these days - but "rarely" certainly doesn't mean "none at all".

On some occasions they are highly useful and somtimes even required - but not very often. Most of the times the normal signal is all you need in simutrans - when these are set correctly.

Re: Rail choose signal issue

Reply #28 – November 19, 2009, 07:56:18 pm

Not to forget: Also any waypoint acts as an invisble normal signal (since the route beyond is not known ... )

Re: Rail choose signal issue

Reply #29 – November 19, 2009, 08:00:04 pm

Yeah, I figured it thinking about reason to put waypoints somewhere near the skipped stations. But this signal is valid only to trains using it and will not actually stop them in danger, huh? ;]