Will Dark Screens Be Fixed on 2020 Planes?

[LyonHaart001]

Version: 1.XX.XX.X

Frequency: Daytime mode in the sim

Severity: High Blocker
(Low - quality of life, workflow optimization, rare enough to not impact production, etc…
High - critical but workarounds are available, important feature not working as expected, frequent enough to impact production
Blocker - prevents from working on the project, prevents from releasing the product)

Marketplace package name: LHC Trinidad TB21 GT if applicable

Context: Mounted in Community, MSFS 2020 running in 2024.

Similar MSFS 2020 issue: None, MSFS it runs fine.

Bug description: Dark Screens in the daytime. You can barely see that it is on, but only barely. At night they are fine. I tried doing the day time boost coding in the model XML and that didnt work.

Repro steps: Load a flight in the Trinidad TB21 GT and note the screens in daytime.

Attachments:

Private attachments: Send a PM to @PrivateContent with the link to this topic and the link to download your content

Daytime

Night

My question concerning this is will Asobo be fixing the dark screen issue, or is this up to us. We are just days away from release. It would be good to know now if we need to fix this ourselves, and how to fix it.

Many thanks, Team Aosbo. Hope all is well. Keep up the great work.

Bill
Lionheart Creations

[EPellissier]

@LyonHaart001,

Yes the plan is that this is fixed before release.
To be honest we are having an issue right now with those MSFS 2020 aircraft which did NOT connect their emissive to the sim day/night cycle - would it be the case for the LHC Trinidad TB21 GT?

Best regards,

Eric / Asobo

[R-AzurPoly]

Hello,
Same issue described here: Some MSFS2020 displays are way darker in MSFS2024 - #6 by Nick_NZASimulations

@EPellissier What do you mean by “connect their emissive to the sim day/night cycle”?

[LyonHaart001]

Hello Eric,

It was not on my planes except perhaps one screen on one plane, the newest version G3X. That had it, a recent update. But, I tried entering that into one of my planes, the Trinidad, to bring the screens back, and it didnt work. Raul had shown us a way to put this in, but for some reason, it didnt work.

This is the code I used for some of the screens in the Trinidad;

  	<Component ID="AUTOPILOT_SCREEN_FIX" Node="Autopilot Screen">
  		<UseTemplate Name="ASOBO_GT_Material_Emissive_Code">
                    <EMISSIVE_CODE>
                        (E:TIME OF DAY, Number) 1 == if{ 1.5 } els{ ( 0.5 }
                    </EMISSIVE_CODE>
                </UseTemplate>
        </Component>

Bill
LHC

[LyonHaart001]

@EPellissier

Eric, does this look correct to you? I wonder if its the Panel Config section that might be causing this. Background color. On one of my instruments in this plane, it has an entry in the panel config for ‘emissive=0’ on the Clock unit. Should these have an emissive entry?

[VCockpit04]
size_mm = 350,190
pixel_size = 350,190
Background_color=0,0,0
size_mm=1024,1024
texture = $AS430_Screen
htmlgauge00=NavSystems/GPS/WT430/WT430.html, 0, 0, 350, 190

[VCockpit05]
size_mm = 320,234
pixel_size = 320,234
Background_color=0,0,0
size_mm=1024,1024
texture = $AS530_Screen
htmlgauge00=NavSystems/GPS/WT530/WT530.html, 0, 0, 320,234

[LyonHaart001]

Fixed… @SimbolFSReborn found a mistake in the code I was using. That didnt clear it, but then I tried renaming the parts without spaces, putting in underscores, reexported the models, renamed them in the XML, and they worked.

So the day/night code fix is working, and the screens cannot (cannot) have spaces in the names, such as GNS530 Screen.

Bill
LHC

  	<Component ID="GNS530_SCREEN_FIX" Node="GNS530_Screen">
  		<UseTemplate Name="ASOBO_GT_Material_Emissive_Code">
                    <EMISSIVE_CODE>
                        (E:TIME OF DAY, Number) 1 == if{ 1.5 } els{ 0.5 }
                    </EMISSIVE_CODE>
                </UseTemplate>
        </Component>

[EPellissier]

@LyonHaart001,

Is it the Node attribute in the XML Component tag that created issues when including a space? Maybe our exporters replace spaces with underscores - I’ll need to check about this.

Best regards,

Eric / Asobo

[JimStewart]

@EPellissier - I can confirm we have this issue on our MSFS 2020 Blackbird Simulations / Shrike Simulations aircraft; they do not use the day night cycle as part of the emissive logic.

[bagolu]

I have the issues on my planes. I have no emissive connected to sim day/night cycle

I tried the same xml trick on nodes (with higer values for night) :

• it works nicely on kap140, com&nav & xpndr Asobo default screens
• it has an heratic behavior on WT450 by night (like if 2 systems were trying to set the emissive value)

I removed the hack. I think it’s better to have that corrected globaly.
NB. it affects registrations too (Registration/Registration.html)

[LyonHaart001]

Hello Eric,

My code I had, had a bad character in it. Fixing that helped. Then when I took the space out of the 2 word name of the part, it then worked. Lights Nodes in the System Config do this also. You cannot have a space in the name or the game causes the name not to be fully read by the sim. If you close it, use an underscore, set that into the XML file as well as the part name, and make the entry for the day/night code control, then it all works fine.

Thanks to @SimbolFSReborn for the info and help on this.

Bill
Lionheart Creations

[bagolu]

@EPellissier, are you refering to the gltf setting “day/night cycle” here in blender :

Because if I drop the 152 or the DR400 from msfs2020 in community 2024, both planes have good emissive behavior :

But they don’t seem to use it at all :

    {
      "name": "$NavCom1_Screens",
      "occlusionTexture": {
        "index": 75
      },
      "emissiveTexture": {
        "index": 76
      },
      "emissiveFactor": [
        1,
        1,
        1
      ],
      "pbrMetallicRoughness": {
        "baseColorTexture": {
          "index": 74
        },
        "metallicRoughnessTexture": {
          "index": 75
        }
      }
    },

They don’t have any specific setting in panel.cfg either

[VCockpit02]
size_mm                         = 512,70
pixel_size                      = 512,70
texture                         = $NavCom1_Screens
htmlgauge00=Generic/Radios/KX155A/KX155A.html?Index=1,          0,  0, 512, 70

[LyonHaart001]

Hello @bagolu

Negative. This would be an entry you put into the Model Interior XML file. See above. You need to customize it to the name of your screen ‘part name’, and then modify the name of that code block to be similar to what you have. NO spaces in the names.

Bill
LHC

[SWS-AlexVletsas]

Adding some feedback regarding screen dimming. Testing on our PC-12 with the latest FS2024 Dev Alpha update (1.0.84.0) the screen brightness at night is working well but at daytime some gauges are dim.
You can see the EFIS works fine, but the altimeter doesn’t. Differences:

	EFIS50	Altimeter
Template used	ASOBO_GT_Emissive_Gauge	ASOBO_GT_Material_Emissive_Code
EMISSIVE CODE	(A:LIGHT POTENTIOMETER:#POTENTIOMETER_SCREEN#, Percent over 100) 0.05 max	(A:CIRCUIT ON:#CIRCUIT_ID_AVIONICS_1#, Bool)

@EPellissier
Comparing the XML templates in FS2024 (left) and FS2020 (right), the IsVersion Parameter doesn’t exist in 2020, but I don’t think that is a problem.

There is though a different set of parameters for Automatic Brightness. Is there a chance the AMBIENT LIGHT SENSOR simvar is causing the problem? In that case, making the same check for IsVersion=“2” and using the old (A:GLASSCOCKPIT AUTOMATIC BRIGHTNESS, Percent over 100) may solve the problem.

[cdgonzalezgo]

I found a workaround for the GNS530/430 inconsistent screen dimming, if you want to use it.

NOTE: For the following to work, and if you are relying on the standard AS530/AS430 templates, you must have the AS530_Screen_1 or AS430_Screen_1 named as is on your 3D model, or ending with whatever the ID is and prefixed with whatever the <AS430> template parameter is named on your code (e.g.: if <AS430> is overriden and named like GNS430W or something else, different from the standard naming, and the <ID> is 1, then your screen node on both the XML and the model must be named as GNS430W_Screen_1; again, for the sake of understanding how the node must be named). In my case, I have the standard naming conventions, so I use the screens’ node names above.

Well, after researching the AS530/AS430 template code, I found inside two L: vars called (L:#AS430#_ManualBrightness_Enabled#SUFFIX_ID#, bool) and (L:#AS430#_ManualBrightness_Value#SUFFIX_ID#, percent over 100).

You can enable the manual brightness, hence fully overriding the use of the (A:GLASSCOCKPIT AUTOMATIC BRIGHTNESS, percent over 100) simvar. So, you can set the BOOL local var on aircraft init, and play with the value Lvar on code (if you want to set it through a knob or something, or you can preset the emissive value on flight init, just like I did):

<Component ID="Init_Callback">
    <UseTemplate Name="ASOBO_GT_Update">
        <UPDATE_ONCE>True</UPDATE_ONCE>
        <UPDATE_CODE>
            (* Rest of code omitted here *)
            1 (&gt;L:AS530_ManualBrightness_Enabled_1, bool)
            1 (&gt;L:AS430_ManualBrightness_Enabled_1, bool)
            1 (&gt;L:AS530_ManualBrightness_Value_1, percent over 100)
            1 (&gt;L:AS430_ManualBrightness_Value_1, percent over 100)
        </UPDATE_CODE>
    </UseTemplate>
</Component>

The above is assuming you have the template’s standard naming conventions. But, if you have a different ID (like 2, for example) and an overriden AS430 template name, like on the example above (GNS430W), you must then replace to the corresponding values, like this:

1 (>L:GNS430W_ManualBrightness_Enabled_2, bool)
1 (>L:GNS430W_ManualBrightness_Value_2, percent over 100)

Using this helped me to maintain the GNS screens’ brightness consistently and does not dim anymore. This worked like a charm for me on both sims 2020 and 2024. I leave this in case you want to give it a try.

Regards,
Carlos Daniel González Gómez
NextGen Simulations

[bagolu]

Problem still occuring in 1.0.87.0
(ok by night, unusable by day)

[ScorpionFilm422]

Hi Eric,

It does not look fixed in the release.
Any plan to fix it soon?
Many screens are not usable.

Best regards
Pierre
PMS50

[NightMercury358]

Agreed… Or just tell us whats changes so WE can fix things

[LyonHaart001]

In the past couple of days, I tried fixing mine. Some work, some do not.

Bill
LHC

[MariopilotPD808]

Attempted a number of things. It mostly works, but I have to fine tune the values.
Everything points at just setting the emissive to a fixed value of 1 .
To be confirmed when I manage to load into a flight again …
Investigating the GLASS COCKPIT AUTOMATIC BRIGHTNESS SimVar, I found out that it is rather useless. It only outputs 1, 0.35 or 0.15. My hope was that it will smoothly vary with time, so that we would not get a sudden change as with the use of the Env Variable TIME OF DAY, ENUM.

Also, it behaves exactly the same in MSFS 2020.

[LyonHaart001]

@MariopilotPD808 , can you post your template? I would be grateful.