Add option to not autodraw all possible jumps when opening GalMap
- Thread starter CmdrThyme
- Start date
Click the 'Fast route' check again to make them vanish. You could reword your request as 'add a more obvious ....' - as it isn't 
I thought there was a toggle under filters somewhere.
See the tags
The request was phrased as such because I think an Option (as in the Options tab) to not draw them would be the way to go.
I think the fact that the selection is a Radio Button is quite sufficient.
They do that, yes. However, that is a workaround that works for now, but that behaviour might change if the GalMap is changed (as you're essentially untoggling a parameter for route planning). Adding an explicit option to not show them additionally takes away ambiguity.
I am pleased you find it sufficient
I am pleased you find it sufficient
I am interested in why you think this behaviour is a "workaround"? The use of a "Radio Button" for On/Off as well as selection is rather ubiquitous in computing so why the route choice button doing this should offend you seems strange to me. The idea that you are "untoggling" anything is a complete misunderstanding - you are not turning off any route planning, just the spider lines.
Maybe if instead of just clearing the "Radio Button", subsequent clicks changed colour of the box (rather than having filled and blank) that would satisfy someone's need to have further evidence of whether economic or fastest route calculation was in effect.
First things first, I take no offense at inconsistency, but it may lead to error, and that can and should be avoided.
Now, as to your question and the context of it. Couple of reasons.
First off, a radio button is pretty well defined in terms of UX. It's a toggle between different inputs. I think you might be referring to a checkbox. I know Apple introduced some design primitives that might lead one to believe otherwise, but if we're going by well-defined in computing, let's stick to what is pretty much bog standard. Anyway, it's not really relevant.
The design logic is that display options are presented together, you can see that for yourself in the options tab. The workaround is a workaround (even if you're used to it) because you're using a functional toggle, which is present in a functional context, to toggle a display option. You can see it's a functional context in the options present around that particular button, they pertain to route planning, not purely display, alteration of what is displayed is a side-effect of a functional state change.
Now, seeing as this is pretty much UX 101, there's a definite chance that anyone working on this part of the game will inadvertently alter the current behaviour, thereby removing the current workaround. This can be avoided quite easily, even without right now removing the current workaround.
Additionally, as it was already pointed out the current workaround is non-intuitive, it's a QoL improvement for I daresay quite a number. And additionally to that, overall it will in all likelihood lessen pre-emptive load.
Anyway, we're probably not going to see eye to eye on this. So, it's probably best if we stop wasting each other's time.
Now, as to your question and the context of it. Couple of reasons.
First off, a radio button is pretty well defined in terms of UX. It's a toggle between different inputs. I think you might be referring to a checkbox. I know Apple introduced some design primitives that might lead one to believe otherwise, but if we're going by well-defined in computing, let's stick to what is pretty much bog standard. Anyway, it's not really relevant.
The design logic is that display options are presented together, you can see that for yourself in the options tab. The workaround is a workaround (even if you're used to it) because you're using a functional toggle, which is present in a functional context, to toggle a display option. You can see it's a functional context in the options present around that particular button, they pertain to route planning, not purely display, alteration of what is displayed is a side-effect of a functional state change.
Now, seeing as this is pretty much UX 101, there's a definite chance that anyone working on this part of the game will inadvertently alter the current behaviour, thereby removing the current workaround. This can be avoided quite easily, even without right now removing the current workaround.
Additionally, as it was already pointed out the current workaround is non-intuitive, it's a QoL improvement for I daresay quite a number. And additionally to that, overall it will in all likelihood lessen pre-emptive load.
Anyway, we're probably not going to see eye to eye on this. So, it's probably best if we stop wasting each other's time.
Maybe it doesn't affect route planning (I still think it does though), however it disables "use jet cone boost" option which definitely does affect route planning. So if you want to toggle that, you have to enable this option which might cause short hang.
My reply to @corous was in response to their ' however it disables "use jet cone boost" option ' - the image suggests that, once enabled, the "use jet cone boost" is still in effect even with the spider lines suppressed. I am not in a position to test this in-game at the moment but my memory says that is the situation - of course I could be mis-remembering. (Yes you have to have the fastest box "filled" to initially select the jet cone boost.)
By the way - I don't object to the idea of having an option available - my reaction was just "do we really need it since the facility is already provided?" - that's all.
By the way - I don't object to the idea of having an option available - my reaction was just "do we really need it since the facility is already provided?" - that's all.
Last edited:
I understand the misunderstanding. I interpreted that as saying the option is disabled, hence, when you want to toggle that option, you cannot. If you enable that option, and then toggle the fastest routes parameter, the jet cone boost options visually remains enabled. My guess is it is functional, but haven't tested that.
But that's also part of the point; it is not internally consistent, we cannot predict the behaviour, and we sure as hell can't rely on this workaround to remain functional. If my decades in this industry have taught me anything, it's that un(der)documented features will die, it's just a matter of when.
Adding to that, anything that takes a little bit of pressure off that poor overworked route planning engine is a good thing
Anyway, I want to thank you for the persistent questioning. It has allowed the point to be made abundantly clear.
o7
But that's also part of the point; it is not internally consistent, we cannot predict the behaviour, and we sure as hell can't rely on this workaround to remain functional. If my decades in this industry have taught me anything, it's that un(der)documented features will die, it's just a matter of when.
Adding to that, anything that takes a little bit of pressure off that poor overworked route planning engine is a good thing
Anyway, I want to thank you for the persistent questioning. It has allowed the point to be made abundantly clear.
o7
Excuse the re-opening of this but I had a chance to check this last night and I was actually wrong.
So, for example: you have a route calculated with Fastest Route box and JetCone box both filled-in - you get a route plotted that includes jet boosts. Now clear the fastest route box and the jet boosts disappear from your route (even though the box still looks filled) and a new fastest route is presented.
So my apologies about this, I had remembered totally wrong.
I’m a bit confused... (nothing really new, there )...
I thought the radio buttons directly selected the route plotting mode, and that at least one of them had to be selected (since it looks like a radio button array)?
If it is possible to unselect them all, what does the route plotter do when it tries to plot a route to a distant star? Does it always use the last mode selected, always use “Fast”, always use “Economical”, or something else entirely?
I would really like to get rid of the blue sea-urchin a lot of the time, but retain whichever plot mode I wanted. Which probably means I am in favour of the OP, but I really have no idea what is going on now
)...I thought the radio buttons directly selected the route plotting mode, and that at least one of them had to be selected (since it looks like a radio button array)?
If it is possible to unselect them all, what does the route plotter do when it tries to plot a route to a distant star? Does it always use the last mode selected, always use “Fast”, always use “Economical”, or something else entirely?
I would really like to get rid of the blue sea-urchin a lot of the time, but retain whichever plot mode I wanted. Which probably means I am in favour of the OP, but I really have no idea what is going on now