[Proposal/POC] Sensor overhaul

[Ownezx]

This PR proposes an overhaul of the raw sensor data system. The objective is not to merge this as it is, but for others to try out. Depending on the feedback I will separate in smaller PRs for integration.

The main objective of this PR is the following:

• Separate the calculation of the raw sensor data into an util file in order to call it in an identical way in different components
• Propose a new sensor data model with the following characteristic
  • Tries to stay as close to the original as possible with negative traces being absorption
  • The isolation of the sensor sum function to open for new shapes for sensor traces in the future
  • The use of perlin noise in order to make the noise feel more interesting than just a random
  • Summing all traces using a square root to flatten extremes but also make it less obvious when two objects are stacked on another
• Reintroduces [PROPOSAL/POC] Detailed signal visualization on Science #742 in the map view
• Adding a first version of a sensor screen ([Feature] Sensor screen #2417) to show a more precise version of the raw sensor data. This sensor screen would ideally end up in the alternative screen as it is not a role. This screen could also be useful as a developer or scripter to debug the raw sensor data in entities in a scenario.

Other notes:

• Integrated FastNoiseLite
• Fixed nebula traces being the incorrect size
• Added a graph graphLabel GUIElement
• Added a LongRangeRadar raw_radar_range and raw_radar_noise_floor component with Lua bindings and GM tweaks

Sensor screen screenshot to show new raw sensor

Please note that the screenshot do not convey the dynamic nature of the raw sensor data.

Kesler spawn, the asteroid ring shows a higher gravitational density to the side where there are many asteroids together

Scurvy scavenger spawn, showing how nebula combines

The omicron plague spawn

[oznogon]

As someone who loves the idea of a more sim-like sensor experience, I want to like this. In this state though it feels like a few things are missing.

The biggest is a chicken-and-egg problem: signal values on entities aren't particularly meaningful because there hasn't been a meaningful reason to pay attention to them without a view like this. Those values should be revisited, either as part of this PR or after some iteration of it is implemented.

Aside from that:

• The square radar with Relay's shared-short-range visibility, and with only two zoom levels available, is too different from how radar/sensors work elsewhere. Relay has its shared-short-range view for comms purposes and it doesn't fit will here, although I think I see what you're going for by providing mark controls to chart signal bearings.

  I'd expect the Sensors screen to have Science's radar view, but with sensor values instead of trace icons for unscanned entities and with a range up to the larger effective sensor band distance.

• The range as depicted in both the signal band and the map are unclear and can't be tuned. The radius of the arc drawn on the radar doesn't seem to be related to the range of visualized entities. I'd expect at a minimum to know what range the sensors are picking up signals, and to be able to set a limited signal-sensing range. The arc's radius should reflect the defined sensor range, and ideally this would also control the map's zoom level.

  For instance, if I know there's a signal I want to inspect within 10U or 5U of me, I should be able to reduce the sensor range accordingly to cut out the noise of black holes/nebulae/etc. far outside of that range. Even better, if I want to inspect an area between 25U and 30U from me, for instance to determine if there are objects outside of long-range radar range where we want to jump, I should be able to set both a minimum and maximum range to inspect.

• Adjacently, there's no range resolution in the band. There's some attenuation by distance, but there's no means of distinguishing the distance of a signal from the ship on a given vector.

  If a goal of Sensors is to identify and place signals on the map, it needs some means of determining and marking both bearing and range. A toggle for the signal band visualization to switch from position to distance, visualizing from left to right by nearest distance within the arc rather than by heading, might be useful there.

• The noise floor is too active to detect signals with low values, such as small ships, which get fully washed out in the noise. This isn't inherently bad except that there's no way to filter the noise, and when combined with the indefinite range, this view becomes hard to use at the most common kind of sensor interaction in the game: answering "where's the target ship?"

  Either the floor needs to be less noisy or there needs to be a way for the Sensors crew to improve SNR. Maybe actively over a limited decay period (i.e. repurposing the scan minigame controls to "negate subspace noise" or some other technobabble, and then temporarily turning down the noise floor effect) or maybe through coordination with other officers (i.e. movement, shields, and loaded tubes generate noise, so Sensors has to convince the bridge to reduce combat readiness in exchange for sensor resolution).

  I don't think this should delve further into simulation territory; implementing STC/FTC would be overkill. But Sensors should have some way to reduce that noise.

• Likewise, I'd expect Sensors to control gain or amplify weak signals in order to see them more clearly, at the expense of definition in more powerful signals. If I can lessen the noise and increase the gain of certain sensor bands, I could then tune them to distinguish weaker signals, which would make this more usable for detecting ships.

• With this view making sensor values meaningful, the base/default values for entities should be listed on their related Science DB pages, and the DB view should be available from here as it is for Science.

And then the figurative elephant in the room: as it stands, this doesn't really add much to the game as a separate screen. There's no clear demonstration on what this screen does in existing scenarios, or what scenarios might be possible with this screen that aren't easy or possible to implement without it.

For instance, there'd need to be more controversial additions to make this more useful than Science scanning, such as the potential of cloaked ships, ECM/radar jamming that needs to be cut through, transponder spoofing, or long-range navigation.

• If there could be cloaked ships, then Sensors would be an important station for finding them by identifying and inspecting aberrant signals.
• If Sensors had a way to identify and paint targets beyond short-range radar range within radar-obstructed areas like nebulae clusters, Science could scan them even if they're otherwise obstructed.
• If ships could disrupt automatic missile homing, Sensors could paint and manually track the homing target in order to guide the missile and defeat the countermeasure.
• If Science scans a target but suspects a spoofing or friend-or-foe issue, Sensors could inspect the signals and compare to the database to confirm.
• The eternal question of setting the jump distance to a point outside of long-range radar range. How far should we jump and is it safe to jump there? If Sensors can detect and identify whether a distant location is vacant or potentially hazardous, it becomes more valuable to that aspect of Helms/Relay.

[Ownezx]

Thank you for the very thorough review, I agree there are many things missing especially considering I did not want to commit too much to a full feature, but just a POC.

I want to reemphasize that this is not just a screen, but also a tool for development and scripting.

Answering in order:

The square radar with Relay's shared-short-range visibility, and with only two zoom levels available, is too different from how radar/sensors work elsewhere.

• I wasn't sure how to handle zoom because I wanted to assign the scroll mouse to the arc size. I do agree that it is very different than other places. I don't have a good answer to that for now.

The range as depicted in both the signal band and the map are unclear and can't be tuned

• Arc length was set to not overflow out of the map, having it fit to range would make a lot of sense before integration.

I should be able to set both a minimum and maximum range to inspect.

• I intentionally chose to force the player to get all the signals. I consider they all come from the same direction and unfilterable. Having range that could be set could mitigate the importance of nebulas. For instance, if I want to detect a ship behind a nebula I just set the min range just after. I think it would break some interesting nebula shenanigans that exist. This is also consistent with the way science works.

Adjacently, there's no range resolution in the band. There's some attenuation by distance, but there's no means of distinguishing the distance of a signal from the ship on a given vector.

• Players should not have distance indication from just a single sensor trace, a close entity with a small sensor trace will be the same as a large entity that is far. Target distance should be found by tracking the same object during ship movement or by launching probes to triangulate targets.

The noise floor is too active to detect signals with low values

• In this PR I wanted to really emphasize how the noise floor can affect readings so it's intentional, the noise floor can be tweaked using the GM screen or in lua. It would be up to the dev to set a default and the scripters to find useful ways to use it.

But Sensors should have some way to reduce that noise.

• Definitely something worth discussing. For now I'm mostly adding a tool to visualize data in a different way and reworking the sensor system to be more interesting.

I'd expect Sensors to control gain

base/default values for entities should be listed on their related Science DB pages

• yes and yes! Should be added for sure if this is a desired feature.

---

Now as for the last section, I would tend to disagree on the fact that new features are needed to justify a sensor screen. Any scenario that involves searching an artifact or following a strange signal can be used with the sensor screen.
One particular scenario I have in mind in which such a sensor screen would have been immensely valuable is Xansta's Liberation day:

https://github.com/Xansta/EEScenarios/blob/master/scenario_27_liberation.lua

In this scenario, players have to find unknown devices that are not visible on the map. We failed the scenario several times in a row and I believe such a screen would have improved our playthrough the first time around as we had not really found the anomalous entity.

[oznogon]

I wasn't sure how to handle zoom because I wanted to assign the scroll mouse to the arc size.

I'd suggest a GuiSlider zoom control, as used on other radar screens with adjustable view distances. It doesn't have to be connected to the mouse wheel but could still be controlled by manipulating the slider.

For instance, if I want to detect a ship behind a nebula I just set the min range just after.

I don't think I communicated this point very well, then. The signals of occluding objects would still occlude sensor readings that target the space behind it, just as they occlude the radar visualization on Science.

I'm not suggesting the bending of spacetime here. If we're behaving like these signals represent something like linear signal reflection, then the suggestion is to display reflections from a given pulse range.

That would include signals from occluding entities like nebulae, but not from non-occluding entities like ships. That too is consistent with how Science works, since they can see traces for ships that are located behind other ships, but not traces for ships that are located behind occluding entities.

Since it sounds like you're also not interested in an A-scan view:

Players should not have distance indication from just a single sensor trace, a close entity with a small sensor trace will be the same as a large entity that is far.

then for me the Sensor screen's value becomes more difficult to understand compared to Science, which gets the data derived from an A-scan view (distance, heading, and relative speed) for free even for unscanned entities.

In other words, in practice it sounds like this should be used more like high-frequency sonar despite the visualizations resembling active radar. With better SNR it might be valuable if the Science radar didn't exist, but between the SNR and lack of tuning parameters it can't be used to plot the position of most entities outside of Science radar range, except for those like planets and nebulae which already appear up on Relay.

I'd reconsider this point on range, in other words. I'm reluctant to dismiss your intent, but in this implementation I'd need to see an active demonstration to understand how it'd be either useful or fun in the context of an EE scenario. I don't think any amount of description in text would communicate it.

Any scenario that involves searching an artifact or following a strange signal can be used with the sensor screen.

If the Sensors screen could demonstrate functionality in Liberation Day without any changes to the scenario, I think it'd be very informative. I'd likewise be curious about @Xansta 's thoughts as the scenario's designer on both the potential effects of a Sensors screen on Liberation Day and the current difficulty without it. (I can't get Liberation Day to run on this branch, so I can't test it on my own.)

Though to be clear, I consider that to be part of my chicken-and-egg point about a lack of signal data implementation and reference throughout EE. The presence of a Sensors screen should result in changes to signal data values on entities, and those changes should be designed around its presence.

My relevant point at the end that you're responding to is more about whether and how Sensors would be useful outside of the context of scenario-specific implementations (which is something I'm wrestling with now with the tractor/utility beam). Does it allow for new ship types and interactions, and how do those enhance, change, or break gameplay in scenarios or freeform GM'd sessions that aren't designed around their existence?

[Ownezx]

Agreed for the slider.

I understand better now, having an active sonar (or A-scan view) is definitely something that could be very interesting for the sensor screen. Having read about A-scans, a nebula could send all your signal back to you actually.

For now I only did a screen that basically is a passive hydrophone because it was the closest to the existing raw sensor data.
Perhaps #2417 gives a clearer idea of the initial scope for this proposal. I am, however, open to ideas and PRs on that test branch.

The sensor screen's in it's current state would for when a target is too far to be on the science radar. Some example could be

• Tracking a freighter we are tasked to escort after it exited science radar range
• Finding an object that has a sensor trace but that is very small and would barely be visible on the science raw sensor data
• Detecting objects within a nebula without having to send a probe into it

For now I would have placed the sensor screen in the extra screens, not putting emphasis on it too much as I would not want it to take too big of a place. I would see it as a screen used by people who have a deep understanding of the raw sensor data system and who would want to push it a bit more.

[Xansta]

So, the fireworks artifact in Liberation Day is specifically designed to be hard to "see" on the Science and Relay screens. I did not make the three (red, green, blue/biological, electric, gravity [no correlation]) minimally registering or anything like that, I just made the radar trace the same color as the background. The fireworks object is very clear when it's in a nebula. It can also be visually identified when it crosses a grid line. Even with knowledgeable science officers, the fireworks object is hard to detect because most Science officers still rely heavily on the radar trace visually pinpointing the location. An extra sensor screen could improve the chances of locating the object, however, since Liberation Day is already crowded with many different objects, picking out the fireworks object would still be a challenge. BTW, locating the object is only the first part of the solution. The crew still has to get through the puzzle associated with discovering the fireworks object's deactivation code.

Something else to consider: On the science screen, you can tell the primary sensor range boundary because it's the edge of the large circle. On the new sensor screen, you're reaching farther, specifically to the limits of the raw data availability. It would be nice to know on the new screen where the primary sensors end and the "stretch" sensors begin. Perhaps another line at the range of the primary sensors similar to what helm/weapons sees when they have two beam weapons with the same arc but different ranges.

[Ownezx]

I agree for the range, if there is agreed potential for integration I would work on the interface for a second iteration. I would likely include a slider for zoom as well as two range indicators for radar and raw radar range.

[Ownezx]

Also, Adding a small gif of how I was intending to use the system to triangulate object position:

[oznogon]

That is helpful. I didn't know what "Link Probe" did in this context, since that's not how probe linking works in the Science/Relay context. "Switch to Probe" or "Probe View" might be clearer.