Check spaceport being behind a body while drawing nav target indicator

[WKFO]

Draw nav target icon differently for starports that are behind the frame body.
Demo: https://www.youtube.com/watch?v=7KSaPZqU9eA

The math may not hold too well with ground ports on concave-shaped asteroids but it still would be better than not having it at all IMHO.

[impaktor]

Do we want this for ships as well? Is it needed / possible?

[WKFO]

Ships landed on planets? Possible. Ships in flight? Not with the one-line vector math (just a dot product really) I did here. It could be possible with the following, which is quite simple too:

Needed? I have no idea. Should be unimportant relative to ground stations' case.

[WKFO]

Also, this is only a draft because I didn't figure out what to do with the indicator after performing the check.

[bszlrd]

Nice!
How about using a full frame around the icon while obstructed? And the usual corner type if not.
For ships in flight I don't think that it is that important.

[WKFO]

In drawings full solid lines are usually used for things in front and dashes are used for things in the back so I think having it the other way around could make it a bit awkward.

This morning I was thinking of sth like:

...or a dashed/dotted version of the usual corner-frame type, like:

Now that I think of it again, maybe the first two ones may be confused for it being impossible or forbidden. The dashed one seems best to me.

[bszlrd]

Dashes sound good. I agree that the crossed out implies more like something that's forbidden.

[Web-eWorks]

I've thought about switching to a circular target outline rather than square when the target is on the reverse side of the planet. A dashed outline is fine-ish, but it's already a very small outline and making it dashed may not be readily apparent.

[craigo-]

Diamond?

[WKFO]

Circle and diamond are also good. Given the choice I would go with circle to increase the contrast.

[WKFO]

Ah, well, the circle one is used for something else already (I think position/orientation follow). Also, I'm suddenly not so "pro-diamond" because diamonds belong to velocity-vector family of icons in my head and it would get me confused.

I propose the sort-of-negative of the nav target square.

[craigo-]

I quite like your negative-space square, @WKFO.

Have you exhausted/rejected the idea of the standard indicator in a different colour? I had no problem with the red indicator in your video... unless a red indicator is used for other scenarios (combat target?) Would a blue square work? Would want the colour scheme to be consistent - not sure if there is a style guide around this.

[bszlrd]

Shape is always clearer than color for reading at a glance. Especially if we take the 10% colorblind in the population into account.
That negative space one does look good in my opinion, and could be combined with that color change. Or just a faded/darkish gray color, because a that vivid color change could read more like a warning or attention grabber, especially the red, but the saturated blue too. Also, we use a brighter blue for maneuver indicators, which is a possible clash.

[craigo-]

Thanks @nozmajner - all good reasons and nicely explained.

I think I've exhausted my input 😄 Happy with whatever is decided.

[Web-eWorks]

Have you exhausted/rejected the idea of the standard indicator in a different colour?

Generally speaking there is enough information already presented by "overloading" the same UI elements with different meanings in different colors that I don't want to add yet another distinct color tone into the mix. Not only is symbology a better fit for this, but this keeps our options open for the future to allow e.g. manufacturer-specific HUDs or users to better configure the color and theme of the UI.

The standard indicator is also already colored to indicate whether it is a nav- or combat target, so color is not a great fit here.

Ah, well, the circle one is used for something else already (I think position/orientation follow).

IIRC a circle is currently only used for the frame-up-direction indicator, which by nature will never be coincident with a target on the other side of the planet. It's also rendered in a different color to both the nav and combat targets, which makes it a viable candidate in addition to the natural symbology of a planetary circle for a target on the other side of a planet...

Also, I'm suddenly not so "pro-diamond" because diamonds belong to velocity-vector family of icons in my head and it would get me confused.

Personally I'd rather the diamond currently used for the prograde vector be replaced with a more standard prograde indicator of some sort, as diamonds are a very general-purpose shape and could be used for a number of different symbology options, including a target with no clear line of sight. This is not to say the diamond is a bad prograde indicator, merely that it could have many more uses.

[WKFO]

Now also checks for orbital stations being behind the body. Also the icon is added. The PR should be ready to test & review.
Demo: https://www.youtube.com/watch?v=7KSaPZqU9eA

[robothauler]

I stumbled over this error:

Warning: Caught error in Lua UI code:
[T] pigui/modules/flight-ui/indicators.lua:121: attempt to index local 'frameBody' (a nil value)

The crosshair and the square disappear sometimes.

[azieba]

Dashed lines are customary for invisible lines in any technical drawing so it would be quite intuitive.

[WKFO]

I stumbled over this error:

Warning: Caught error in Lua UI code: [T] pigui/modules/flight-ui/indicators.lua:121: attempt to index local 'frameBody' (a nil value)

The crosshair and the square disappear sometimes.

Yeah, right, sometimes one simply doesn't have a frameBody. Should be fixed now, with the latest commit.

[craigo-]

Just a note to say thank you for this work, @WKFO - I am finding it really useful. And the dashed square works well.

Would you consider extending this to (at least landed) ships also? On the rescue mission pictured below, it would have been great to know at a glance that the ship in distress was on the far side of the horizon.

[WKFO]

The math works exactly the same for any target so this feature can be extended for pretty much all targets. This seems like a useful case so why not?

That being said I need to find time to get to do that.

[azieba]

Would you consider extending this to (at least landed) ships also? On the rescue mission pictured below, it would have been great to know at a glance that the ship in distress was on the far side of the horizon.

PR #5481 contains what you request. I found it very useful too and extended it for all types of targets.