Hi there.
Finally the red NAV flag in RNAV mode is gone!
The conflict was in some other place, but the truth is that the problem with NAV1_IN_RANGE condition has led me to pinpoint where the problem was. Diving into the KNS80.nas file, I couldn't find any other reason that caused the red NAV flag being there every time the RNAV mode was activated, so I reviewed again the other file defining the KNS80 (kns80.xml).
There, in the kns80.xml (in Patten’s Aerostar is in /wherever you have your additional aircraft folder/Aerostar-700/Models/Instruments/kns80”) I saw that in the the Nasal script governing the RNAV.btn object there was a ‘}’ that was closing the (test!=2) condition before setting the property to slave the NAV to the GPS and, therefore, executing this every time and thus making the RNAV of the KNS80 to ALWAYS be slaved to the GPS. That‘s a bug, isn’t it?
The same applies for the kns80.xml in the other affected airplanes’ trees (Ryan-Navion, Lancair-235,etc.), and for the kns80.xml in the MAIN FG INSTALLATION DIRECTORY (in my version – Ubuntu PPA FG 2018.2.1): /usr/share/games/flightgear/Aircraft/Instruments-3d/kns80.
The solution is simple. First KEEP the condition affecting NAV1_IN RANGE in its original form inside KNS80.nas (IT HAS TO BE WHERE IT WAS). The same goes for kns80.nas as well in ITS ORIGINAL form. I just reproduce the one in KNS80.nas here:
- Code: Select all
updateRNAV : func{
if(!me.NAV1_IN_RANGE.getValue()) {
return;
}
then, in kns80.xml, just move the curly bracket to make the property that slaves the NAV to the GPS be INSIDE the conditional:
There it is:
--For the RNAV mode--
Original WRONG kns80.xml (RNAV.btn):
- Code: Select all
<animation>
<type>pick</type>
<object-name>RNAV.btn</object-name>
<action>
<button>0</button>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>
var test = getprop("/instrumentation/kns-80/nav-mode");
if(test != 2){setprop("/instrumentation/kns-80/nav-mode",2);
}else{setprop("/instrumentation/kns-80/nav-mode",3);}<!-------problem here-->
setprop("/instrumentation/nav/slaved-to-gps", 1);
</script>
</binding>
</action>
</animation>
Corrected kns80.xml (RNAV.btn):
- Code: Select all
<animation>
<type>pick</type>
<object-name>RNAV.btn</object-name>
<action>
<button>0</button>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>
var test = getprop("/instrumentation/kns-80/nav-mode");
if(test != 2){
setprop("/instrumentation/kns-80/nav-mode",2);
}else{
setprop("/instrumentation/kns-80/nav-mode",3);
setprop("/instrumentation/nav/slaved-to-gps", 1);
}
</script>
</binding>
</action>
</animation>
However, the VOR/PAR mode still needs to be corrected since the red NAV flag keeps coming alive there.
Haven’t found the solution yet, but if the property to slave nav to gps is commented out in the VOR.btn object the problem is gone, so it must be over there as well. Any one sees something?
Original xml80.xml (VOR.btn):
- Code: Select all
<animation>
<type>pick</type>
<object-name>VOR.btn</object-name>
<action>
<button>0</button>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>
var test = getprop("/instrumentation/kns-80/nav-mode");
if(test != 0){
setprop("/instrumentation/kns-80/nav-mode",0);
setprop("/instrumentation/nav/slaved-to-gps", 0);
}else{
setprop("/instrumentation/kns-80/nav-mode",1);
setprop("/instrumentation/nav/slaved-to-gps", 1);
}
</script>
</binding>
</action>
</animation>
UPDATE: if the slaved-to-gps property affecting mode 1 (VOR/PAR) is either commented out or edited to be 0, the red NAV flag also dissapears in VOR/PAR mode. Don't know if is a solution though. It just behaves like that. Below is the edited code for VOR.btn in kns80.xml:
- Code: Select all
<animation>
<type>pick</type>
<object-name>VOR.btn</object-name>
<action>
<button>0</button>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>
var test = getprop("/instrumentation/kns-80/nav-mode");
if(test != 0){
setprop("/instrumentation/kns-80/nav-mode",0);
setprop("/instrumentation/nav/slaved-to-gps", 0);
}else{
setprop("/instrumentation/kns-80/nav-mode",1);
setprop("/instrumentation/nav/slaved-to-gps", 0);
}
</script>
</binding>
</action>
</animation>
Anyway, as a temporary solution, if someone doesn’t want to slave nav to GPS at all, simply comment out any reference to that property both in VOR.btn and RNAV.btn, and the problem with the red NAV flag would be gone for good.
Corrected kns80.xml -slaved-to-gps- commented out:
- Code: Select all
<animation>
<type>pick</type>
<object-name>VOR.btn</object-name>
<action>
<button>0</button>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>
var test = getprop("/instrumentation/kns-80/nav-mode");
if(test != 0){
setprop("/instrumentation/kns-80/nav-mode",0);
<!-- setprop("/instrumentation/nav/slaved-to-gps", 0);-->
}else{
setprop("/instrumentation/kns-80/nav-mode",1);
<!-- setprop("/instrumentation/nav/slaved-to-gps", 1);-->
}
</script>
</binding>
</action>
</animation>
<animation>
<type>pick</type>
<object-name>RNAV.btn</object-name>
<action>
<button>0</button>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>
var test = getprop("/instrumentation/kns-80/nav-mode");
if(test != 2){
setprop("/instrumentation/kns-80/nav-mode",2);
}else{
setprop("/instrumentation/kns-80/nav-mode",3);
<!-- setprop("/instrumentation/nav/slaved-to-gps", 1);-->
}
</script>
</binding>
</action>
</animation>
NOTE: because of the ‘slaved-to-gps’ property, if anyone tried the KNS80 Pilot’s Guide flight from KMCI to KMEM planning the flight in the route manager AND with the flightplan ACTIVATED, the perception would have been that the KNS80 was working properly, without being so.
I‘ll keep trying to solve the VOR/PAR mode NAV flag anyway.
However, now that the red NAV flag is not there anymore in RNAV mode, there are some -until now- hidden problems that have aroused and that need to be solved. Just to mention one of them for the moment: the CDI doesn't point to the phantom station (waypoint) but to the actual DME station as in VOR mode--
EDITED--> so there is no way to know when we are passing over our waypoint, since the TO-FROM flags will be linked to the real VORTAC station, nor our linear deviation from the waypoint.
More next time.
Jogois