Having a little knowledge of how this mod works may help to get the most out of it. In particular, knowing the order in which updates are performed, as described below.

The radar is implemented as a component of the beacon (like Keen Software's "Sir Beacon" mod). It updates every frame, but may miss frames from time to time. This is due to some part of the game engine that I haven't figured out yet, which, for some reason, occasionally removes the flag to update every frame. This will be fixed at some point in the future when I switch this mod to use a session component instead.

When the game engine first loads, the radar doesn't know of any targets. I have not implemented a feature to save targets with the game yet. On the first frame and every 60 frames thereafter (every second), each beacon with the [radar] tag in its name does as follows:

• It locates all sensors with one of the various forms of [radar] tag and allocates space to store targets for that sensor, unless the sensor has already locked its targets. If the sensor has already locked its targets, then it is skipped.
  
• It goes through every entity that the game has loaded and checks to see if it is in range of the beacon.
  
• Every entity in range is then checked against every sensor to see if it is a valid target for that sensor.
  
• If it is a valid target and the sensor does not already have 20 targets, then it is added to that sensor's list of targets.
  
• If the sensor already has 20 targets, then it is checked against the existing target furthest away and, if it is closer, replaces that target.

Then, every frame (including frames where the radar updates its targets), the following occurs:

• The radar sorts the targets for every sensor that has not locked its targets. Notice that this means that the order in which the targets are indexed for locked sensors does not change.
  
• The appropriate target is selected according to the index number in the sensor's [radar] tag (e.g. [radar1] or [radar+1] will select the second closest target rather than the closest).
  
• The sensor's name is tagged with a vector containing the target's coordinates relative to the sensor. Notice that even if the sensor has locked its targets, a different target from among its locked targets can be selected. If the slot in question had no target (there weren't enough targets or the target that should be there was destroyed), then the sensor name will not be tagged with a vector.
  
• If the sensor is flagged to lock its targets (it has the + sign in its name), then it does so. The set of targets that it is tracking and their indexes will not change. If one of those targets is destroyed, that slot will become empty and will not display a vector when selected.

And... that's it. I hope this will help at least some of you.

Additional info as posted with the example missile/torpedo:
In order to detect enemies the ownership settings have to be
- for the beacon: "Me" with any of the other three specific settings
- for the sensor: "Me" with "No share" or "Share with my faction"

Ah, so that's what was going on with you. Yes, you are correct. That's because there are two relationships at work here.

One is the relationship between the sensor's owner and the detected item's owner. This should be the same as for a sensor that isn't using radar (a vanilla sensor). So, if it isn't owned by someone, then it is considered friendly to everyone.

The other relationship at work is the relationship between the radar (the beacon) and the sensor. Sensors are only updated by radars (beacons) that are friendly to them. Which means, in addition to being updated by radars belonging to you, they should also be able to be updated by radars belonging to a faction member, but I haven't tested that because my ability to test multiplayer (and factions in particular) is somewhat limited =p.

In [1.067.007] the sensor has to be switched on to be updated, it seems. Or since the last update of this mod ;-)