P3D v4 Randomly bright gauges (2d panel)

[Miguel]

Hello all, it's me again with my CASA-212.

While trying out the 2d panels (I need 2d ones for the home cockpit), I came to realize that when I set the time to night and all lights off, I have some random bright gauge images or background images.
The random full bright images change at each airplane reload, so let's say for example that the left starter switch may be fully bright, and if I reload the aircraft, it may be dark, but now the Right ignition switch is fully bright.

With all lights off, I took the first picture, reloaded the aircraft and then took the second.

What i've done till now:
-I created all images on GIMP and saved them as 32 bit BMPs (ARGB) and 24 bit (RGB).
-I came back to the drawing board, saved it all as a psd and used psd2xml to get the BMPs. Same result.
-Setting button images to Luminous="False", without success.
-Changing the [color] section in the panel.cfg (Luminous, Day, Night)

Does anyone have any idea of why this is happening, and how to correct it? I'm pretty sure it will be something dumb but I can't seem to catch it.

 

[rpmc]

Interesting. I don't know what's causing that but I regularly experience an incomplete panel set load when I start one particularly complex-gauge aircraft in P3D v4. Related to your issue? Not sure, but I "solve" mine by including a panel reload click area in one of my gauges. Load aircraft from Select Vehicle - see incomplete panel set load - click Reload User Aircraft button - everything then is normal. Could be worth a try until you find out what's really causing it, or it might be a wild goose chase.

 

[DragonflightDesign]

It's a screen draw timing problem. Basically, if the sim finishes the redraw before the panel is set onscreen, you can end up with only a partial redraw displayed. I've found this is particularly troublesome in two circumstances; a complex panel (as Roy has found) or gauges that do not have any moving parts i.e. they just display an icon. That was the bane of my life for quite some time until I figured out what was going on: these days as soon as the panel is loaded onscreen I then keep firing off a redraw sequence for a further second or two to ensure everything is displayed correctly. A good way of doing it is to use PANEL_LIGHTS_ON/OFF; determine the state of the panel lights, then flip them the other way and back again. It happens so fast that you don't get a screen flicker but it forces the screen to update. You may need to do this multiple times; I do it every half second for five seconds, then stop it from happening again until the panel is closed and reopened. This prevents event flooding. If your background is a gauge displaying a bitmap and you are not loading a bitmap defined in the panel.cfg [Window] section, then quite often just forcing the background gauge to update kicks the others into submission. If your background is a bitmap loaded from the [Window] section in the panel.cfg then you'll need to add code into each gauge that's causing trouble.

As I only program in C/C++, I can't help with forcing a redraw in XML.

For users with no access to the source code, the only option is Roy's suggestion.

 

[rpmc]

A good way of doing it is to use PANEL_LIGHTS_ON/OFF; determine the state of the panel lights, then flip them the other way and back again. It happens so fast that you don't get a screen flicker but it forces the screen to update. You may need to do this multiple times; I do it every half second for five seconds, then stop it from happening again until the panel is closed and reopened.

Ahh, that's a good idea, and that can be automated by an XML gauge init sequence without having to manually click a mouse area that fires off a (>K:RELOAD_USER_AIRCRAFT). I like the idea of momentarily toggling PANEL_LIGHTS better than a RELOAD_USER_AIRCRAFT.

Firing Events in a gauge init sequence can also run into timing issues as discussed in this wiki, so you might want to incorporate ideas from the wiki, like Rob Barendregt's delay scheme to get it to work to your satisfaction. Gauge script begins running slightly before the sim’s event and trap handling system is operational which possibly could explain why Dai needs to flip the panel lights multiple times.

Bob
(not Roy, but Roy is a friend of mine )

 

[Miguel]

Interesting. I don't know what's causing that but I regularly experience an incomplete panel set load when I start one particularly complex-gauge aircraft in P3D v4. Related to your issue? Not sure, but I "solve" mine by including a panel reload click area in one of my gauges. Load aircraft from Select Vehicle - see incomplete panel set load - click Reload User Aircraft button - everything then is normal. Could be worth a try until you find out what's really causing it, or it might be a wild goose chase.

Thanks for your suggestion. Unfortunately, the gauges keep behaving the same when I reload the panel with (>K:RELOAD_PANELS). If I use the key binding for reload user object, it just changes which images will be bright.
What surprises me is that it's not a gauge-wide problem, but it only occurs with random images, and even then, as you can see in the 2nd picture, the Right Torque indicator background is bright (while its needle is dark) and the left torque indicator is completely dark. Both background images are the same, yet they behave differently


DragonflightDesign's comment came in just as I was replying to Bob's.

It's a screen draw timing problem. Basically, if the sim finishes the redraw before the panel is set onscreen, you can end up with only a partial redraw displayed. I've found this is particularly troublesome in two circumstances; a complex panel (as Roy has found) or gauges that do not have any moving parts i.e. they just display an icon. That was the bane of my life for quite some time until I figured out what was going on: these days as soon as the panel is loaded onscreen I then keep firing off a redraw sequence for a further second or two to ensure everything is displayed correctly. A good way of doing it is to use PANEL_LIGHTS_ON/OFF; determine the state of the panel lights, then flip them the other way and back again. It happens so fast that you don't get a screen flicker but it forces the screen to update. You may need to do this multiple times; I do it every half second for five seconds, then stop it from happening again until the panel is closed and reopened. This prevents event flooding. If your background is a gauge displaying a bitmap and you are not loading a bitmap defined in the panel.cfg [Window] section, then quite often just forcing the background gauge to update kicks the others into submission. If your background is a bitmap loaded from the [Window] section in the panel.cfg then you'll need to add code into each gauge that's causing trouble.

As I only program in C/C++, I can't help with forcing a redraw in XML.

For users with no access to the source code, the only option is Roy's suggestion.

Thank you too for your help. Following both your suggestions, I have tried to add this into the Update block of one of the gauges that keeps having bright elements:

(L:PANELREDRAW) 10 < 1 1.2 (L:LASTTIME) 10 % rng and if{ (>K:RELOAD_PANELS) (>K:PANEL_LIGHTS_TOGGLE) (L:PANELREDRAW) 1 + (>L:PANELREDRAW) }

This should redraw the panels 10 times, as well as toggle the panel lights, ± once every 10 seonds. Yet, to no avail.
I can see the panel lights toggling, but the bright textures remain once the lights go dark again.

I have also tried cycling the Panel lights with the key binding, but once again it just brightens the panel and then returns to the same thing after I turn the lights off.

I'm running out of ideas, to be honest.

 

[rpmc]

(>K:RELOAD_PANELS) is what to use if you are running FS9. Try (>K:RELOAD_USER_AIRCRAFT) for FSX and P3D v.X and see if that helps ... hope it does!

Here are two ways to refresh the panel. See if either works. Your comment about seeing the panel lights toggle suggests that gauge 2, the panel lights toggle gauge, won't solve the problem, but I'm hoping that the reload user aircraft gauge does. If not, then it's on to something else to think of.

Bill Leaming has a lot of expertise in lighting issues, so when he reads this thread, he, for one, may know what's going on. And when Stoviak gets coffee'd-up, he will just solve it like always.

There's an explanation out there somewhere.

[edit] - removed xml example. bad code]

Bob

 

[Miguel]

(>K:RELOAD_PANELS) is what to use if you are running FS9. Try (>K:RELOAD_USER_AIRCRAFT) for FSX and P3D v.X and see if that helps ... hope it does!

Here are two ways to refresh the panel. See if either works. Your comment about seeing the panel lights toggle suggests that gauge 2, the panel lights toggle gauge, won't solve the problem, but I'm hoping that the reload user aircraft gauge does. If not, then it's on to something else to think of.

Bill Leaming has a lot of expertise in lighting issues, so when he reads this thread, he, for one, may know what's going on. And when Stoviak gets coffee'd-up, he will just solve it like always.

There's an explanation out there somewhere.

<Gauge Name="RELOAD_GAUGE" Version="1.0">
    <Size X="2" Y="2" />
    <Update>     
        (L:Reload_Gauge_1, bool) 0 ==
            if{
                (>K:CABIN_SEATBELTS_ALERT_SWITCH_TOGGLE)
                1 (>L:Reload_Gauge_1, bool)
            }

        (A:CABIN SEATBELTS ALERT SWITCH, bool) 1 == (L:User_Aircraft_Reload, bool) 0 == and
            if{
                (>K:RELOAD_USER_AIRCRAFT)
                1 (>L:User_Aircraft_Reload, bool)
            }
    </Update>
</Gauge>

or

<Gauge Name="PANEL_LIGHTS" Version="1.0">
    <Size X="2" Y="2" />
    <Update>     
        (L:Panel_Lights_1, bool) 0 ==
            if{
                (>K:CABIN_SEATBELTS_ALERT_SWITCH_TOGGLE)
                1 (>L:Panel_Lights_1, bool)
            }

        (A:CABIN SEATBELTS ALERT SWITCH, bool) 1 == (L:Panel_Lights_Toggle, bool) 0 == and
            if{
                (>K:PANEL_LIGHTS_TOGGLE)
                1 (>L:Panel_Lights_Toggle, bool)
            }
    </Update>
</Gauge>

Bob

Hey Bob!

Unfortunately, none of the gauges work. The 2nd one, as we expected, doesn't do anything else than cycle the panel lights, but without effect.
Meanwhile, (>K:RELOAD_USER_AIRCRAFT) reloads the aircraft anew, as well as all user variables. So it just turns in a loop with constant triggering.

I'm officially out of ideas.

 

[rpmc]

So it just turns in a loop with constant triggering. Constant triggering .. oops, you're right. Big apology for that.

And a manual Reload mouse click (>K:RELOAD_USER_AIRCRAFT) which is a guaranteed one time only doesn't do it?

Then need to think about it differently......

Bob

 

[EduHir]

this behaveiour was found on FSX , P3dv4 an is on P3Dv5 also! i think it was also on FS9, but can't remember.

I checked it here on P3dv5 and it is the same as on the older versions.
I used PANEL_LIGHTS_ON/OFF (shift + L), PANEL_LIGHTS_ON/OFF with xml- gauge and (>K:RELOAD_USER_AIRCRAFT).
So i think it's an old bug.

 

[DragonflightDesign]

I've been fighting it since FS9.

 

[WarpD]

Ok... it's not a bug, per se... but... here's what I know about it.

No dynamic elements (icon, slider, etc.) will update their lighting if their state (position, etc.) is unchanged on load. In other words, if it defaults to 0 on load and is at 0... no lighting update is called ( I dunno WHY).

Any static elements will not get a lighting update unless done in the PRE_UPDATE cycle (it's the only cycle I've ever seen it behave consistently).

 

[DragonflightDesign]

Thanks Ed - that collates with what I've found - except that PRE_UPDATE isn't always totally reliable either! Not immediately after load is complete, anyway. I use the 'check the seatbelts' method detailed in the wiki to confirm when load is complete and then start an additional reload sequence. Contrary to what I said way above, I've recently found that a two-second reload interval for twenty seconds covers all the PCs that are being used by the current batch of testers. It does lead to a visually odd load sequence; as you say, all the non-zero stuff loads immediately followed by the zero stuff after the first forced update. I doubt a 'normal' user would really comment on it but as a developer, I'm painfully aware that it's a 'two stage load' to get a complex 2D panel up successfully.