I suppose it was inevitable that this one would come up for discussion again. It usually does from time to time.
Supercruise. The gameplay aspect everyone loves to hate. Always portrayed as "netflix time" or something similar. Set the blue, point in the right direction and wait. Except it isn't. There's fun in learning the mechanics of supercruise well enough to use them in your favor. How to use gravity wells as convenient brakes, the good ways to use them to scrape off a pursuing pirate (or copper) before they can interdict you, how a carefully judged overshoot might not result in a "loop of shame" but in your pursuer never getting into position to pull you over. Know it well enough and you get to the point you can do these things to players not just to NPCs, to the point that you're near impossible to catch in SC if you're prepared to "play the game" because there's no such thing as a "faster ship" in SC, only a "better SC pilot".
Nobody wants that gone, at least nobody who isn't secretly wishing for an "I win" button or to take the sense of scale completely out of the game, but yes, it can sometimes take huge amounts of time. So people talk about intrasystem jumps and autopilots, because thankfully most folks are smart enough to realize that in a shared realtime environment the kind of time-compression single-player games use is a non-starter. Given that autopilots appear to be completely off the table (there has never been a hint of a favorable response from FD regarding any more automation than the docking computer) that leaves microjumps.
FD HAVE engaged with the subject of microjumps. I remember at least two previous threads on the subject where Sandro got involved. Now Sandro is good at his job and knows not to commit FD to anything that they have not already publicly announced but in both those discussions he was prepared to admit that the subject of microjumps between the stars of multistellar systems had been discussed at fD and that it hadn't explicitly been ruled out. They don't want to cramp the sense of scale but they are aware of the frustrations folks feel over excessive SC times. At the same time places like Hutton that are (in)famous for being a long trip from the drop point have become the focus of several "community features" and I can see why they wouldn't want those factors vanishing either.
I think I have an answer that's a suitable compromise. Nav beacons. When the game fist appeared they were placeholders and were nothing more than a persistent deep-space instance. They were later given the functionality of "scan them for complete system info." Currently there is one per system located near the system primary. I propose adding nav beacons to most, but not all, other stars in inhabited multistellar systems too. You can scan any of them for complete system info, just as you can the solitary one in the system now. Once you have that complete info you can microjump but only from one nav beacon to another in the same system. I said "most but not all" because of course nobody wants to take away Hutton's special cachet. Sadly the Proxima system would be one of those which still only had a single nav beacon. There would be others where you still had no option but to make the run in SC too. Of course, since their target systems are uninhabited, explorers would find their gameplay unimpacted. There might also be (given the laws of probability there almost certainly would be) situations where you're at a station so far out from its star that it would actually be quicker to SC over to a station orbiting a different star in the same system than to SC back to the primary, microjump then SC out to your target station from the other stars nav beacon. Sense of scale preserved, need to make informed planning decisions preserved, a little more depth added to no harm and significant gain to folks frustrated with extended SC times.
![[Diplomacy] Carnegie](https://d2aefvhu2f0gi9.cloudfront.net/data/avatars/m/123/123809.jpg?1553527149){kind=avatar}