The issue is that Oromarch is branched off from nodeID A3A, which generates only half the time in a vanilla game. Changing it to be a guaranteed node and altering A3 to generate half the time would fix this without otherwise altering gameplay.
I don't see how this could happen. The Eternity Port topology always create a gate to A3A (and from there to Oromarch).
I you have a game that shows this, please attach and reopen.
Done. I’ve also added a map generated by TransData with just SotP and ATS topology. It shows the disconnected branch to Oromarch (and the unreachable Manchester system between Rigel Aurelius and Charon).
I think I can see what’s happening. Eternity Port topology always creates A3A, but vanilla topology might not, and would therefore go from A3 to PJ. The problem seems to be due to the way stargates are all named either Inbound or Outbound. If there was no A3A generated by vanilla topology, this causes both A3 and A3A to go to the same destination stargate in Point Juno. That destination gate, on the other hand, can only go to one of those two stargates, and it will always go to the node specified first — the one in vanilla. Node A3A will always generate with the Near Stars Addon and even have the branch to Oromarch attached but, depending on how vanilla topology turned out, A3A not be reachable.
Basically, the changes being recommended are on lines 391 and 397 in HumanSpaceMap.xml:<Stargate from="EC:Outbound" to="A3:Inbound"/>
…to this:<Stargate from="EC:Outbound" to="A3A:Inbound"/>
…and…<Stargate chance="50" from="A3:Outbound" to="PJ:Inbound"/>
…to this:<Stargate chance="50" from="A3A:Outbound" to="PJ:Inbound"/>
Both systems are Level 8 systems, so there would be no noticeable effect on gameplay. Note that in this fix, A3 will still generate in ATS topology, but there will be no way to reach it because Outbound in EC will already go to Inbound in A3A, and vice versa. (This also happens with C4 and the optional C4A in vanilla. The C4A always generates in Eternity Port, but may be unreachable if vanilla didn’t create it first. As long as gameplay isn’t meaningfully affected — which, in this case, it isn’t — this may be acceptable.)
Another alternative that would help to alleviate potential issues in the future would to be to use unique stargate IDs for each gate instead of a universal Inbound/Outbound ID for all of them, which would probably require a rewrite of at least one topology/stargate lambda.
A few notes:
- In 1.8 Beta 5, I've made A3A a guaranteed system and A3 is random (as suggested).
- ATS should not need to refer to A3, since it will be generated (or not) by the Human Space library. Same thing for C4A.