The AMBIENT LIGHT SENSOR simvar appears to always return 10000 regardless of the actual ambient lighting conditions in SU1 beta. It works perfectly on the retail build of the sim.
This simvar is extremely useful and finally allowed us to implement a decent automatic display adjustment for those using our aircraft on MSFS2024, but it’s now broken in the SU1 beta.
Repro steps:
Spawn in either the A32NX or A380X (available freely from https://flybywiresim.com/) and read the simvar in the SimVarWatcher or behaviour debugger.
Can you please confirm whether the aircraft you were testing against were coming from an MSFS2020 package or an MSFS2024 one?
The value you are reporting would be the default one for aircraft stored in an MSFS2020 package - because this SimVar does NOT exist in MSFS2020 and hence should never be queried by an MSFS2020 aircraft.
The packages are indeed built with the MSFS2020 builder/manifest. We are steadily adding MSFS2024 compatibility but for a variety of reasons it’s not possible to switch fully to 2024 for the time being. If new simvars are going to require an MSFS2024 exclusive package it will be a lot longer before we can embrace 2024. It is especially unfortunate that it stops working in a sim update.
I would agree that it’s quite a needed variable - can we at least have its value in another variable that wouldn’t clash with MSFS2020 SDK so it doesn’t break backward compatibility? something like AMBIENT_LIGHT_SENSOR_2024
An MSFS 2020 package is supposed to run under MSFS 2020 - how could it be the case if the said package is using an MSFS 2024 exclusive SimVar (or any other MSFS 2024 exclusive feature)?
Although it works differently than “AMBIENT LIGHT SENSOR” on the 2024 platform, you can use “GLASSCOCKPIT AUTOMATIC BRIGHTNESS” on the 2020 platform.
Am I right to think that you are just trying to keep the 2020 LOD selection mechanism while using some 2024 specific features? If that’s the case, please note that this is unlikely to work - as you know we provide backwards compatibility for 2020 packages (including LOD selection), but we never planned for a 2020 package to use 2024 specific features (for the very reason stated at the beginning of this post).
Happy to discuss further if there’s another reason outside of the LOD selection system.
Not sure how this is relevant - there was no automated LOD pipeline in 2020 and yet many 2020 packages include LODs. Anyway your comment doesn’t answer my initial question (and obviously it wasn’t aimed at doing so) - are there any other reasons to the OP question than wanting to keep the MSFS 2020 LOD selection system?
We haven’t gotten far enough to know if there are any LoD problems. The main issues stopping us producing MSFS2024 packages at the moment are our installer that users use to install and update the aircraft is not ready for two sims, and our CI pipeline that builds all of the packages is not ready. The CI and its automated builds is essential for a large project with dozens of contributors, many unaffiliated. We can’t switch to 2024-only because a large proportion of users have not, and also because there are still some pain points with 2024; for example our flight model guy says his work takes an order of magnitude longer doing package rebuilds rather than quick reload.
What I am trying to do here is implement as much new 2024 functionality as I can while all of the other stuff falls into place, then we can hit the ground running when that happens. The LoDs are now a concern as we are still using the old Asobo A320neo 3D assets and don’t have the source files for them, so we are very limited in what we could do to address that…
As written in my original answer: “an MSFS 2020 package is supposed to run under MSFS 2020”. Hence speaking of “the integration of the EFB”, which is a 2024 feature, in a 2020 package doesn’t really make sense and is not officially supported.
If you want your aircraft to support the EFB then it has to be a 2024 aircraft in a 2024 package - I understand it means a lot of additional work on the art side (materials & LODs), but we currently cannot support mixing features like this.
