Dear all, Hello, I am the author of a flight replay/recording software, and
finally do have some questions for the fine forum here 
According to the
SimConnect API
documentation
the following simulation variables should be writeable (“settable”): -
CABIN NO SMOKING ALERT SWITCH - CABIN SEATBELTS ALERT SWITCH I tried
setting values 0 and 1 (which work with other boolean simulation
variables). However trying to set them with the SDK example “Simvar Watcher”
() fails (the variables are properly updated in the Simvar Watcher
however), with “data error” (or the like). I tried setting its type to
both “number” (which essentially always works with most other simulation
variables) and “bool[ean]”, but always the same “data error” (and neither any
change in the cockpit nor in the actual simulation variable value). I must
admit that this made me stop with further experiments, that is, I haven’t
actually tried to set those variables from within my own application,
expecting this to equally fail with “data error”. Is there anything I am
overlooking here? I hope Asobo won’t simply fix this by adjusting the API
documentation, but rather to fix the server, in order to make those simulation
variables actually “writeable” 
Or has anyone succeeded in modifying those
alert signals, perhaps via events (which I’d like to avoid, as I prefer to
alter states via setting the corresponding simulation variables)? () By the
way, what happened with the announced “updated Simvar Watcher” example app,
did I miss it? The one with “searchable simulation variables” dropdown list
and what not. It was announced with SU 8 already, then some follow-up news
indicated that “oops! We forgot to ship it!” and now we are at SU 9 already, I
have the (seemingly) latest MSFS SDK installed (0.18.0 - as installed via the
“developer mode” in MSFS) and no updated Simvar Watcher to be seen.
Hello @Steeler This is a mistake from the documentation, these 2 simvars are
not writable. @Nocturne will fix the doc. Instead, you want to use the
corresponding key events: KEY_CABIN_NO_SMOKING_ALERT_SWITCH_TOGGLE
KEY_CABIN_SEATBELTS_ALERT_SWITCH_TOGGLE
https://docs.flightsimulator.com/html/Programming_Tools/Event_IDs/Aircraft_Misc_Events.htm
Regards, Sylvain
The new Simvar Watcher should look like this.
with the v18. What’s the date of last modification of your exe?
Hello, Thanks! Indeed, I found the pitfall I fell into: in short, the Simvar
Watcher comes with a separate “Samples” download, and either I forgot about
that, or the SDK once included everything in one single installer package.
Anyway, I wrote my answer about it in a thread which is actually about this
Simvar Watcher example program:
<https://devsupport.flightsimulator.com/questions/6028/simvarwatcher-not-
updated-017-sdk-per-release-note.html?childToView=8298#answer-8298>
Hello @FlyingRacoon Well, I was hoping you would fix the SimConnect “server”
instead of the documentation Here is my point: those “toggle XYZ events”
are not very useful to me (my “recording & replay” application). Why? First
off course I record the state of any simulation variable that I am
interested in (essentially those which either control the flight path and/or
have otherwise a “visual impact” on the model, like moving flaps and gears,
but also cockpit elements like the rudder peddals, yoke, thrust lever etc.).
So at any given time during replay I know what the value of any given
simulation variabe (that I previously recorded) should be. And the easiest way
to do so is simply to “set” (“write”) the corresponding simulation variable
state - which off course implies that the corresponding variable must be
“settable” in the first place. Now you proposed to use “toggle events”, but
here is the “problem”: I need to know the current state of the variable in
the flight simulator (“server-side”) before toggling it to the desired
value. So essentially before every change that I recorded I would have to: *
First make an (asynchronous) request to get the current state of, say, the
CABIN_NO_SMOKING_ALERT_SWITCH * Wait for the reply * Compare the received
state against the expected one, and if they differ, trigger the
KEY_CABIN_NO_SMOKING_ALERT_SWITCH_TOGGLE event (I could limit this to only
make a request at the very beginning of the replay, you might say. But the
user might toggle the cockpit switches during the replay, too, and I would
again have an “inconsistent state” between client and server) Yes, I agree,
this is not an “unsolvable” problem, but it unnecessarily complicates my code.
Especially given that most other variables are actually writeable. And also
given that there must be code already in place somewhere which allows to
change the state of the CABIN_NO_SMOKING_ALERT_SWITCH (via events). So why not
simply call this same code whenever you receive a “write” on the
CABIN_NO_SMOKING_ALERT_SWITCH? Or did I miss a way to actually be able to send
an actual value - as parameter - with the “toggle” event? I don’t think so,
otherwise we wouldn’t have events like: * SMOKE_OFF * SMOKE_ON * SMOKE_SET *
SMOKE_TOGGLE Jeez Or are you saying that each event implicitly supports
OFF, ON, SET and TOGGLE operations (I must admit I am rather new - 1+ year -
to the SimConnect API and so far did mostly everything with “writeable
simulation variables”)? And it actually seems that (some) events actually
support parameters, like the SMOKE_SET, which takes a 0 or 1 value (according
to the documentation). I understand, you “inherited” an API with “lots of
legacy” and functionality was “incrementally added” over the decades. And IIRC
the whole event system was even deprecated in the API documentation at some
point in time, because you must have realised, too, that having “writeable
simulation variables” and “events” is essentially redundant So here is my
suggestion (wish): * Simply make every simulation variable “writeable” ,
at least all those for which a corresponding event already exist I do
understand that it doesn’t make sense to write every simulation variable, as
some variables are “read-only by nature” (e.g. the outside temperature etc.).
But anything that is “clickable” by the user in the cockpit should be
“writeable” via simulation variables as well. Or again, at least those for
which a corresponding event exists already. This would make your documentation
live much easier, too, I guess
@Steeler That’s right, it’s a bit painful since there are no ON/OFF/SET events
in this case. We will add those events then, I have added a task for this in
our backlog. We opt for events rather than making simvars writable directly so
that the key events can show up in the control options menu and be remapped.
Regards, Sylvain
I have a question regarding these events: what is the purpose of ON/OFF/TOGGLE
events in practice, in addition to the already existing SET ? Since every
single actionable can use RPN logic at least, or are emitted from code, can
you explain in which situation these specific events could be more
appropriate, vs for example: ON: SET (1) OFF: SET (0) TOGGLE: SET ( GET() ? 0
: 1) etc… And corollary to this, is there any event with a ON/OFF/TOGGLE
variant but without any SET, in which case, do you plan to add all the missing
SET variants too?