Mask affecting neighboring gauges

I've created a gauge with a mask that is considerably bigger than the gauge itself, and while the the mask itself works just fine, it messes up gauges that are "covered" by it.
For example, if I place it right above an autopilot gauge, the AP's buttons either stay lighted or off all the time, not in synch anymore with the AP's mode. I can still operate it, and when I do the light is correct for a moment, but then it goes back to its buggy mode.
Is this a known limitation, or is there something wrong with my mask or the code?

In the attached screenshot, the blue frame indicates the overall size of the mask, which has a cutout for the smaller, framed rectangle inside. The grown arrow rotates within this rectangle, and is cut off correctly.
(This may seem like a silly gauge, but it's a simplification for debugging purposes.)

The important code is listed below, and the complete gauge (code & images) has also been attached:
Code:
<SimGauge.Gauge id="Gauge" ArtDirectory=".">

    <FloatPosition>0.000,0.000</FloatPosition>
    <Size>220,100</Size>
    <!-- Black background -->
    <Image id="back" Name="back.bmp">
      <Transparent>True</Transparent>
      <Bright>True</Bright>
    </Image>
    
    <Element>
      <FloatPosition>-89,-76</FloatPosition> 
      
      <!-- Mask -->
      <MaskImage Name="mask.bmp"> 
        <Axis>155,151</Axis>
        <Transparent>True</Transparent>
      </MaskImage> 

      <!-- Rotating image -->
      <Image id="pointer" Name="pointer.bmp">
        <Axis>58,71</Axis>
        <Transparent>True</Transparent>
      </Image>

      <!-- Rotate it -->
      <Rotation>
        <Expression>
          <Script>(E:LOCAL TIME,seconds) 60 % 100 * 0.017453 *</Script>
        </Expression>
      </Rotation>
    </Element>        
                    
  </SimGauge.Gauge>
 

Attachments

tgibson

Resource contributor
Can you move the AP to another location temporarily to prove that it is the gauge interaction that is doing this?
 
Oh, it's definitely the new gauge (with the mask).
AP normally works just fine, and I never have problems with its lights acting up, but as soon as I put the new gauge above it, it goes crazy.
 

Luka

Resource contributor
I'm not sure, but you can try to add "draworderNN=gaugeAA, gaugeBB,..." in panel.cfg, or using "Clip" (or RelClip) instead of MaskImage in xml.
 
YEAH! draw_order did it!!!
Once I define it, the "covered" gauges worked just fine.
Thanks for saving my gauge!

For those who might end up here, with a similar problem, here's the details:
The original AP gauge (that ended up being overlapped by the mask) was defined as, let's say, gauge10, and my new gauge was gauge20.
So, I added the following line below all the gaugeNN= definitions, telling the engine to first draw the new gauge (with the mask), and then to draw the old gauge: draw_order00=gauge20,gauge10

I'm not sure what the significance of the "00" in the draw_order is (I guess you can use different numbers there, but why — since you can just put all the gauges into draw_order00), but anyway, this works.

What didn't work though, was just manually putting the new gauge at the top (i.e. make it gauge10, and the AP gauge #20). That just screwed up everything, and all the covered gauges disappeared altogether.
 

Luka

Resource contributor
I'm not sure what the significance of the "00" in the draw_order is (I guess you can use different numbers there, but why — since you can just put all the gauges into draw_order00), but anyway, this works.

What didn't work though, was just manually putting the new gauge at the top (i.e. make it gauge10, and the AP gauge #20). That just screwed up everything, and all the covered gauges disappeared altogether.
Order of gauges (gauge00/01/02...) has no effect because each gauge is not rendered constantly, but only when really changed (ie when the pointer moves). But draw_orderNN=gaugeAA,gaugeBB will force the gaugeBB to refresh whenever the gaugeAA changed. So, to prevent loss of performances, is not a good idea to place all gauges into a single draw_order. If there are more collisions between gauges, it is better to use more draw_orders (draw_order00, draw_order01, etc).
 
Top