Talk:2D Panel Lighting RFC

Hi Ben,

Will think a bit about your suggestions :)

Regardless of what we end up with, I'd really like a master ON/OFF switch for the LIT panel instead of the SIM deciding when it's appropriate to turn it on. I can also imagine that in real the panels get lit step by step as it gets darker, not flood, background etc all at once... . So, maybe a ON/OFF switch for each type of light?

Cheers,

Morten

Morten -- Remember that right now it's a dual on-off switch...the flood light has to be on AND the sim has to think it's dark enough to warrant lighting. This is unfortunately necessary now because the custom _LIT panel might look really absurd during the day, particularly if it has flood-light arcs written in. So I think that to move to a 100% user-driven switch, we'd need to change the actual lighting to be dynamic, so that the flood halos can be made less "drastic" in high ambient light conditions (like an overcast day). We may get there some day, but I'm not sure about biting off that hw chunk now. Jose's concept of a -2 light mask at least gives us an authoring format that makes dynamic lighting of the floods possible. --Ben

Hi Ben,

As far as I know, at the moment, the flood light is always on and the sim decides 100% the timing of on/off. If the main argument against a user controlled LIT on/off switch is "night panels look crap at daytime", this could be avoided by having a checkbox in viewpoint PM "allow LIT panels between 8AM and 4 PM" or something like that.

I think the transition phase between day/night and night/day is one of the main issues needed to be solved. At the moment, both day and night panels work well as is at .. well.. day and night :)

Cheers,

M

Its making my head hurt trying to formulate a coherent response for some reason - it's all layers within layers etc... Maybe some headings will help: :-) -AG

Proposed Panel Background Lighting Mask
The combined shadow/halo mask sounds like a clever idea. Just to confirm, when you say 'the system would be set up to use one or the other, but not both', do you mean 'not both at the same time?'. I think it's important that a panel should be able to have both a shadow mask AND a lighting mask - but I agree that they would rarely be needed at the same time. -AG

Proposed Layering Generic Instrument
Very much in favour of this idea. It would save having to cannibalise default instruments in order to appropriate their mask layers, which is what I've done in the past. :) Alternatively, rather than creating a new 'mask' instrument category, you could maybe establish a standard convention (within the scope of generic instruments) linking a layer's behaviour and it's suffix. For example (off the top of my head): "inst-1" = any moving elements: digits, needles etc; "inst-2" = overlay masks whose brightness is tied to the 'instrument brightness' rheostat; "inst-3" = overlay masks tied to the 'cabin flood' rheostat, "inst-4" = unlit overlay masks. Any desired combination of layers would be permitted, irrespective of instrument category (needle, tape, annunciator etc). For maximum flexibilty, the layer draw order might be defined by dragging their names up or down a hierarchy list, in a similar manner to the WED UI -AG

Proposed Additive Lighting Instruments
I'm not 100% sure that I understand the question... :-) -AG

Proposed Additional Brightness Source Algorithms
Here's one I'd find useful:
 * Instrument remains visible but ceases to function when it's associated bus fails. For example: radios with mechanical numeric displays, needle-type gauges with powered senders etc. -AG