News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

method for finding unconnected tracks

Started by phillyj, February 28, 2014, 04:45:34 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

phillyj

Sometimes it is not obvious that a track or road is not connected. Sometimes, careful examination of the route fails us, since the eyes probably overlook it.

My method is to have the route in question be run using waypoints. For example, place a waypoint as far as possible and run the vehicle. Try a few different point and eventually you will find the point which the vehicle can't cross. It's systematic, don't just randomly place points hoping to find the location.

Ters

I just rebuild the track at known problem spots (bridges, tunnels, certain platforms), progressing to less likely spots if that fail. If electification is involved, I try to rebuild that first, which can be done over long stretches with little fear of unintended effects. This tactic will however fail if the problem is with signals, but that's rarely the case, for me at least.

Combuijs

QuoteMy method is to have the route in question be run using waypoints. For example, place a waypoint as far as possible and run the vehicle

I use a slightly better method by trying to place a waypoint halfway each time. So, first time halfway between start and finish. If no route is found, try another waypoint halfway start and first waypoint. If a route is found, try another waypoint between first waypoint and finish. Etcetera.

Known to programmers as binary search...
Bob Marley: No woman, no cry

Programmer: No user, no bugs



ӔO

I use electrification preview.

If you drag electrification between two points, and they don't preview the build, then it's disconnected.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

benjad

Quote from: Combuijs on February 28, 2014, 07:59:29 PM
Known to programmers as binary search...

Had to chuckle... just taught that today... somewhat successfully.

That being said, the pakset goes a long way to helping you find these 'adjacent tiles' not connected.  I like paksets that have large 'bumpers' at the end of rails... that helps a lot. 

Ters

I just remembered another place where disconnects may go unnoticed due to lack of bumper graphics: slopes.

phillyj

Quote from: Combuijs on February 28, 2014, 07:59:29 PM
I use a slightly better method by trying to place a waypoint halfway each time. So, first time halfway between start and finish. If no route is found, try another waypoint halfway start and first waypoint. If a route is found, try another waypoint between first waypoint and finish. Etcetera.

Known to programmers as binary search...

Yes, that is what I meant. Sorry for my poor explanation. Much faster than following the roads by sight.

Ters

Quote from: phillyj on March 01, 2014, 04:24:02 PM
Much faster than following the roads by sight.

I guess what gives it an edge is that the vehicle can start moving immediately as far as it gets, rather than having to wait at the starting point until everything is fixed. But visual inspection can be done with the game paused, which might be important if things pile up quickly while something is stuck.

prissi

The problem with "Halfway waypoint" is that to set a waypoint at half way, a computer need a successful way search, which does not finish for "not found".

gauthier

Just a simple algorithm idea to find such connection problems automatically : for each way ending, test if there is an opposite ending just after it. Could it be easily implemented ?

prissi

That would be a way search ignoring ribis, and it is easy. However, this will not find signals facing in the wrong way. One would then need a special convoi, which uses the setting of the routeless vehicle to find the missing linke, wrong singal, wrong slope ...

I tried a patch with only a modified route search, but it is not very easy for a computer to find the right missing ways. Even in very simple geometries. SO one may need to drive this found route also.

Combuijs

Quote from: prissi on March 01, 2014, 09:23:44 PM
The problem with "Halfway waypoint" is that to set a waypoint at half way, a computer need a successful way search, which does not finish for "not found".

I know, my method is meant to be performed manual  ;)
Bob Marley: No woman, no cry

Programmer: No user, no bugs



ӔO

How about a visual toggle to highlight all the dead ends?
or a visual toggle to replace all signals with arrows in which they face?

The latter would obviously require a pak for the images.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

AP

Quote from: ӔO on March 02, 2014, 12:54:05 AM
How about a visual toggle to highlight all the dead ends?

That sounds (a) simple, and (b) very useful.

Lmallet

Quote from: ӔO on March 02, 2014, 12:54:05 AM
How about a visual toggle to highlight all the dead ends?

You beat me to it :).  I take it the ribis are different when something is connected vs. something is not?

isidoro

I like the idea of highlighting dead ends and arrows for signals.  The second part is even useful when building two one-direction parallel rail tracks.  Sometimes it is difficult to see the direction when placing one-direction signals on curves.


Red_Wraith

Quote from: ӔO on March 02, 2014, 12:54:05 AM
or a visual toggle to replace all signals with arrows in which they face?

I would love that feature. I've already spent too much time debugging signals and trying to see where the signals are. That's especially difficult with monorail tracks which often cover the signals (at least in pak128). If it was possible to temporarily display big arrows on the tracks, that would help a lot.

gauthier

Building signals "automatically", by keeping mouse button down between two points of the track, avoids such problems on long linear sections at least.

mph1977

missing electrification can be seen if you open the map view  and click on 'tracks' as  none electrified track is white and electrified track is red ( although it won't show  what type of electrification is present)

Ters

Quote from: mph1977 on August 13, 2014, 04:56:11 PM
missing electrification can be seen if you open the map view  and click on 'tracks' as  none electrified track is white and electrified track is red ( although it won't show  what type of electrification is present)

That works for tunnels (I guess), and even some bridges, but perhaps not so much for the occasional tile gap.

Philip

Quote from: isidoro on March 02, 2014, 02:30:11 AM
I like the idea of highlighting dead ends and arrows for signals.  The second part is even useful when building two one-direction parallel rail tracks.  Sometimes it is difficult to see the direction when placing one-direction signals on curves.

Here's a five-minute hack (patch against Experimental) to do something like that, using ASCII text overlays rather than arrow symbols (which has the advantage of making them more visible as you zoom out). To enable the overlays, go into block reservation mode with the B key. Could anyone confirm this is something like what they had in mind? I believe Unicode has characters for diagonal arrows, so we could probably avoid the trouble of adding PAK support...)

I'm not sure I understand what precisely should be indicated for electrification.


isidoro

Very nice!  But diagonal arrows would make it look better indeed.

I guess that what was suggested for electrification is marking "dead ends" in the wires, i.e., in a certain point the track can be contiguous, but the electric wires aren't.

Ters

Quote from: Philip on August 13, 2014, 07:02:38 PM
Here's a five-minute hack (patch against Experimental) to do something like that, using ASCII text overlays rather than arrow symbols (which has the advantage of making them more visible as you zoom out). To enable the overlays, go into block reservation mode with the B key. Could anyone confirm this is something like what they had in mind? I believe Unicode has characters for diagonal arrows, so we could probably avoid the trouble of adding PAK support...)
There will of course will a lot of false positives (the screen shot is nothing but), but I think it might still work. As for Unicode, the font might not contain these symbols. The new font backend being worked on currently might reduce this problem.

Quote from: Philip on August 13, 2014, 07:02:38 PM
I'm not sure I understand what precisely should be indicated for electrification.
Pretty much the same. The exact text can be tweaked later.

Philip

Quote from: Ters on August 14, 2014, 05:00:32 AM
There will of course will a lot of false positives (the screen shot is nothing but), but I think it might still work.

I'm not a hundred percent sure what would constitute a false positive. This modified version uses red messages only for the common (for me) case of two dead-ends facing each other, pretty much, not for regular dead ends in the middle of a field.

Quote from: Ters on August 14, 2014, 05:00:32 AM
As for Unicode, the font might not contain these symbols. The new font backend being worked on currently might reduce this problem.

Your suspicion is correct. I ended up using fontforge to add diagonal arrows to the BDF file, though the font code also fails to work for fonts with fewer than 256 glyphs some of which still have code points > 256.

(To test this with the Unicode characters, use the attached font file and edit en.tab to include an initial §. It should just fall back to ASCII characters, though).

Ters

Quote from: Philip on August 14, 2014, 06:42:18 PM
I'm not a hundred percent sure what would constitute a false positive. This modified version uses red messages only for the common (for me) case of two dead-ends facing each other, pretty much, not for regular dead ends in the middle of a field.

Then you've modified away most of the false positives. It will still generate a few for the map I currently have, but I can't think of any way the game can realize that those dead-ends facing each other are not errors. In fact, when not intentional, they can be one of the most difficult breaks to find in pak64: a platform divided in two.

prissi

I think I would prefer an arrow graphics overlay; that would point in the right direction and could get a color (depending on the signal state). Theose arrow could be very flimsy in certain ddd box settings.

Ters

What does signal state have to do with this?

Philip

#28
Quote from: prissi on August 17, 2014, 09:45:01 PM
I think I would prefer an arrow graphics overlay; that would point in the right direction and could get a color (depending on the signal state). Theose arrow could be very flimsy in certain ddd box settings.

I don't disagree that would be nicer (and I seem to have a problem with the tooltips disappearing in some zoom levels (ETA: I think I've got this tracked down and fixed now)), but I don't know how to go about it. Any hints would be appreciated. Certainly text arrows can also be given a colour, though signal state is usually quite obvious from the reserved blocks, so that's not really necessary.

prissi

Since this patch is lost and there is the newer arrow overlay, I put this to solved for now.