it should, but with the T-45 Goshawk that I just purchased today in the MS Marketplace (which has a tailhook and a canopy that can be opened) I am always getting values 0.0, regardless of whether the tailhook has been lowered or whether the canopy is open.
Quite possibly that airplane is not setting those variables properly (yet), or they simply don‘t work at all yet in FS2020.
I also tried with the example SimWatcher app, with different metrics (percent, percent over 100, number, even degrees… the values remain at 0.0).
Not sure whether other airplanes with a tailhook exist in FS2020 (*) but maybe someone has had luck with opening canopies?
(*) I just read that the F-15 does have a tailhook as well, for emergency landings on land - but not sure whether the F-15 in FS2020 has a functional tailhook. I guess so?
Haven’t had anything with a tailhook, but the canopies of the Spitfire, the MB339, the G.91 and the P.139 all work through the virtual cockpit. Each has contact points at the original handles, levers, knobs and buttons
I am not sure whether I understand your answer (or whether you understood my actual question ;)): the tailhook and the canopy of the T-45 Goshawk (by IndiaFoxEcho - who also provided the MB339 earlier) do work within Flight Simulator: that is, the tailhook properly is lowered and raised (visually), and so is the canopy (open, close) when I operate the corresponding handles in the cockpit, with the mouse.
But the problem I have is that this is seemingly not reflected by the corresponding simulation variable states, namely the variables TAILHOOK POSITION and CANOPY OPEN: according to the MSFS SDK documentation (linked above) they should work, but I always get values 0.0 back - also with the provided SDK example app “SimvarWatcher”, regardless of whether I set the metrics (unit) to “percent over 100”, “percent”, “number” or even “degrees”.
So are you implying that you do get values > 0.0 for the CANOPY OPEN variable (e.g. with SimvarWatcher), e.g. for the Spitfire? Because that would probably also imply that the T-45 Goshawk implementation simply does not properly set those variables (yet) (-> I have also a pending question with IndiaFoxEcho about this, but yeah, on their facebook announcement post. I have yet to find a proper contact address ;)).
Otherwise it could simply mean that FS 2020 - despite claiming otherwise in the SDK documentation - simply does not support yet the TAILHOOK POSITION and CANOPY OPEN variables.
Again, I’m interested whether others were successfully reading (and setting) those variables with other aircraft, or whether anyone can confirm the same observations (with the same T-45 model or with other aircraft even).
Interestingly there is also a TAILHOOK HANDLE variable, but that one is described under “Carrier Operations” as:
“True if the tailhook handle is engaged.” (read-only)
So I assume that the “handle” here refers to some “handle” on an aircraft carrier, and hence is of no use here (and anyway, it is read-only and also returns 0.0).
Hmmm… this is an interesting development: I actually just tried to set a value - in this case the CANOPY OPEN variable, with value 100 (number).
And lo and behold: the CANOPY OPEN value quickly showed a value of 100.0, but it quickly (within seconds) diminished back to 0.0 again.
BUT: after a couple of attempts I then noticed that the TAILHOOK POSITION value has the (expected, according to the tailhook position in the simulator) value of 100.0:
HOWEVER: now setting back the CANOPY OPEN (!) variable to 0 sets - in fact - back the TAILHOOK POSITION to 0. Setting CANOPY OPEN back to 100 sets the TAILHOOK POSITION variable to 100.
But the (visual) tailhook in Flight Simulator is unaffected: it remains lowered all the time.
So - does not work. This reminds me of my recent experiments with the “Light” switches (taxi light, landing light etc.), as described here:
There it also seemed that setting some light variable actually toggled “the last successfully set” (which includes “operations with the mouse in the cockpit”) element. At least the “Lights” variables are (still) declared as “read-only” in the SDK documentation…
So to me it seems that both CANOPY OPEN and TAILHOOK POSITION variables are still not properly implemented within FS 2020 itself.
Can anyone confirm my observations here? Of course all this is with the current FS 2020 (“Sim Update 3”).
UPDATE: Doh! It seems that the SimvarWatcher example actually tries to modify the selected row in the right-hand side table (and not the variable as selected in the Simvar Name combobox!):
Setting the CANOPY OPEN variable to 100 quickly sets that value, but the value decreases back to 0.0. within seconds
Setting the TAILHOOK POSITION actually works (the value 0.0 or 100 is “persisted”), but…
… in any case no visual impact is observed in the simulator itself: both the canopy and tailhook remain at their position (including the tailhook handle in the cockpit of the T-45).
Thanks for the elaboration. But since I have never had used the SDK I guess I really misunderstood your question and I also can’t help you. Sorry for wasting you time
And you don’t happen to have access to the MSFS SDK (downloadable via the “developer mode” within FS 2020) by any chance?
Because if you did - and if you actually own the F-15 in FS 2020, that is - could you confirm whether reading the CANOPY OPEN and TAILHOOK POSITION variables actually works?
You could copy & paste the following content into a file, e.g. named tailhook.simvars (any file name will do, of course):
CANOPY OPEN,percent, 0
CANOPY OPEN,percent over 100, 0
TAILHOOK POSITION,percent, 0
TAILHOOK POSITION,percent over 100, 0
and then open that file with the “SimvarWatcher” example application:
Run FS 2020
Start a flight (with the F-15, or any aircraft that has at least a canopy that can be openend, e.g. the Spitfire)
Load the *.simvars file (created above)
Click the “Connect” button in the SimvarWatcher
Open and close the canopy (in FS 2020)
Lower and raise the tailhook
Those changes should be reflected in the variables CANOPY OPEN and TAILHOOK POSITION (in SimvarWatcher)
The SimvarWatcher example application is located at
It’s possible that the developer of that plane is using LVARs to control the state of the animation and not the legacy sim vars. You can open the model xml files to see what’s driving the animations.
I am working on a plane and tried to control the doors with the EXIT OPEN and interactive points but couldn’t get it to work. But with LVARs, it was easy, so I’m sticking with that for now.
Hmmmm… LVARs you say. I must confess that I only got started with the SimConnect API a couple of weeks ago and that I have not yet looked at any other part of the MSFS SDK at all.
So I actually had to lookup the term LVAR (“local variables”), e.g. here
“LVAR (correct would be L:Var) are Local Variables that only exist in the simulator itself and are not accessible from the outside via SimConnect.”
Okay, so I understand that “local variables” may be easier to use (or “make things possible” in the first place) within the flight simulator than what is known as “simulation variables”. And they are not accessible “from outside” (hence the name “local”).
But I would still expect - from the flight simulator, not necessarily the aircraft provider - that the state (value) those local variables be at least reflected in the “official SimConnect API”, namely the corresponding simulation variables. Or can a developer define his/her own local variables (which would make it nigh impossible to map them onto the corresponding SimConnect simulation variables)?
And what I am not quite clear about: why are you calling the “simulation variables” (as exposed via the SimConnect API) “legacy”? Do you have any source for that? I know that (most? all?) simulation events have just been declared legacy (see my other question about events here and the official MSFS SDK documentation), but the simulation variables themselves? That would render the entire SimConnect API a legacy API (and what would be the replacement?).
Anyway, I actually had a look into the T-45 directory and quickly searched for the term “tailhook”. I did not find anything within any XML file, but several *.cfg and *.flt files turned up.
Are those local variables (and the corresponding simulation variable would be TAILHOOK POSITION)?
Thank you!
UPDATE: The XML files you were referring to are probably packed (archived) into Xml.fsarchive (and similar archives) and are hence not accessible to me (the content is binary and possibly even encrypted - did not bother to look at its content with a HEX editor ;)).
I just got confirmation from the developer IndiaFoxEcho that they indeed use L:vars for the canopy and tailhook animations.
So those values are not (yet?) reflected in the corresponding simulation variables CANOPY OPEN and TAILHOOK POSITION, unfortunately. At least not for the T-45.
For the record: the CANOPY OPEN simulation variable does indeed work, as observable with the free Alpha jet here:
(which has a working canopy, readable/writeable via SimConnect).
It’s just like the T-45C aircraft developers decided to use “local variables” instead, but the Alpha jet proves that at least for the canopy “simulation variables” would also work.
I have yet to find an example for a working (= accessible via SimConnect / simulation variables) tailhook though…
Steeler is correct about the canopy, and you can verify that it works using Lorby Axis And Ohs to map a key to the TOGGLE_AIRCRAFT_EXIT. However, if you map a key to either of the two relevant tail hook events - TOGGLE_TAIL_HOOK_HANDLE or SET_TAIL_HOOK_HANDLE, they will not operate the tail hook as they should.
However, the A:TAILHOOK POSITION variable is implemented in MSFS. I have written the following script and mapped it to a key in Axis And Ohs, and it will toggle the position of the tailhook in imported FSX aircraft. It does not always do a smooth animation (depends on the plane), but it at least switches between full down and full up.
