Marketplace package name: bfg-super-decathlon, bfg-navion-twin, bfg-navion-b, bfg-navion-l17b - All most recent versions
Context: Mounted from community 2024
C:\Users\MYNAMEHERE\AppData\Local\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalCache\Packages\Community
Similar MSFS 2020 issue: I haven’t seen this other than the dev stream and on here in this forum, fixes are out, but not sure on the implementation to backwards compatibility and I just wanted to make this known if it wasn’t already.
Bug description:
PMS50 GTN650/750 screen illumination on all 4 aircraft is very dim during the daytime and on the highest brightness settings. All other avionics are normal brightness except the KAP140 on the Camair 480 Twin and Navion B also have this issue. During night time operation the GTN’s & KAP140 are normal(better) brightness.
Repro steps:
Starts around 7 AM local time(Sunrise) and ends around 7 PM local time(Sunset) Attachments:
Mid Day
The only other issue I am having with 2020 backwards compatibility in 2024 is in any of my airplanes that have my smoke FX and the position of the smoke trail for the Navion L-17B/D and Super Decathlon. In 2020 The smoke position is coming from the exhaust a few inches away. In 2024 the smoke FX is located where the actual node is located. I had to adjust the location in 2020 to have it come from where it should be. It seems in 2024 the location is exactly on the node and is located inside the plane.
Also to note the FX for the exhaust heat blur has since been fixed, I used the original SDK version and the 1st release of dev alpha and it was also too much, but has been considerably fixed to that of 2020 thank you. If this is supposed to be reported somewhere else please advise.
For the screen emissive issue, you should implement the Asobo_GT_Emissive_Gauge template in the screen node of your model, and also override the <EMISSIVE_CODE> parameter to a value (or code) of choice, preferably set it to 1 or something, so that you invalidate the default value controlled by the (A:GLASSCOCKPIT AUTOMATIC BRIGHTNESS, percent over 100) simvar, which is causing that issue in MSFS 2024.
This is a workaround I found, since I also had the same issue with my EMB-110, where the WT GNS displays were also rendering so dimmed at day but bright at night. The other HTML/WASM digital instruments did not suffer from that situation because I overrode the EMISSIVE_CODE parameter value on each 3D nodes affected.
That issue was also reported previously (see below):
Regards, Carlos Daniel González Gómez NextGen Simulations
this wouldn’t work in MSFS 2020 as that variable is exclusive to MSFS 2024… is not a solution we can implement as we are supposed to have products that work on both platforms with 1 code base.
Once we fully convert to MSFS 2024 standards, that’s another matter.
That is actually wrong, Raul (@SimbolFSReborn).
Please take a look to the AS430 XML definition from MSFS 2020, as well as the 2020 SDK documentation. That simvar is defined in 2020 as well. Please see below:
And by the way, what I found was a guess from my point of view, it might be something else, but what I did cured the issue on my side. So, it is up to you (the developers) if you want to patch it that way while Asobo reviews what went wrong.
Regards, Carlos Daniel González Gómez NextGen Simulations
I will give this a go and see how it works. Thanks for the reply.
One thing to mention though is what about the other planes that maybe someone hasn’t tested yet and they don’t know this is an issue. It still needs to be raised if we truly want 2020 planes to fully function like they are now in 2024. I’m aware of other issues and willing to look away at some of those as they are cosmetic, as is this, but I would think this would get priority as it’s functionality is somewhat paramount to user experience. My next question would be as to why is it not like this in both simulators as it might be part of another issue we are unaware of yet.
Yes, this is true. This needs to be raised to Asobo. The FX issue you are experiencing should be reported on a spearate post, however.
@FlyingRaccoon@Boris@EPellissier: guys, do you know if this screens brightness issue can be fixed for the 2024’s final build, without having us to perform code updates, and also considering what @B4Gunner stated at first for untested content, especially for other 3rd-party developers around that do not have access to the Dev Alpha? Also, can you give us an answer to the other concerns @B4Gunner asked in the reply above?
Thank you.
Regards, Carlos Daniel González Gómez NextGen Simulations
As suggested by @cdgonzalezgo, could you please make a separate post for your VFX issue ? Please include more details in it regarding what you had to do to “adjust the location in 2020” (<FX_OFFSET_X/Y/Z> in modelbehavior xml ?).
So, I guess the question is… It was stated that 2020 aircraft would work in 2024 without modification. Is this requirement now gone, realized as being technically infeasible?
What I’m seeing is authors changing their planes so they can function in 2024 and having to provide updates.
What was originally understood was that the planes, assuming they were developed in tune with the SDK, would work without modification. It seems like, with examples like this, that’s not possible.
I totally understand if the concept is unfeasible, knowing what I know about how development was done in the past, it seemed like that would be impossible, but I was impressed that the attempt was made.
In any event, a statement regarding whether authors should give up on hoping their planes will work without modification in 2024 should be made, to both the development community and the userbase, so customers can realize how much work authors are going to have to do. I feel bad for the authors because of the sense of entitlement customers tend to have, without realizing how many hours are spent in development.
Please don’t take this as a complaint. I totally realize how hard it was to accomplish this goal.
Its actually quite easy with that code from Raul. Just find the names you used for the screens(model) and make a component/template for each. I have this work around for both my PC and XBOX version of the Super Decathlon going out hopefully within a week or so to Official Marketplace. I also made the 2020 changes to my GTN from PMS50’s new code for the HTMLUI and the Xbox In Game Panel and it works just fine now.
For the users of my aircraft I want them to have the most up to date features that I can have for my planes for both 2020 and 2024 so I can move forward with new features being added and then on to the next project.
I’m using the 2020 version in the 2020 upload that is compatible with both 2020/2024. When I go to do the planes native to 2024 I’ll be using the 2024 specific code with the G3X using the new V2 that syncs the GTN’s with the new EFB. I’m already in the works to converting to native on the Super Decathlon and excited to get the new Banner Towing with missions implemented.
Oh, I wasn’t questioning how hard fixing the issue was…
Users are waiting for their 2020 planes.
In order for that to happen there are two solutions
Asobo can fix all the bugs in compatibility mode. Then the planes will just work
Developers can update their aircraft to make them work with what is (see above).
1… that’s a lot of work for Asobo, on top of all the other work they have to continue to develop 2024, and it’s backwards work, work that won’t be needed in the future
2… means developers need to fix their planes and release them, which is a lot of work for the them and the Marketplace (but, distributed among many parties, which is nice, with a bottleneck at the Marketplace).
So I was just wondering which is the most efficient path for all parties and for the sake of the codebase itself?
My take on it is fix it myself and not wait for Microsoft. Let them worry about bigger better things. Who knows when they will get to it. Let the Marketplace handle the bottleneck and have priority would make sense. I’m pretty sure I’m not alone in thinking this way as a developer and I’m not waiting around to get my native products started/finished for 2024 while the hiccups will eventually wash out. I doubt this fix will need to be returned to as it works in 2020 now as well just the same.
I agree. But, there are forces beyond my ken, and considerations I’m unaware of, so, I thought I’d ask the question.
Seems to me it’s best if a commitment to one or the other is made, though there is room for a mix of things, fix some stuff, but move on and update planes in general.
Your solution of developers fixing things certainly alleviates a lot of work Asobo is currently committed too. Right now, though, they’re living with a commitment that all 2020 planes should work as is. That’s a lot of pressure.
