Nightlighting panel and gauges

[Guest Basil]

I've been modifying a panel (Maule) to add some IFR equipment and other customizations. After much work, I thought I had what I wanted, until this evening when I was flying at dusk and turned the cabin lights on. One of the gauges (a realityxp vor2 gauge) just up and disappears, the gauge bitmaps on a couple of others (also realityxp) do not merge well with the panel bmp, and only the pointers are visible in others (airspeed, vertical speed, and altimeter all borrowed from the cessna 182).Altogether a real mess.I know absolutely nothing about how nightlighting is effected through the panel bitmap. In restoring the original panel, none of the original gauges themselves have nightlighting. The nightlighting effect is entirely through the panel bitmap.I'm not sure what to do. I might could live with the lights off if I could find suitable airspeed, altimeter, and vertical speed gauges with their own lighting. But I'd rather figure out why the gauges themselves do not work with the night panel bitmap and fix that if possible.Basil

[n4gix 4,947]

Older style gauges used LUMINOUS for internal lighting, which received its value from the panel.cfg entry:Luminous=190,190,190Newer style gauges use internal lighting controls based on:LIGHT_IMAGEwhich is coded into the gauge by the programmer. If the programmer didn't make provision for this feature or the older "LUMINOUS" method, then there is nothing you can do to "fix them."

[Guest Basil]

The Maule panel.cfg has the following in it:Luminous=200,200,200The nightlighting works fine with the original gauges. The problem is when I substitute other gauges, like gauges from the default Cessna (which also has a "Luminous=" but with different values), and with the realityxp gauges.The realityxp gauges have their own lighting, so I could leave the panel lighting off for them. But then I cannot see my other gauges. I may just have to ditch the cessna gauges, and return to the original Maule gauges. (For all the raves this plane gets, and for the most part deserves, I'm surprised that no one has complained about the quality of the gauges. I think they are supposed to look "photorealistic." But they look blurry and are hard to read. I guess that's why the tool tips all give digital readouts.)Thanks for trying to help, or at least explain things to me.BasilP.S. I've borrowed the EDM-700 from the Socata panel, and works just fine, having its own lighting.

[Guest Basil]

I wonder if this is something other than just a "luminous=" issue. If you would, take a look at the attached image. The airspeed, attitude, altimeter, and vertical speed gauges are all from the FS2004 Cessna 182. The attitude indicator is the only one that looks "complete." The altimeter is mostly complete, but if you look closely at about 7-8 o'clock you'll see a rectangular area missing. Only small portions of the other two gauges appear; what appears is well lighted, so the "luminous" values seek to be okay, don't they?WIth the realityxp vor gauges, the VOR2 gauge, which is not showing in the image, will appear if I click where the OBS button is active. Sometimes VOR1 doesn't appear with the lights are turned on until I clcik where the OBS button is active also, but it usually comes on.Any other ideas of what's going on?Basil

[sab12 6]

I am doing some of the same kind of retrofitting Basil is doing and having some of the same frustrations.I have a situation where a Cessna! gauge appears and is lighted in the 2-D cockpit and appears but is not lighted in the VC. Thoughts/suggestions?Also, how is the lighting for light_image gauges controlled? I can't remember seeing any references to this in any .cfg etc. files.Thanks,

[n4gix 4,947]

>I have a situation where a Cessna! gauge appears and is>lighted in the 2-D cockpit and appears but is not lighted in>the VC. Thoughts/suggestions?>>Also, how is the lighting for light_image gauges controlled? I>can't remember seeing any references to this in any .cfg etc.>files.First of all, VC gauge backlighting requires two things, both of which must be present.1)Think of the VC "gauge display" as if it were an LCD screen. Gauges & textures are "projected" onto the screen and thereby can be "seen" in the sim. Backlighting of the "projection screen" must be supplied at night in order to brighten up the "projected image." This is a function of the model's internal code structure. If the designer has provided the needed code to apply an _L.bmp (lightmask), then you can "paint" the _L.bmp file wherever you want illumination. If the model doesn't have this coded in already (such as all the default a/c!), then there is nothing you - as an end user - can do to change that.2)As I mentioned previously, each gauge may be coded by the programmer to use "Luminous," in which case the "Luminous" entry in the panel.cfg controlls the color and brightness......or they may specify "BRIGHTEN_IMAGE," in which case the gauge element becomes "self-illuminating." In addition, the gauge programmer can use alternate bitmaps for any or all gauge elements they wish, and then apply the "BRIGHTEN_IMAGE" to them, thereby creating one or more levels of "relative brightness," based on the bitmaps.In the case of vector drawn "glass gauges," there is yet another technique the gauge programmer can use to provide levels of screen brightness.However, all that said, ultimately you as an end-user have absolutely no control whatsoever over whether the gauges have the ability to illuminate or not. Either the gauge(s) have the needed code programmed in, or they do not.Likewise, in the case of a virtual cockpit, the ability to "backlight gauges" is either built into the model, or it is not...As for the OP's problem with some gauges having "invisible/hidden" displays under certain conditions, that again is dependent upon how the gauge programmer designed the gauge(s). You might try altering the display order of the gauge(s) either through reshuffling the panel.cfg entries, or using the (undocumented) "draw order" command in the panel.cfg:draw_order00=gauge04, gauge17, gauge05, gauge06, gauge28,This snippet from the TB20GT's panel.cfg illustrates this. I am explicitly instructing FS to draw gauge04 first, followed by the remaining gauges in the list, then draw all the others in that entry in whatever order they are listed. This was quicker than resorting the gauge entries... ;)I sure hope this helps clear up these issues!

[Guest Basil]

Not sure why, but when I commented out the following "gauge" the problems went away://gauge00=Maule_IG_panel!Panel_norm, 0,0,1024,768Without this, the panel itself does not cast lighting at night like it does with it, but without it all the gauges are capable of displaying their "night" and "luminous" properties correctly. Following your suggestion about load ordering, I tried loading it last, instead of first, but that didn't work.I can do without it. (I think; for now it seems I can, but who knows what may come up and bite me later?)Thanks for the input.Basil

[n4gix 4,947]

In that case, you might wish to simply extract the bitmap from the "Panel_norm" gauge in the "Maule_IGpanel" gauge.Create a new window and use that "nighttime panel" as the background image, then copy all the gauges used in [Window00] to the new window.

[Guest iholrf]

Bill,Is the brighten_image guage element available in XML or only C? Is this documented somewhere?TIAShad

[sab12 6]

Bill,Thanks for your explanation.

[n4gix 4,947]

>Bill,>>Is the brighten_image guage element available in XML or only>C? Is this documented somewhere?Shad,In XML the tag is Bright="Yes"For example:Simple, no? ;)

[Guest lonelion]

>Newer style gauges use internal lighting controls based on:>LIGHT_IMAGEDo you tell me please, where to get info about this? or code sample... i don't see it in panel SDK

[n4gix 4,947]

>>Newer style gauges use internal lighting controls based on:>>LIGHT_IMAGE>>Do you tell me please, where to get info about this? or code>sample... i don't see it in panel SDKThe "official" command in the SDK is:IMAGE_USE_BRIGHT Use this to make the image appear lit at night.Most C programmers use an "enhanced and expanded" version of the gauges.h file though, where LIGHT_IMAGE and DARKEN_IMAGE macros are defined:#define LIGHT_IMAGE( element ) ((element)->image_flags |= IMAGE_USE_BRIGHT)#define DARKEN_IMAGE( element ) ((element)->image_flags &= ~IMAGE_USE_BRIGHT)The first macro will "add" the IMAGE_USE_BRIGHT to the image flags list, whereas the second macro "removes" the command from the image flags list.This allows the programmer to write dynamic code to toggle on/off the "light" easily... ;)FLOAT64 FSAPI AirspeedNeedle_cb( PELEMENT_NEEDLE pelement)if ( panel_lights == 1 ) { SHOW_IMAGE(pelement) ; LIGHT_IMAGE(pelement) ; }else { HIDE_IMAGE(pelement) ; } return;}

[Guest lonelion]

thanks for explanation it is clear now ;)

[n4gix 4,947]

>thanks for explanation it is clear now ;) No problem! Note that it isn't necessary to use the DARKEN_IMAGE tag in the 'else' clause, since we've used HIDE_IMAGE... If the image is hidden, it won't matter if it is 'lighted' or not! ;)