The Route Finder Report has always been one of my favorite tools in chView2. Even with the distance links displayed, it can be very hard visually to ascertain a good route between two stars in a three dimensional display. Route Finder makes that considerably easier. The recent addition of a textual report describing the legs of the route with actual leg distances and total distance travelled has made it even more convenient and useful to me.
The purpose of Route Finder is to find the shortest path between two stars consisting of a number of legs, each of which begin and end at an existing astronomical object and are of some limited length. This is the model of Traveller’s Jump Drive, which is capable of 1, 2, 3, 4, 5, or 6 parsec jumps between stars(although in some versions jumps beginning or terminating in deep space may or may not be allowed), my own version of the Alcubierre Warp Drive in FTL mode and apparently C.J. Cherryh’s choice of FTL drive(I don’t recall the exact parameters of that drive, or the name of it, but I do remember that it was restricted to travel along specific routes). This involves a percolation model of interstellar travel where the allowed route between two points may be quite convoluted and considerably longer than the direct path seems to indicate. If the length of the longest allowed leg is less than some critical percolation value, there could even be objects on the map that are mutually unreachable.
One feature, in fact, that I’d like to see added to chView2, eventually, is a tool to determine that smallest critical leg size limit such that all objects on the map are reachable from all others. Because the maps are necessarily smaller than the total extent of the galaxy, it may be a necessary to limit the, “No Orphans,” requirement to some extent smaller than the entire map, as actual routes may exist between objects near the edge that pass through objects that aren’t represented on the map.
With all that in mind, let’s look at how one uses the Route Finder Report.
This requires some set up. First open the Links tab in the Preferences(View>Preferences…:Links tab). Make sure that Show Links and Show Numbers options are both checked, if not click any checkbox without a checkmark to select the option. Now select the numbered textbox at the very bottom middle of the window right above the “OK” button. This is the maximum allowable link between two stars. In my
own science fictional universe the maximum distance that the Warp Drive can travel between two stars is about nine light years, so I enter “9.0”. That sets the maximum leg length that the Route Finder uses. Now we select the two objects between which we wish to travel. Simply click on the first object to select it, then, while holding down the shift key on your keyboard, click on the other end of your desired route. The order of selection
doesn’t matter as the route can be considered symmetrical. For the example, I will select Sol and 61 Cygni A in my localSpace.chv.xml map. With the two termini of your route selected, simply go to the Report menu and select the Route Finder item. From that we get the Route Finder Report shown to the left.
What we see on the report is a route that leaves Sol, passes through BL Ceti, SO 0253+1652, GX Andromedae, Kruger 60, Gliese 725 and Ross 248, ending finally, about 50.9 light years later at 61 Cygni. How cool
is that? The trouble is, as anyone who’s ever wondered about the sanity of their GPS knows, this kind of algorithm doesn’t always find the absolute best route. So, just as a sanity check, let’s have a look at the route on the map(image to the right).
As you can see from the figure, even with the stars nicely picked out and even with the termini circled, it isn’t necessarily easy to see the route among all the clutter of a densely-packed starmap. ChView2 is capable of helping with that. First go the menu and select View>Show only selected. This
will show all of the objects that were selected by the Route Finder and remove extraneous objects from the view. This is only temporary, after you’re done examining the route you can select View>Show All to return the view to normal. In order to maximize the clarity of the view, I also rotated the view orientation a bit. This, much clearer view of the route is shown to the left.
On visual examination, that clump of linked stars at the upper right end of the map is a bad sign. The algorithm is usually pretty reliable, but sometimes it breaks, and this may be one of those times. Looking at the report again, we see that from GX Andromedae the route snakes through Kruger 60 all the way out to Gliese 725 and then way back to Ross 248 before finally ending up at 61 Cygni. In this case, the roughly seven lightyears of the direct route from GX Andromedae is obviously shorter than 4.9 lightyears to Kruger 60, then over six out to Gliese 725, then over eight lightyears back to Ross 248 and then another over five and a half lightyears out again to 61 Cygni. Yeah, that ain’t right. This is instructive, though, both to what a bad route looks like and how to fix it.
First let’s find the route from GX Andromedae to 61 Cygni. That’s a direct route and
about seven light years as shown to the right. Not bad at all…
Now we use Route Finder to calculate the route from Sol to GX Andromedae. Whoa! All over the place and with a distance of over a hundred light years. That’s ugly bad.
I’m not sure what’s going wrong here. If I ever figure it out, I’ll try fixing it. The best way to fix this will be to use the route to GX Andromedae that was calculated as part of the route from Sol to 61 Cygni and use a calculator to figure out the distance.
Sol <-> BL Ceti (8.73 LY), BL Ceti <-> SO 0253+1652 (8.03 LY), SO 0253+1652(8.79 LY) for a total of about 25.55 LY. Now our last check gave us a direct route from GX Andromedae to 61 Cygni of about 7.08 LY. Adding those together, we get a total distance of about 32.635 LY. The resulting route is shown in the image above and to the left. After a bit of jiggering with Open Office, I was able to create the following official-looking Route Finder table.
I really need to get rid of circled-R symbol. For some reason, I thought it was cute, now it just seems kind of stupid…
Again, if I can ever figure out what’s gone wrong here, I’ll try to fix it, but I’m still mystified. I’d certainly welcome advice. It seems to happen less frequently with smaller maps and a lot with larger maps, and as shown in the example, it’ll work fine over some parts of the route and blow up even worse over others. The code is zipped into the jar file if anyone would like a look…
I hope this has been useful, and I would love some help with this,