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.
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.
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...
I use electrification preview.
If you drag electrification between two points, and they don't preview the build, then it's disconnected.
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.
I just remembered another place where disconnects may go unnoticed due to lack of bumper graphics: slopes.
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.
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.
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".
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 ?
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.
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 ;)
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.
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.
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?
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.
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.
Building signals "automatically", by keeping mouse button down between two points of the track, avoids such problems on long linear sections at least.
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)
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.
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.
This is definitely helpful.
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.
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.
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).
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.
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.
What does signal state have to do with this?
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.
Since this patch is lost and there is the newer arrow overlay, I put this to solved for now.