Death 999 wrote:Well, SC1 maps were 3D, so the chances of two lines crossing were essentially zero
Yeah, I think Dragon pointed that out earlier in the thread (or was it the thread on the old forum, I forget). But the 3D sc1 maps are still relevant in 2D if one wants to preserve about the same number of links per star. In 2D, crossed links might be necessary to do it.
Death 999 wrote:What's the algorithm in use here? I don't know what locality and friendliness mean.
I described it in prose on the wiki
. Feel free to edit that page to clarify parts you find confusing. Locality describes the radius within which other stars are considered for additional (on top of MST) links in the pseudo DT. Friendliness is just an arbitrary factor thrown in to vary the number of links.
Firstly, for each star, I need to define a neighbourhood within which stars are considered for linking. This is because two stars are more likely to be connected if they're closer together. I can't make it a fixed distance for all stars, because if that distance is the same for overdense regions as it is for underdense regions, the graph will have much greater ``connectedness" in the former. What I want is for that distance to be greater in underdense regions. The length of the longest MST edge hosted by a star behaves this way because the points are further apart in these environments.
Basically, I thought it'd be elegant if the graph looked the same on large scales as it did on small. Maybe the graphs from sc1 weren't self-similar, but no-one's complained about that aspect so far and I like it that way
So with this in mind, let's examine the part of the starmap you mention.
Death 999 wrote:For example, I have no idea why, for the stars along the southern border, the stars around 9000 connect to one around 7000 rather than the cluster around 8000. It just seems weird.
To begin with, the MST didn't go across there, so we're left with the pseudo-DT. The stars that have the potential to extend links across that void between 8000 and 9000 are the ones hosting decent-sized MST edges. These are Gamma Arae, Delta Arae, Alcor, Alpha Trianguli, Organon and Hyperion. What the condition used for making pseudo-DT links has said is that links across the void are blocked by intervening stars from all of those but Organon (to Epsilon Arae). So it's not as much a case of Epsilon Arae connecting to Organon as it is a case of Organon connecting to Epsilon Arae.
That's what the algorithm has done. Its last step is debatable. Gamma Arae, Alpha Trianguli and Hyperion are clearly blocked from spawning links across there but it's not so clear for Alcor and in particular, Delta Arae. For Delta Arae, links must have been prevented by its close proximity to the other Arae stars, since the ((r_2)/(2r_1))*((\pi/2)/(\theta)) condition considers nearby stars regardless of what direction they lie in (but direction still comes into play through \theta).
I think this is a mild edge effect. If there were stars beyond the right border, they'd counteract the nearby Arae stars, lowering (r_2)/(2r_1), and then Delta Arae probably would have linked to Trianguli as you suggest. I don't have an easy fix for this. Changing the \theta dependence, or adding fake stars beyond the starmap edges might fix it, but I like the simplicity of what we've got now.