FSXA Analog Kohlsman not staying in sink with mouse clicks

#1
Analog Kohlsman not staying in sink with mouse clicks. And when i click STD it says 29.91 and the tooltip says 29.92.

Has anyone ran into this issue? i use 10 keyframes for the drum wheels. I tried using 100 to see if the 1000th value would average out as you rotate the value. But this also was out of sink with the tooltip value. But the math is correct because it seems to catch back up when it falls behind or vice versa.

For the 1000th wheel i am using 10 animated frames with this code.
I also tried not rounding down with no flr in the code.

Code:
(A:KOHLSMAN SETTING HG, INHG) 99 min 0 max 0.1 % 0.01 / flr
Seems to me the issue is the default coding because the math is correct.:rolleyes:
 
Last edited:

n4gix

Resource contributor
#2
Try adding 'abs' and use 'near' instead of 'flr':
Code:
<Code>(A:KOHLSMAN SETTING HG, inHg) abs 99 min 0 max 0.1 % 0.01 / near</Code>
 
#3
That worked perfect. But now i have another issue. The 100th drum is rounding down when it's time to flip up 1 value.
Example.....89, 80, 91

So i tried using near and then it flips 84, 95, 96.

Why?
 

n4gix

Resource contributor
#4
Here are mine tested and working perfectly:
Code:
  <PartInfo>
    <Name>C310_baro_hundths</Name>
    <AnimLength>9</AnimLength>
    <Animation>
      <Parameter>
        <Code>(A:KOHLSMAN SETTING HG, inHg) abs 99 min 0 max 0.1 % 0.01 / near</Code>
      </Parameter>
    </Animation>
    <MouseRect>
      <TooltipID>TOOLTIPTEXT_ALTIMETER_FEET_METERS_SPECIAL</TooltipID>
    </MouseRect>
  </PartInfo>

  <PartInfo>
    <Name>C310_baro_tenths</Name>
    <AnimLength>9</AnimLength>
    <Animation>
      <Parameter>
        <Code>(A:KOHLSMAN SETTING HG, inHg) abs 99 min 0 max 1 % 0.1 / flr</Code>
      </Parameter>
    </Animation>
    <MouseRect>
      <TooltipID>TOOLTIPTEXT_ALTIMETER_FEET_METERS_SPECIAL</TooltipID>
    </MouseRect>
  </PartInfo>

  <PartInfo>
    <Name>C310_baro_1</Name>
    <AnimLength>9</AnimLength>
    <Animation>
      <Parameter>
        <Code>(A:KOHLSMAN SETTING HG, inHg) abs 99 min 0 max 10 % 1 / flr</Code>
      </Parameter>
    </Animation>
    <MouseRect>
      <TooltipID>TOOLTIPTEXT_ALTIMETER_FEET_METERS_SPECIAL</TooltipID>
    </MouseRect>
  </PartInfo>

  <PartInfo>
    <Name>C310_baro_10</Name>
    <AnimLength>9</AnimLength>
    <Animation>
      <Parameter>
        <Code>(A:KOHLSMAN SETTING HG, inHg) abs 99 min 0 max 100 % 10 / flr</Code>
      </Parameter>
    </Animation>
    <MouseRect>
      <TooltipID>TOOLTIPTEXT_ALTIMETER_FEET_METERS_SPECIAL</TooltipID>
    </MouseRect>
  </PartInfo>
 
#5
Thanks for sharing your code Bill. I use the same code but what i learned today is i do not need to use 10 key frames with a second zero at the end.

It's easier to divide the drum by 10 images but if the drum only has 9 key frames then you still can divide by 10 but just use 9 images. So thanks again as this finally solved the issue why i was always in and out of sink.

I have to say it is almost perfect but i still find that it can skip a value every 2 or 4 cycles in the 100th and the 1000th value. So this to me is a fsx bug and not coding. But with your help my values are near perfect now.
 
Last edited:

n4gix

Resource contributor
#6
That's your problem, the zero is repeating (frame 10). Consecutive single digit numbers will never reach 10...

Number strip should run:
0 1 2 3 4 5 6 7 8 9
 
#7
Yes that fixed it but all other custom drum wheels that use enum or bool will work using 10 key frames because 10 becomes 0 and i use the number zero twice.
But for reading variables i am learning now it causes an issue as we both are talking about. So i updated all my codes to only use 9 key frames and i still put 10 images on the drum wheel so it divides evenly.

So another lesson learned as gauges take years to master!:wizard:
 
#8
Bill i still get complaints about how the scale skips and repeats a value 2 times every 4 clicks then every 5 clicks and sometimes other odd amount of clicks. And the default tooltip does the same but on different values. Our beta tester looked at your 310 in FSX and it showed similar behavior. So i think there is some screw up when FSX created how the kohlsman math formula works.
 
Last edited:

DragonflightDesign

Resource contributor
#10
Quote from the sd2gau docs:

It appears that the inches and millibars conversions in the token variables KOLLSMAN_SETTING_MB and KOLLSMAN_SETTING_HG are not quite in sync. The trick to keep them correct is to use KOLLSMAN_SETTING_MB only and then use the following calculation from Gordon Small:-

1013.25 mb = 1.0 atmospheres and each atmosphere is equal to 29.92 inches of mercury, therefore:

atmospheres=X/1013.25 where X is the pressure in mb

pressure in inches = atmospheres*29.92.

He comments that, "I think the problem with FS is that the code takes 1013mb to equal 29.92 inches when it obviously isn't."
 
#11
It appears that the inches and millibars conversions in the token variables KOLLSMAN_SETTING_MB and KOLLSMAN_SETTING_HG are not quite in sync.
Dai,

What was Gordon getting at?

1552329046715.png


The var names could be misleading since they are the same, or nearly the same, numbers, but the units conversions look ok.

Bob

FSXA
 
#13
He comments that, "I think the problem with FS is that the code takes 1013mb to equal 29.92 inches when it obviously isn't."
This will not fix a drum wheel from repeating some values. This only puts the 1013 MB closer to 29.92 HG.
The answer would be to know how far off is each click for MB. Which is near 0.0008 then add this into the hard coding for the drum so it can stay closer to the the actual value.

We did some testing tonight and made a tooltip to display more places after the decimal point for the default HG value using 4.3f in the string. But we got too tired to do more testing.
Tomorrow we will use 4.4f in the string to show more decimal points to get a more accurate value and then re write the hard coding.

I also had trouble adding 0.0008 to the hard coding like the code bill posted. So if anyone can make a sample of how to offset this code by 0.0008 please show. Then tomorrow we will use our new value.
 
#14
I've got this in one of my gauges. It's years old and I can't remember why it was done, but I assume it's linked to this problem.
The x 100 is because I'm using @ExtDigit to drive the drums so I need to get rid of the decimal point.

XML:
<!-- Add the 0.005 Fudge Factor -->
<Element>
  <Select>
    <Value>(A:KOHLSMAN SETTING HG,inHg) 0.005 + 100 * int (&gt;L:BaroSet,number)</Value>
  </Select>
</Element>
 
Last edited:

Roy Holmes

Resource contributor
#15
One inch of mercury pressure change equates to 1000 ft height change. So .01 inch is 10 ft. The average barometric altimeter accuracy is about +/- 30 ft.
You are seeking precision where it does not exist. The difference is common where imperial and metric units are compared.
Roy
 
#16
We found a decent solution but not perfect. The solution was to no longer use the "near" function to round to the nearest whole number for the last drum drum wheel. Instead we use the flr to round down to the lower whole number. This required the fudge factor of 0.005. So here is the upside and downside.

Upside:
No longer skips any values. (This is what we wanted)
Stays in sync with tooltip.

Downside:
Just like the tooltip it repeats a value every 12 clicks.

We also removed the abs because we do not see a reason for it because there are no negative values.
This fudge factor puts the start value over the 29.92 value since we now round down.
Code:
    <Animation>
      <Parameter>
        <Code>(A:KOHLSMAN SETTING HG, inHg) 0.005 + 99 min 0 max 0.1 % 0.01 / flr</Code>
      </Parameter>
    </Animation>
 
Last edited:
Top