Proximity sensor

[Lurkily]

I'd like a sensor for distance.  Distance to the nearest terrain, distance to the nearest enemy, nearest ore, distance to Nimbatus, distance to the dropoff site.  I'd also REALLY like to be able to get the distance to a specific block - either another paired distance sensor, or just a block you specifically select in the construction menu, whichever.

EDIT: Merged these topics.  I thought I had seen more of them, but it must have come up in the discussion of other ideas.  But while I have them both open, I might as well.  As ManTheMister said, something that works like an altimeter, but tuned to selectable targets (Such as drone core, planet core, and other already extant targets) would be fantastic; and could even serve to obsolete the altimeter.

I meant to merge mine into yours; it looks like I did the reverse.  Sorry about that.

[Lurkily]

Absolutely 100% in favor of this, all of it. 

[Lurkily]

If you're right, and I always suspected that it's so, I'll leave it for the devs to reject it, and be content.  But the whole point of this tracker is to provide them feedback on what's important to the community, not what the community thinks is easy.

[ManTheMister]

Works much like the altitude sensor, it gives an output if something is farther/closer to it than a set distance. but you can set what it looks for. If there are multiple things that it can detect (such as enemies) it only detects the nearest one.

it can detect the sumo enemy, level enemies, the hopper, the sumo border, the center of the planet (this feature is in the altitude sensor already, maybe replace the altitude sensor?), the surface of the planet ( because that would be necessary because absolute distance would be used instead of relative distance and planet sizes differ), the drone core, collectible objects (bio-barrels, broken ship pieces, etc.), beacons when they’re added, and anything else that I forgot to put in this suggestion.

Edited November 14, 2018 by ManTheMister
Add more targets

[ManTheMister]

Beacause terrain isn’t an entity (at least I don’t think it is. It would be very difficult to code it into an entity), I don’t think that it or ore would realistically work in any sensor other than the already existing distance sensor. With entities you just have check which of the specified entity is nearest. With terrain, you would have to check every square unit around the drone, and it would be very heavy on the CPU (at least I think that that’s how it works). Long story short, terrain/ore should only be in the distance sensor, not the proximity sensor/directional sensor.

[Lurkily]

There are a lot of ways to optimize find-nearest problems.  Simple solutions, used in industry today for mapping software (find the three nearest gas stations) is to ask 'do any exist within five miles?'  If yes, find the nearest.  If no, extend the search radius.  If the new search radius contains too much to search, pick a search radius halfway between this and the previous.  The division of many data points into regions also has a number of tricks out there, like spatial trees, and etc.  Not sure that kind of solution would be applicable here, but they are common problems, and solutions are out there.

That said, I'm quite aware that terrain isn't the kind of thing that the game seems to recognize as any kind of target with a discrete location, and I'm aware the engine doesn't seem to differentiate between ore and dirt.  Directional location of ore comes up a LOT, though.  If it's prohibitively difficult or resource-consumptive, I'm okay with that, but in the meantime, I'm still gonna suggest it as something I'd like.

[ManTheMister]

The example you used (gas stations) are only points, not zones. So they would work like entities. Even the largest entity has only one location. Dirt/ore is a zone, drawn in. Not an entity, so detecting either, not even discriminating them, is the dificult part. It wouldn’t be that difficult to discriminate them for distance sensors (they already do it with the harvester).

[Lurkily]

That's why I mentioned the algorithms in use out there for grouping large masses into small, discrete groupings.  Regardless, as I said, if it's prohibitively difficult to code, then I'm good. But I think it's a good idea, so I'll put it out there and vote it up when I see it.

What if it is easier than we expect, and it never gets implemented because the players making suggestions thought "Nah, that's probably hard, let's not ask for that."

[ManTheMister]

I agree that it would be nice to have ore in directional sensors, but ore isn’t just thousands of small, trackable entities. It’s one large, solid mass. The only way that I could think of for finding ore/terrain on a direction sensor would be scanning every pixel in increasingly large circles, Which would be very taxing on the CPU. So methods that maps or similar programs for finding specific locations would not work on terrain or ore.