1. Space Engineers Azimuth Ore Detector
2. Space Engineers Increase Ore Detector Range In Excel

If installed on a Large Ship or Station, the range is 150 meters. The range of the Ore Detector does not stack, just overlaps. The Ore Detector requires 1x1x2 blocks of space. It will attach to other blocks on all faces of its cube-shaped base. The cylindrical half of the detector does not attach to blocks.

First, let me say this is an amazing addition that I think a lot of people would benefit from having in core. There are clear balance implications, but not including the radar block itself gives full control to server admins to include mods that implement this in a balanced way - awesome.

We've been working on implementing radar for a long time in the Autopilot mod, and one of the main hangups has always been displaying the information - since we couldn't add GPS markers, users would have to copy and paste GPS coords from a text panel and manually add them. Now that GPS modding has been enabled we could add/remove them that way. But dedicated HUD markers are a better solution. It's also really nice that implementing this in core means getting a dedicated TerminalPanel.

I have suggestions on both functionality and implementation. I'll start with functionality because it's way more interesting:

• Hello everyone and welcome to the Space Engineers Survival mode. Wrecked ships and their parts Asteroid amount set's the number of asteroid clusters in the world This option can highly increase the amount of ore. But allows you to better explore the asteroids The hand drill is equipped with a short range ore detector that will.
• As far as I can tell from my research, the maximum range of an ore detector is 150m. It won't increase if you add more or anything like that.

Space Engineers Azimuth Ore Detector

Functionality

• Control Names - I would rename some of your control parameters to make better sense to a new user:
  • 'Minimum Size' -> 'Minimum Detectable Size' or 'Minimum Detected Object Size' or 'Minimum Detection Size' - anything to help make it clear that this has nothing to do with detected objects and not the size of your detection sphere
  • 'Maximum Size' - same as above
  • 'Broadcast Using Antennas' -> 'Share Detection Info Via Antennas' or 'Broadcast Detected Entities' or something to help clarify that this has nothing to do with the radar signal. Also, I'm not sure where Keen lands on 'Antennas' vs 'Antennae'.
  • 'Tracking Limit' -> 'Max Entities Displayed' or 'Shown', something that helps clarify this has nothing to do with the tracking angle of the radar signal
• Signature Algorithm - in order of how important I think they are:
  • Detect other radar signals - In real life, the easiest way to give away your position to a radar installation is by running radar of your own, or any particularly noisy electromagnetic signal. I think this should be an element of the detection algorithm that's much stronger than size, and preferably can be exposed to the GUI / via the results method.
  • Tech Level - Building on the above, there are a lot of implementations of radar, some much more sophisticated than others. Generally there's tiers of technology that can detect everything earlier than them but hide from similarly advanced methods (I'm thinking Passive and Active Phased Array here). I would suggest implementing this as a simple 3 tier system - 0,1,2 - and making it an attribute of the block definition. So if you have a radar level 0 block, you can detect other radar level zero. If you have a 1, you can detect 0 and 1. If you have 2, you can detect 0 and 1 (like in real life) or 0,1, and 2.
  • Jamming - The logical opposite of other signals making it easier to detect, you would have a Radar Jamming (or even all communications jamming eventually) block that would make it harder to detect its grid and nearby objects. This would probably be easiest to implement after you'd done the nearby object check here.
  • Orientation - A single radar block should have a semi-circle of detection at best. Many of the largest, most powerful radar systems are actually uni-directional. Many modern military bases have giant passive phased array dishes installed on each side. I would recommend allowing the block definition to define angle limits like turrets have, then reading these and comparing against the angle to a detected object.
  • Object curvature - Eventually you could take into account the curvature of the vessel using some real radar maths. This could be cached for a long period of time, it only really needs to be updated when there's a lot of building going on on the object, and then it can wait some frames to see if more building is occurring. This is probably the least important feature I'm mentioning and some of the most work. It'd just be real cool.
• Detected Entities
  • Show enemies first - Currently this just shows the biggest X entities, but enemy entities are far more important to know about than neutral and friendly. I'd suggest you sort it enemy, neutral, friendly assuming that neutral and friendly parties would have updated your system with enough info to distinguish between them and enemies. If that's too much of a logical leap, we should at least avoid showing markers for entities we already have HUD markers for.
  • Show signature size on HUD Marker
  • Remove old markers - it looks like these don't get removed from the targets_cache, and thus not the HUD, until they're replaced with more recent entries. I could be reading that incorrectly though.
• API access
  • Expose signature size and position of detected entities to modders and in-game scripts

Implementation

• Magic Numbers - there's a lot of them. These should be moved to constants declared at the beginning of the class or namespace.
• Unlimited constants - The value used to identify 'unlimited' for object tracking size and displayed entity count should probably be 0 or a negative number instead of a positive one. Using a positive number limits modder's ability to actually increase past that amount.
• Size Signature - it looks like your current implementation is a simple step function. We've got a nice way of doing this via a continuous function in Autopilot
• Bug in nearby-object detection - It seems like this compares each object to the next largest object and finds if its close, great. But it should drop the object at index j, not index i.
• Bug in entity broadcasting - it looks like this uses the terminal block's position, it needs to use that of the radar it's querying and really should just share what radar already has cached
• Performance - Have you done any profiling of this? I know anything that gets a list of entities in a sphere is usually moderately expensive, especially if it's a big sphere. I'm not great at understanding logic flow in this game yet - does this run everywhere at once, or can it run the only on the client who needs to consume the information? I can see having to run the radar detection for my own ships as well as those of everyone else on my server being as CPU-intensive. Could we delay it to run every 300 frames or so more?

Again, awesome PR and I'm happy to help groom this up. I wanted to run this all by you and the community first though.

Space Engineers Increase Ore Detector Range In Excel

Also FYI, when you make changes to this branch you don't have to open a new PR, just push your commits to the same branch. Even if you change the commit history via a rebase or squash, you can just do git push -f.