Originally Posted by psefergr View Post (Source)
But according to FD game mechanic logic i can't.
Originally Posted by Riverside View Post (Source)
That decision to was broached at some point by the designers & we ended up with what we have now.
I'm not certain they ever gave it much thought at all to be honest. Remember that supercruise was the second bite of the cherry; the original plan for in-system travel was fixed POIs as micro-jump destinations. With that mechanic there'd have been no consideration given to travelling outside of a planetary system at all, unless there were pre-determined out-of-system POIs such as the Voyager probes.

Once supercruise was green-lit I suspect FD just didn't think anyone would have the need to do this when playing the game "normally" around human space. It's only when you get those edge cases -- "I can make one jumponium hop to the only scoopable star in the area, but then I'll be a quarter light year short for the next nearest destination" -- that the lack of fidelity in the simulation is revealed.

Fringe explorers have already demonstrated their ability to think around problems by using game mechanics in unexpected ways e.g. smaller fuel tanks for greater range, or plasma slug rails for fast fuel dumping. I'll be quite disappointed if FD don't include partial supercruise distance closing in the exploration QOL update, or at least give us a very good explanation as to why it can't be done. It would be one more string to the explorer's bow and add another strategic variable to navigation on the edges of explorable space.

Compared with some of the more complex changes we've seen this year, it appears to be relatively simple.

  • What's the jump destination vector [x,y,z]?
  • How far are we from the current barycentre [a,b,c]?
  • A bit of Pythagoras.
  • Is the offset distance within the ship's current range?

Granted some of these data aren't normally available or needed in the normal course of supercruising through a system or jumping between systems, and the destination distances are probably pre-calculated and loaded into the navigation panel as constants during the hyperspace "loading screen". So there'll be a bit of extra realtime calculation. But the galaxy map must use it a lot. I can't imagine looking up the vectors between just two systems on demand would add much of a delay to the GO/NO-GO logic for a single hyperspace jump, even if it means briefly interrogating a server. If it does add an unacceptable delay then it would suggest that the code is arguably in a worse state than I thought.

And if the delay was significant, maybe the client could only perform or request the extra calculations if the initial jump request fails the range test? That way most jumps would be unaffected, while fringe explorers pushing the limits of jump range would presumably be more tolerant of slight delays if the payoff was the ability to navigate through previously unreachable areas. No doubt some wise guy would "prove the system was broken" by flying half a light year away from a maximum range destination system and still making the jump. But I could live with that.

An alternative might be to pre-calculate the vectors for all available destinations and to cache them along with the other navigation data generated during the hyperspace animation. The game must be doing the trigonometry anyway just to calculate the jump distances, either locally or as a server request that's cached by the client. But that could get messy in the core where there are lots and lots of potential destinations. If that's FD's reason for not doing it then I'll reluctantly accept it. But it will underscore the idea that the code is somewhat limited and inflexible, which would be both disappointing and worrying for future development.

Come on, FD, please give this some thought. I've no idea what other bones you are preparing to throw to the exploration community, especially given the delay to the planned Focused Feedback, but this seems like such an easy win.