I just tried the SimvarWatcher (SDK example application, in the latest MSFS SDK 0.12.0.0 ) and immediatelly noticed that the application crashes as soon as I try to load a set of simulation variables, via “Load File”. No error dialog is shown, the window simply “closes” after a short while.
I guess the format of the *.simvars file has changed, but it is a pity that the provided *.simvars (C:\MSFS SDK\Samples\SimvarWatcher\Simvars) were not updated then?
The “crash” happens regardless of whether the SimvarWatcher application is connected with FS2020 or not.
Arrrr… and it seems the “index” value parsing is also not working anymore, e.g.
GENERAL ENG THROTTLE LEVER POSITION:1,position,False, 0.0
While “interactively” adding this variable (for “engine 1”) in the SimvarWatcher example app works as expected (= the value changes depending on the throttle lever position) storing that example into a file (which yields the above entry) and then trying to restore that same file somehow “drops the engine index” (the “:1” part):
The index :1 is then gone and the value hence remains always 0.0.
The SimvarWatcher example app has lost quite a bit of its usability like this
P.S. Unlike with the above missing boolean attribute here I don’t see a quick workaround (except of course to install some C# SDK and go and fix the app myself - any volunteers? ;))
… and not a word abou it in the release notes…
Got to be very patient with this guys.
Wonderfull results when it is working
Bad design overall
You pay for the software , yo do not really own anything but “the right to try it out”
It is what it is
I suppose my own developed app in c# ( by the book of course) will not be compatible either … A real mess this people.
Greetings
Is your application actually reading that “ad hoc” (well, CSV) *.simvars file format as well? If not, then there is nothing to worry (or complain) about…
ok. lts hope it is like that. Thank you for your comment.
I am using “Stock” definitions for Request and Events, as per Simconnect documentation calling them directly from C#.
I will surely check, ones my Software is ready to run again… several hours still to complete the “totally unbearable and absurd” update process…
Have to download AND read the update for the SDK too.
I will eventualy report back if that would help anybody
Oh my…
How indecent of mine…
You probably should ask moderators to totally delete what I have written.
You know… somebody , apart from you, could get hurted…
And no , I am not a “Developer” , I just develop sofware for amusement.
And maybe, just maybe, I did not fully understand the implications or the origin of the problem stated here.
And , finally , the update process still is “Absurdly wrong” and a waste of user resources
My appologies if I somehow insulted you , the developer forum or whatever
Maybe so. But you definitely opted for an aggressive maneuver, this time absolutely and with no doubt going off topic in your own threat, considering it was appropiate to just swiftly execute this one childish soul ( I am 63 ) polluting your supposed sacred “Developers nest”
I early loaded, run and studied the “SimWatcher” example provided within the SDK , previous update.
It did not showed any problems at all , except that the option to “Set value” did not worked for me. ( I got it working ok in my apps ).
Your title captured my attention because I , mybe inexcusably wrong, atributed the crash to other many “crashes” reported by users after this last update ( wich continues to download on my side, no oportunity to check yet ).
And last, being a “developer” does not put you in any position to rev up your engines and go attack somebody wich apparently is not. An interesting job, for shure. Just that,
I will not ventilate my CV , on the other hand.
And excuse my bad english , it is not my original tongue. I just happen to speak an Write English, German and Spanish. And as the rule in this one forum is English, I try use it in order to practice and communicate my thoughts.
The original line 554 of file SimvarsViewModel.cs (commented out in the code above) is attempting to determine if the third array item indicates the SimVar expects or returns a string value.
The code used is assuming the third element of every CSV entry (if a third element exists) will always contain a boolean value (it doesn’t, it’s usually numeric).
Replacing the line of code with the 3 lines in the image (replicated as text below for ease of copy/paste) will correct this and fix the problem of the app crashing.
// bool bIsString = aSubStrings.Length > 2 && bool.Parse(aSubStrings[2]);
bool bIsString = false;
if (aSubStrings.Length > 2)
bool.TryParse(aSubStrings[2], out bIsString);
Yes, and it does so by assuming that the 3rd value (indexed with [2]) is now a boolean - which is exactly the newly introduced “is string” property (which now allows to also query “string” simulation variables, which has been newly introduced with this “release”).
And since the *.simvar files that still ship with the SimvarWatcher app are still “in the old format” (they do not have a boolean respectively only have 3 instead of the expected 4 values per entry) the new parser now crashes (presumably by reading “over the end of some string buffer”, trying to access an element which isn’t three or so…).
So either one “converts” the old *.simvars files by adding a boolean, or adjusts the parser, like you just did.
But in either case a change is necessary, and that’s what I meant with "the problem relates to the format of the shipped *.simvars files: either one adapts the parser to properly check the amount of values, or one simply converts the shipped *.simvars files accordingly (and fixes the parser not to “go out of bounds”)
In either event, converting the file or modifying the code is something we shouldn’t need to do, as the code is supplied as examples of working solutions using SimConnect, and it should just work.
Thankfully, there’s not a lot of effort involved in either (load the *.simvar files into a spreadsheet to manipulate and re-save, or modify the code to work with either version).
Although experienced developers won’t have a problem doing either, it would give the wrong impression to someone just starting out in MSFS 2020 or not familiar with C#.
I’d suggest adding a bug request to Zendesk (if you haven’t already), although it’s trivial, if they don’t know about it, it won’t get fixed.
We fixed an issue where the simvar index was lost when loading a file.
Seems like they do take ZenDesk tickets into account every then and when
However I understand that this fix will be part of an upcoming SDK, correct? I checked and the last available SDK version (available via “Dev Mode”) still seems to be 0.12.0.
Not the end of the world, but still…
