I’m trying to build a client application in C# that works with both 2020 and 2024, but I’m running into an issue with the FUELSYSTEM TANK … vars.
If I register a struct to track them but the aircraft doesn’t support it, this exception spams the SimConnect Inspector. In 2024 though, it’s supported on the same aircraft (172 G1000).
I really don’t want to have to manage that logic in my client, and I want it to work with both sim versions, so here’s my questions:
Is it possible to prevent this from spamming?
Can I detect it and avoid it at some point during runtime? Perhaps unregistering a data definition for just those simvars?
Is there any harm in letting it spam? Will it eat up resources in any fashion? Will it eventually stop spamming?
I also raised a bug or change request on this. I have heard nothing since…!
The only way I know of is to first request and check the value of the NEW FUEL SYSTEM simvar, and only request these variables if the new component system is being used. Unfortunately this is not possible in my app, and I would like Asobo to address this issue - just one message and not continual spamming would be sufficient!
Again, not that I know of. The problem is that you do not get an error when requesting these variables, as they do exist, but just not in aircraft that use the legacy fuel system and not the newer modern component fuel system.
Yes, this does cause issues. As so many messages are logged, this can cause quite severe stutters / micro-stutters.
Note also that this is not an issue between 2020 and 2024, but an issue with requesting variables used in the modern component fuel system with a legacy aircraft that uses the legacy fuels system.