i would like it not to rename my antenna, showing the sensor on hud works better then it renaming my antenna

That's a misunderstanding. The mod doesn't rename the antenna. It only requires a [radar] tag on the beacon (was that what you meant?). The mod also doesn't require an antenna, just a beacon, and it will still update the sensor.

The antenna is renamed by my example in-game script. If you're just viewing the coordinates yourself, then don't use the in-game script and use the show on hud option for the sensor like you suggested (I do that myself when I just want to view the coordinates). You don't even need a Programmable Block for that. The point to the script was to show how to access the coordinates reported by the sensor using in-game script. Once you have the coordinates in script, you can do anything you like with them in that script. I chose to rename the antenna, but that was just an example.

If you were talking about having to rename the beacon to include the tag [radar], that was a game/mod design decision. I could have designed the system to just update all radar sensors without any beacon involved, but chose to have a beacon involved for the power and component requirements and to advertise the use of radar. From the design perspective, it is the sensors that are superfluous. They are a technical necessity, however, since I needed to get type settings from somewhere and I needed to report the coordinates somewhere. I could have done both in the beacon's name, but using sensors provides the ability to report multiple types of signals at once under the current constraints (what I can and can't do with the mod API). All in all, I thought it was a good compromise.

Those are probably ideas for completely new mods but they are very related:
As you probably know i wanted (and did) make a torpedo. It worked quite well. I thought of clever ways to mark a target using some pointing device on the main ship and then starting a torpedo using the marked position as target. The first problem is: It is difficult to configure the radar to a specific target at an approximate position. So if i have a position where a target is, how should i tell the radar to track this specific one. You could add a feature so that the radar wont detect the closest things to itself but instead the clothest things to a user configured point (still in range of the radar of course). For target marking i came up with two main ideas that would need some modifications (new mods):
- a rangefinder that detects the distance to an object in front of it (only in that direction). One could build a pointing device so that you can mark a specific 3d point in a direction.
- the radar could obivously also be used for that and all of the 20 targets could be checked if they are in line of sight. But in combat there is a lot of trash from detroyed objects, so the radar would give up very early, because 20 targets are pretty fast reached. A directional radar would filter most things that are not of interest because it only works in a specific direction, which would make it very similar to the rangefinder i guess ^^

To sum it up:
- More control over which target to track and where to search for it.
- A way to limit the radar or another device that is limited on its own, so things can be precisely tracked without other things interfering.

@cookiehunter:

That's an interesting idea. How about a flag on the sensor that will pick the target that is closest to the sensor's forward vector? Once it has a target, it can be locked with the existing + flag. Will that suffice? I'm already implementing a feature that will report spherical coordinates (including radial distance) rather than cartesian coordinates. I've also been considering a feature that would only select targets with a certain number of blocks.

Yep, the thing with the forward vector is a great idea. Also block count would help. One thing is left unsolved though. I select a target using my pointing device (using a radar with the forward vector thing). That way i have a position. Now i want to start a torpedo that follows this target. The torpedo obviously has a normal radar. It has to be possible to configure the radar on the torpedo so it tracks an object at a certain position (position acqiured by pointing device). Obviously one could check all 20 targets that the torpedo detects and use the one that is closest to the given position, but there is the possibility the target that is marked, isnt one of the 20 closest objects. As i said in my previous post it would be nice to select the origin the radar uses to determine the closest object. So if i have my marked position, i would set my radar to this position as origin. The closest object the radar detects will then be the closest object to the marked position. This wont effect radar range or the origin of the radar coordinate system. It would just change the definition of "closest object".

Oh, I see. Because you need to detect the target on one cube grid (a ship or station), but then seek it with another (the torpedo). Hmm... that actually isn't too far from what it does now when locking targets. The only real difference is that the sensor would be on a different cube grid. Same owner. But how to match them with one another?

Right now, I think it would be a bad idea because I am using a game logic component on the beacon to implement the radar. When I switch to using a session component, it should be straightforward. I've been intending to do that, but it's a larger change, so I don't know when I'll actually get around to it. I think sometime in the next couple weeks though, unless I get swamped with school work. I'm trying to make progress on my AutoDrone mod as well.

Err... or maybe look to see if coordinates are on the radar beacon itself and use those... that could be done a lot sooner. Sorry, I'm thinking out loud. I think I'll do that (allow coordinates to be placed on the beacon), but not right this minute. Later today perhaps.

Cool! I really want to thank you for youre effort to integrate my suggestions and i am looking forward to the upcoming features. But you dont have to hurry. I dont want to occupy all youre time for that. And always remember: shool is important :D

Is there a way to ignore contacts on the same grid ? If you have rotors and/or pistons your ship/station will be made of more than one entity. Best way would be to find out if the entity is connected to the one with the radar but I didn't find such info in the Entity or Entities classes. Doesn't mean it doesn't exist there, though.

There is no way through either the IMyEntity or IMyEntities interfaces. In fact, the only way I've found to do it is through the object builders. I've actually already written the code, which I plan to include in the next version of the Radar mod and the first truly working version of my AutoDrones mod. I used a fixed-point algorithm to trace all the connections and group grids into ships. This is as efficient a way as I could find to deal with many ships, which both the radar and the drones have to do.

Thing is, I have no idea when I'm going to finish the next version, now that school has started up again and I have other commitments. I guess I could publish my (non-working) work in progress. It has the afore-mentioned routine as part of a base library that I'm using for both mods. I haven't looked at it in a while; I'll see if I can get it in a publishable state.

May I publish a temporary version with my modifications then ? It'll be removed when your next version is finished since I don't want to have a parallel version. This way you could also take a look what I did.
I modified the UpdateSensors function to get more info in the sensor name. This is to reduce the number of required sensors. Introduced coordintate type "a" and radar mode "*" (used as/instead of "+").
[radara] returns all three coordinate types. I would use this for a locked target.
[radar*n] returns all targets beginning with target n.

[radar] returns Rel:NumOfContact<x,y,z>
[radars] returns Sph:NumOfContact<r,alpha,beta>
[radarg] returns GPS:NumOfContact:x:y:z:

The tags in front and ":" I've added for easier text processing. So [radarg*] on all the sensors will return all contacts applying to their filter settings in one long row which can then easily be copied from the first occurence of "GPS:" into a textpanel/LCD. This way all contacts can be easily transferred into the GPS.

Yes, of course. You already have permission with the license I used, so long as you give credit for the original work.

Is there a way to obtain a list of all matches?

I've been wanting a device that I can point at an asteroid and get the distance. So I've put together some rotors and a camera, along with sensor, beacon and progr. block. I can use the camera to point at the asteroid, using the rotors. Then I check the pitch and yaw (I'm using "radars") and if they're close enough to 0 I rename something with the distance.

The problem is it only does this for the closest thing, and that might not be what I'm pointing at. So now I'm renaming the sensor, incrementing it's number to skip the closest matches, so I can check the next. But I have to exit the script to let the mod handle the new sensor config, and rename my sensor. I've made it so that if I run my script 20 times, I'll get the distance to the asteroid I'm pointing at, but I would be really happy if this repetition can be incoorporated into the script..

And for that, I need access to more than one match at a time. Not sure how that would work, unless you put everything into the sensor name.. which is not very desirable.

That's the "*" I've implemented in the modified version of the BlueG radar, see my post above. [radar*] [radars*] [radarg*] and [radara*] are returning all contacts (still up to 20) for the sensor setting used. If you just want to find asteroids then you're lucky because you just need one sensor.
I find the "*" the most useful modification I made, 2nd is the "NumOfContact" to distinguish the returned contact data. Seems you are the next.
Beware that the modified version will be removed so you can use it, but just temporary until BlueG has updated his original.

I had a suggestion, but then I looked at Lynnuxx's post, and saw he beat me to it.
But another one would be countermeasures of some sort. Maybe decoys show up as separate targets with the same ID as the ship it's on?

Originally posted by BlueG:

Oh, I see. Because you need to detect the target on one cube grid (a ship or station), but then seek it with another (the torpedo). Hmm... that actually isn't too far from what it does now when locking targets. The only real difference is that the sensor would be on a different cube grid. Same owner. But how to match them with one another?

Okay, after checking some readily available sources I can give you a little assistance on this.

Real IR missiles use a slaved/independent seeker method of locking targets.
The ship's (yes, fighter pilots actually do call their fighters ships) radar or other cueing system (helmet mounted sight) locks onto (or looks at for the HMS) the target and the seeker of the missile is slaved to look at the same place. When the missile indicates it has locked onto something, the pilot uncages the missile which allows the seeker to operate on its own. If the seeker sticks on the desired target, the pilot knows he's got a good lock and fires the missile.

So what you need is:
Two systems: One for the ship, one for missile.
The missile's system tracks the target locked by the ship's system until you push a button.
Once pressed the missile remains locked onto the target the ship was tracking before it was "uncaged".
Then you fire the missile which tracks onto that target.

Actual radar guided missiles work differently, and would take more time to discuss).

For balance (and realism) these radar antennaes should probably have a limited FOV. Thus a fighter must point it's radar to the enemy to lock the missile. (No radar can/could realistically continuously track all 360 degrees simultaneously.) If you'd like to learn more about radars, I would be happy to help out.