I’m looking into how I can make this possible. In the meantime, I want to shed a little bit of light onto how the process of accepting/rejecting ideas works behind the scenes. So, here’s a small rant about how seemingly simple ideas might actually be far more complex upon closer inspection.
Say for example that you want to solve this by simply hiding the asterisk for any player who comes near a wormhole (and presumably show it again when they’re sufficiently far away). On its own, that’s a simple distance check – but a distance check that needs to be done on every frame, for every player, and for every wormhole. There are about 20 wormholes and up to 900 relevant players (that you can see in the galaxy), that’s 18000 distance checks per frame. That’s a heavy price to pay, especially on mobile platforms.
So, maybe you decide to optimize this and only check for players who are moving. That cuts down on unnecessary work, but disproportionately complicates the code handling the asterisk. Whereas before you only had a uniform rule…
“Show asterisks only if user has enabled them in the Information Overlay”
… suddenly the rule has become a lot more complex:
“Show asterisks if user has enabled them in the Information Overlay, except don’t show them if a particular spacecraft is near a wormhole, but do show them if the wormhole is explored, or if the player starts moving, but only if they’re moving sufficiently far away”
This additional code has to be maintained on several platforms and interact correctly with dozens of other interdependent features, existing or planned (such as the fact that asterisks need to fade in/out as camera zooms in/out, or with another idea I saw that on-line players should have differently-colored asterisks).
It’s a good idea. It may see the light of day. Or it may sadly not, for reasons entirely unrelated to its worth.