plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.

Please take a moment to read the platform’s guidelines before you get started!


Steeler avatar image
Steeler asked RXP edited

SimConnect: simulation variables not writeable: CABIN NO SMOKING ALERT SWITCH?

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"):



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.

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

FlyingRaccoon avatar image FlyingRaccoon ♦♦ commented ·

The new Simvar Watcher should look like this.


It should already be available with the v18. What's the date of last modification of your exe?

0 Likes 0 ·
1653392785541.png (22.9 KiB)
Steeler avatar image Steeler FlyingRaccoon ♦♦ commented ·


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:

0 Likes 0 ·

1 Answer

FlyingRaccoon avatar image
FlyingRaccoon answered RXP edited

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:


10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Steeler avatar image Steeler commented ·

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:





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 ;)

0 Likes 0 ·
FlyingRaccoon avatar image FlyingRaccoon ♦♦ Steeler commented ·
@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.


0 Likes 0 ·
RXP avatar image RXP FlyingRaccoon ♦♦ commented ·

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)


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?

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.