• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSXA COM tune without battery

Not good :mad: Please look at the picture I've made with the help of BlackBox.

(L:com_khz,number) 0.025 - 1 % (>L:com_khz,number)

Supposed that the com_khz variable equal to 0.000, the result of the calculation sholuld be 0.975. Isn't it ?



attachment.php
 

Attachments

  • LUN.JPG
    LUN.JPG
    174.8 KB · Views: 885
I found something on this forum that will be usable, I hope :rolleyes:
It will work. That is the exact script I'm using. There are 40 possible "fractional frequencies" which is why the range for the L:var tuning variable is 0 to 39.

Similarly, there are 19 possible "whole" frequencies, so the range there is 0 to 18.
 
Bill,

in that code you count L:B737_Com1Stby_WHOLE_TUNE from -1 to +19, then you change -1 to +18, and +19 to 0. You calculating similar with the decimal variable. What's the reason of this?

Code:
(L:B737_Com1Stby_WHOLE_TUNE,enum) 19 == 
             if{ 0 (>L:B737_Com1Stby_WHOLE_TUNE,enum) }

(L:B737_Com1Stby_WHOLE_TUNE,enum) -1 == 
    if{ 18 (>L:B737_Com1Stby_WHOLE_TUNE,enum) }
 
Bill,

in that code you count L:B737_Com1Stby_WHOLE_TUNE from -1 to +19, then you change -1 to +18, and +19 to 0. You calculating similar with the decimal variable. What's the reason of this?

Ah, that's to prevent "runover" when reaching either the changeover from 0 to 18 or from 18 to 0...

The thing with "mouse stuff" is that until the "click" happens, no evaluation of the variable has occurred yet, so undesired things happen at the changeover point.

Let's look at a count down scenario. When we reach 0, we want the next "click" to go to 18, so unless we check for -1, we won't be able detect the changeover to 18...

Similarly, when counting up, we need to check for 19 rather than 18, because if we reach 19 we want to changeover to 0 again...

Make any sense?
 
You explained it f...ing good :D Thank you Bill !

For the MHz setting I don't need changeover, because the dial stops at 118 downwards, and 136 at upwards, so my code is simply :

Code:
 (M:Event) 'WheelDown' scmi 0 == if{ (L:com_mhz,number) -- 0 max (>L:com_mhz,number) }
(M:Event) 'WheelUp' scmi 0 == if{ (L:com_mhz,number) ++ 18 min (>L:com_mhz,number) }
           
118 (L:com_mhz,number) + (L:com_khz,number) +
100.001 * 10000 % int 
d 10 % r 10 / int 
d 10 % r 10 / int 
d 10 % r 10 / int 
16 * + 
16 * +
16 * + 
(>K:COM_RADIO_SET)

One more thing I'd like to solve : when the radio tuned by the ATC menu in FS, and after that I tune it with its knobs, the tuning will be continued the frequency which was tuned before the ATC menu, but I want to tune from the actual frequency everytime. It is understandable what I scrubbling? :o

PS : other peoples used to make so many problem with the xml-coding or am I the only abnormal guy? :D
 
I haven't had to do anything to the B737-200 script to ensure continuity of tuning...

...however if you do need to do that, it requires a bit more effort. I have an invisible "logic gauge" that performs that chore. This example is from the T-38A.

First, we need to set up a slight "delay" in the script to allow one to use the knobs to tune directly. In the mouse section for our knobs we initialize our flag variable for a 2 second delay:

Code:
(P:local time, seconds) 2 + (>L:T38_Com_MouseActive,enum)

If the frequency "tuned" is different from the actual frequency in the sim, once the delay has expired, we need to read the sim's frequency and use it to reset our knob L:variables.

Code:
    <!-- INTRODUCE SLIGHT DELAY TO ALLOW FOR DIRECT ENTRY FROM KNOBS -->
    (L:T38_Com_CompleteFreq,enum) (A:COM1 ACTIVE FREQUENCY,Mhz) !=
    (L:T38_Com_MouseActive,enum) (P:local time, seconds) &gt;
    and
    if{ }
    els{
    @ExtDigit((A:COM1 ACTIVE FREQUENCY,Khz),6,0) (>L:T38_Com_100_TUNE,enum)
    @ExtDigit((A:COM1 ACTIVE FREQUENCY,Khz),5,0) (>L:T38_Com_10_TUNE,enum)
    @ExtDigit((A:COM1 ACTIVE FREQUENCY,Khz),4,0) (>L:T38_Com_1_TUNE,enum)
    @ExtDigit((A:COM1 ACTIVE FREQUENCY,Khz),3,0) (>L:T38_Com_10ths_TUNE,enum)
    @ExtDigit((A:COM1 ACTIVE FREQUENCY,Khz),2,0) s0
    l0 0 == if{ 0 (>L:T38_Com_100ths_TUNE,enum) }
    l0 2 == if{ 1 (>L:T38_Com_100ths_TUNE,enum) }
    l0 5 == if{ 2 (>L:T38_Com_100ths_TUNE,enum) }
    l0 7 == if{ 3 (>L:T38_Com_100ths_TUNE,enum) }
    }
 
Last edited:
I haven't had to do anything to the B737-200 script to ensure continuity of tuning...

It's interesting, because in my plane when I first load it, and click the COM radio knobs for the first time, it's jumps to the "zero" position everytime, namely to 118.000Mhz :confused:

In your code @ExtDigit is a macro, as I think, which pick out the digits from the frequency(?) Do I need to put in this macro somewhere or it is the part of the plugin?
 
It's interesting, because in my plane when I first load it, and click the COM radio knobs for the first time, it's jumps to the "zero" position everytime, namely to 118.000Mhz :confused:

In your code @ExtDigit is a macro, as I think, which pick out the digits from the frequency(?) Do I need to put in this macro somewhere or it is the part of the plugin?

That is a macro which is explained in this Wiki article: http://fsdeveloper.com/wiki/index.php?title=XML:_Macros_-_Extracting_Digits

However, I think your problem is different than what I initially thought because of your latest explanation...

You need to read the current COM and/or NAV frequencies when first loading the aircraft so that the displays will be correct!

I do this in an "initialization" routine (can be a gauge or a "logic poly" in the model). Because I am only having to 'custom tune' the COM1 and COM2 standby frequencies, this is the script I use. This obviously is only run once:

Code:
    <!-- SET COM1 STBY RADIO BASE FREQUENCY -->
    (A:COM STANDBY FREQUENCY:1,Mhz) 999.999 min 0 max 100 % 10 / flr (>L:B737_Com1Stby_10_TUNE,enum)
    (A:COM STANDBY FREQUENCY:1,Mhz) 999.999 min 0 max 10 % flr (>L:B737_Com1Stby_1_TUNE,enum)
    (A:COM STANDBY FREQUENCY:1,Mhz) 10 * 99999.999 min 0 max 10 % flr (>L:B737_Com1Stby_10ths_TUNE,enum)
    (A:COM STANDBY FREQUENCY:1,Mhz) 100 * 0.1 + 10 % flr (>L:B737_Com1Stby_100ths_TUNE,enum)
    (L:B737_Com1Stby_10_TUNE,enum) (L:B737_Com1Stby_1_TUNE,enum) + (>L:B737_Com1Stby_WHOLE_TUNE,enum)
    (L:B737_Com1Stby_10ths_TUNE,enum) (L:B737_Com1Stby_WHOLE_TUNE,enum) + (>L:Com1StbyDecimal,enum)
    118 (L:B737_Com1Stby_WHOLE_TUNE,enum) + (L:Com1StbyDecimal,enum) +
    100 * 10000 % int d 10 % r 10 / int d 10 % r 10 / int d 10 % r 10 / int 16 * + 16 * + 16 * + (>K:COM_STBY_RADIO_SET)

    <!-- SET COM2 STBY RADIO BASE FREQUENCY -->
    (A:COM STANDBY FREQUENCY:2,Mhz) 999.999 min 0 max 100 % 10 / flr (>L:B737_Com2Stby_10_TUNE,enum)
    (A:COM STANDBY FREQUENCY:2,Mhz) 999.999 min 0 max 10 % flr (>L:B737_Com1Stby_2_TUNE,enum)
    (A:COM STANDBY FREQUENCY:2,Mhz) 10 * 99999.999 min 0 max 10 % flr (>L:B737_Com2Stby_10ths_TUNE,enum)
    (A:COM STANDBY FREQUENCY:2,Mhz) 100 * 0.1 + 10 % flr (>L:B737_Com2Stby_100ths_TUNE,enum)
    (L:B737_Com2Stby_10_TUNE,enum) (L:B737_Com2Stby_1_TUNE,enum) + (>L:B737_Com2Stby_WHOLE_TUNE,enum)
    (L:B737_Com2Stby_10ths_TUNE,enum) (L:B737_Com2Stby_WHOLE_TUNE,enum) + (>L:Com2StbyDecimal,enum)
    118 (L:B737_Com2Stby_WHOLE_TUNE,enum) + (L:Com2StbyDecimal,enum) +
    100 * 10000 % int d 10 % r 10 / int d 10 % r 10 / int d 10 % r 10 / int 16 * + 16 * + 16 * + (>K:COM2_STBY_RADIO_SET)
 
Last edited:
Yes ! I made the same code, but I put it into the <CallbackCode> part of the knobs - which obviously will not work :rolleyes:
 
It is possible that there is some delay refreshing the model in FS when I reload it with "Reload user aircraft" option or I gone mad ? :D I worked on other things than COM radio on my plane, but after some reload, the radio worked completly different than before, but I did not touch the code :confused:
 
Unfortunately, L:vars will always initialize to zero (0) when using "Reload User Aircraft," and worse still any 'initialization routine' you have in place to overcome this will not be (re)executed. :mad:

That's why any such things that need to be set correctly while TESTING the project I duplicate in the <Update> section of a logic script within a one-second timer loop. Once the TESTING is completed and ready for release, I remove the script in the <Update> section as it's no longer needed:

Code:
  <!-- SECONDARY INIT SECTION TO DO ONCE ON A/C LOAD! -->
  (L:T38_Init2,bool) 0 ==
  if{
  15.5 (>L:Buffet_P1_Start,enum)
  17.0 (>L:Buffet_P1_End,enum)
  20.0 (>L:Buffet_P2_End,enum)
  1 (>L:T38_Init2,bool)
  }
  <!-- END SECONDARY INITIALIZATION -->

  <Update Hidden="Yes">
    <!-- COPY TO MODELDEF.XML INIT SECTION WHEN COMPLETED! -->

    <!-- 1 SECOND UPDATE -->
    (P:Absolute time,seconds) 1 % 1 > !
    if{

    15.5 (>L:Buffet_P1_Start,enum)
    17.0 (>L:Buffet_P1_End,enum)
    20.0 (>L:Buffet_P2_End,enum)
      }
 
Last edited:
If you want your custom knobs to respond to external frequency changes, then you need to constantly test if your custom L: variables are equal to the frequency A: variable. If they are different, then you need to increment your L: variables appropriately.
 
Now it works ! That was the code that Bill showed me some days ago :

Code:
<CallbackCode>
(M:Event) 'WheelUp' scmi 0 ==   if{ (L:khz,number) ++ 40 min (>L:khz,number) 1 (>L:lun_khz_hang,enum) }      
(M:Event) 'WheelDown' scmi 0 == if{ (L:khz,number) -- -1 max (>L:khz,number) 1 (>L:lun_khz_hang,enum) } 

(L:khz,number) 40 == if{ 0 (>L:khz,number) }
(L:khz,number) -1 == if{ 39 (>L:khz,number) }
           
(L:khz,number) 0.025 * (>L:com_khz,number)

118 (L:com_mhz,number) + (L:com_khz,number) +
100.001 * 10000 % int 
d 10 % r 10 / int 
d 10 % r 10 / int 
d 10 % r 10 / int 
16 * + 16 * + 16 * + (>K:COM_RADIO_SET)      
</CallbackCode>

I made a BlackBox panel to see what happens behind the scenes. Every time when L:khz,number comes to value '40', the line (L:khz,number) 40 == if{ 0 (>L:khz,number) should change it to '0' but I saw the following order while tuning : 0.950...0.975....1.000...0.025...0.050 and so on. In this case the tuning of the kHz will stepping the MHz freq by one because the kHz value will reach 1.000. It is completely wrong. But I start thinking how can I avoid that jump to 1.000, and I found out this modification in the code, which solved this fault :

Code:
(L:khz,number) [COLOR="Red"]39 >[/COLOR] if{ 0 (>L:khz,number) }
 
Hi,

Yes, in many cases limit testing is better than testing an exact number. :)
 
One of the most perverse idiosyncracies of FSX is that according to ACES themselves, "the only guaranteed value for L:variables is zero..."

It is frustrating when your expected value of 1 turns out to be 0.99999998 or even 1.0000001... :mad:
 
Here are the final codes for my COM radio, maybe somewhere in space or in time somebody will looking for some similar :D With this I can tune independently from battery state, the tuning will be continuous from any tuned ( i mean actual) frequency, tuning of kHz will NOT stepping the MHz. The MHz value stops at 118 and at 136, the kHz value hasn't end positions, it can be tuned around and around. Just like in the real plane ! For displaying the frequency I use only two "stripes", one goes from 118 to 136, stepping by one, other one goes from .000 to .975 stepping by .025. Thank you gusy all your comments and help !

The MHz knob :

Code:
 <PartInfo>
 <Name>gomb_com_MHz</Name>
  <AnimLength>180</AnimLength>
    <Animation>
      <Parameter>
        <Code>(L:com_mhz,number) (A:COM ACTIVE FREQUENCY:1, MHz) 118 - int  != 
               if{ (A:COM ACTIVE FREQUENCY:1, MHz) 118 - int (>L:com_mhz,number) }   
                   (A:COM ACTIVE FREQUENCY:1, MHz) 118 - int 10 *
       </Code>
      </Parameter>
   </Animation>
    <MouseRect>
     <Cursor>hand</Cursor>
     <TooltipText>COM Freq - %((A:COM ACTIVE FREQUENCY:1, MHz))%!3.3f!MHz</TooltipText>
      <MouseFlags>WheelUp+WheelDown+LeftSingle+RightSingle</MouseFlags>
      <CallbackCode>
       
      (M:Event) 'LeftSingle' scmp 0 ==   
      (M:Event) 'WheelDown' scmi 0 == or
      if{ (L:com_mhz,number) -- -1 max (>L:com_mhz,number) 1 (>L:lun_mhz_hang,enum) }
     
      (M:Event) 'RightSingle' scmp 0 ==   
      (M:Event) 'WheelUp' scmi 0 == or
      if{ (L:com_mhz,number) ++ 19 min (>L:com_mhz,number) 1 (>L:lun_mhz_hang,enum) }

      
      118 (L:com_mhz,number) + (L:com_khz,number) +
      100.001 * 10000 % int d 10 % r 10 / int d 10 % r 10 / int d 10 % r 10 / int 16 * + 16 * + 16 * + (>K:COM_RADIO_SET) 

     </CallbackCode>
   </MouseRect>
 </PartInfo>

The kHz knob :

Code:
 <PartInfo>
    <Name>gomb_com_kHz</Name>
    <AnimLength>360</AnimLength>
    <Animation>
      <Parameter>
        <Code>(L:com_khz,number) (A:COM ACTIVE FREQUENCY:1, MHz) 1 % != 
              if{ (A:COM ACTIVE FREQUENCY:1, MHz) 1 % 0.025 / (>L:khz,number) 
              (L:khz,number) 0.025 * (>L:com_khz,number) } 
              (A:COM ACTIVE FREQUENCY:1, MHz) 1 % 360 * 
       </Code>
      </Parameter>
    </Animation>
    <MouseRect>
      <Cursor>hand</Cursor>
      <TooltipText>COM Freq - %((A:COM ACTIVE FREQUENCY:1, MHz))%!3.3f!MHz</TooltipText>
      <MouseFlags>WheelUp+WheelDown+LeftSingle+RightSingle</MouseFlags>
      <CallbackCode>

      (M:Event) 'RightSingle' scmp 0 ==   
      (M:Event) 'WheelUp' scmi 0 == or 
      if{ (L:khz,number) ++ 40 min (>L:khz,number)  1 (>L:lun_khz_hang,enum) }      

      (M:Event) 'LeftSingle' scmp 0 ==   
      (M:Event) 'WheelDown' scmi 0 == or
      if{ (L:khz,number) -- -1 max (>L:khz,number) 1 (>L:lun_khz_hang,enum) } 

      (L:khz,number) 39 > if{ 0 (>L:khz,number) }
      (L:khz,number) -1 == if{ 39 (>L:khz,number) }
             
      (L:khz,number) 0.025 * (>L:com_khz,number)

      118 (L:com_mhz,number) + (L:com_khz,number) +
      100.001 * 10000 % int d 10 % r 10 / int d 10 % r 10 / int d 10 % r 10 / int 16 * + 16 * + 16 * + (>K:COM_RADIO_SET)
      
     </CallbackCode>
    </MouseRect>
 </PartInfo>
 
I've been trying to modify the working code above to meet my requirements but not had much luck. The code as it stands seems to rotate the part through 180° and then stops.

For my part I need it to rotate through 360° without the stop (i.e. to keep turning as long as the user provides input) as the dial starts back at 118 Mhz again after the first revolution.

Can anyone suggest how I can adapt the code to my needs please?
 
I've been trying to modify the working code above to meet my requirements but not had much luck. The code as it stands seems to rotate the part through 180° and then stops.

For my part I need it to rotate through 360° without the stop (i.e. to keep turning as long as the user provides input) as the dial starts back at 118 Mhz again after the first revolution.

Can anyone suggest how I can adapt the code to my needs please?

Hello

I used the code above in my baby : PWDT Z-142. The kHz tuning goes around-and-around, as you want it also for MHz.

This part of the code will do this in the kHz code:

(L:khz,number) 39 > if{ 0 (>L:khz,number) }
(L:khz,number) -1 == if{ 39 (>L:khz,number) }

When the counter (L:khz, number) steps over 39 (39 * 0.025 = .975kHz) it will jump to 0 again, this tune the frequency from .975 to .000 when tuning upwards.

Same thing when you tuning downwards : steps below -1, the counter continues at 39, it will goes from .000 to .975kHz.

If you look the code of the MHz tuning there is no this kind of expressions in it. That's way the Mhz tuning will stop at 118 and 136.

I hope it is clear :)
 
Back
Top