#2083 broken radar for mp planes

[jean pellotier]

the radar in the mp planes properties doesn't work anymore, all radar props keep a steady "0" as value.

this make mp refueling impossible as the contact never come to 'true' in "refuel"
from the tests, in AIModel/AIMultiplayer.cxx, in the tanker code, isTanker ( tied to ai/models/multiplayer/tanker) and range_ft2 ( "double range_ft2 = UpdateRadar(manager);" ) are working fine, but y_shift and elevation (pointing to radar/x-shift and radar/elevation-deg ) are allways 0, preventing refuel contact.
setting those two to 1 make it work again
you can try this on ground with the 707-TT and a plane refuelable, (i use the F-4N here) and just toggling the refuel boom/drogue trigger the tanker property needed.
this worked fine as late as the 27 july 2018 (did a check with e43fe8209 as it was a suspect :) )
this break 2018.3 and next, the only branchs i tested ...

the ai tanker works fine ...

[jean pellotier]

the commit involved seems to be:
ef98b667b473fdbb02600d

the trouble is that's only if the mp plane is close when it join, for mp planes far enough, the radar work as they come in the properties.
something to do with the loading of the 3d model ?
in fact it only work if the mp plane is far, cloder than 44nm and the radar stop working ...

[Anonymous]

What is "radar" properties? There is no mention of it in src/MultiPlayer/multiplaymgr.cxx...

[Stuart Buchanan]

Jean is referring to AIMultiplayer.cxx around line 528, which determines whether there is contact:

    if ( isTanker) {
        //cout << "IS tanker ";
        if ( (range_ft2 < 250.0 * 250.0) &&
            (y_shift > 0.0)    &&
            (elevation > 0.0) ){
                // refuel_node->setBoolValue(true);
                 //cout << "in contact"  << endl;
            contact = true;
        } else {
            // refuel_node->setBoolValue(false);
            //cout << "not in contact"  << endl;
            contact = false;
        }
    } else {
        //cout << "NOT tanker " << endl;
        contact = false;
    }

AIBase.cxx binds these to properties as follows on line 655:

   tie("radar/elevation-deg", SGRawValuePointer<double>(&elevation));
    tie("radar/range-nm", SGRawValuePointer<double>(&range));
    tie("radar/h-offset", SGRawValuePointer<double>(&horiz_offset));
    tie("radar/v-offset", SGRawValuePointer<double>(&vert_offset));
    tie("radar/x-shift", SGRawValuePointer<double>(&x_shift));
    tie("radar/y-shift", SGRawValuePointer<double>(&y_shift));

[jean pellotier]

the refueling stuff is just a side effect wich made me find this, you don't need to use a tanker to see if it works, just log with a plane using the radar, and check if the radar work for mp player close to you.
Maybe Richard got clues about this, btw i didn't try the latest next from today if by chance it's solved ?

[Stuart Buchanan]

On next today, I've just had a go with an A4F and the KC-10A and the radar properties seem to be fine, even having the model swap between the real model and the glider.

However, I don't see any fix from Richard today.

Do you see the problem on next?

-Stuart

[jean pellotier]

i don't see the problem with other planes (tried the f-14a and the a4f and both went fine) on next.

a change of range in the config file:

<instrumentation>
...
<radar>
<range type="int">10</range>
</radar>
...
</instrumentation>
change the distance where it stop working, looks like it work only if out of range.

maybe the F-4N don't use the same radar as the other planes ?

i think the radar code rewrite wich took place in ef98b667b473fdbb02600d make it work in reverse, but it's too late now for a check :)

[jean pellotier]

got it working again, here's the diff:

diff --git a/src/AIModel/AIBase.cxx b/src/AIModel/AIBase.cxx
index e214d01..58d99fc 100644
--- a/src/AIModel/AIBase.cxx
+++ b/src/AIModel/AIBase.cxx
@@ -731,7 +731,7 @@ double FGAIBase::UpdateRadar(FGAIManager* manager)
     double dFt = d * SG_METER_TO_FEET;
     in_range = (d < radar_range_m);

-    if (!force_on && in_range) {
+    if (!force_on && !in_range) {
         return dFt * dFt;
     }

in the initial code, we had

if (!force_on && (d2 > radar_range_m))

replaced with :

 in_range = (d < radar_range_m);

 if (!force_on && in_range)

the initial test was true if not in range ...

[James Turner]

Ah this is my fault, good catch indeed.

[James Turner]

Fixed in ff760e3d962459c44f390de7cb52d1c65d1c27a5 on 2018.3 and 31f8f86e1288be671c93e48fe0464aeb87836e8a on next. Thanks!