Oops! I’d better pay attention to announcements! 
Thank you for letting me know! 
My first duty station in the Navy was an F-14D squadron. I would love to have this addition to MSFS. Also, can the TARPS pod be added? Even non-functioning, it would be a nice addition.
And if you could somehow add the TARPS pod with the cameras working, and allow players to simulate reconnaissance missions…
TARPS would almost certainly not work in MSFS at this time, but the D model is likely to happen in the future as quite a lot of folks have asked for it.
Hi Dean,
I was just wondering if you may be able to shed some light on something, please accept my apologies if already answered.
For a fair while now there has been an issue when in multiplayer that landing gear doesnt update on planes that are not yours. I see that in the recent Dev Q&A they have acknowledged this is a bug that needs resolving.
I played with my brother yesterday just to test things out, both in the F14 B. The way things currently work at the moment is that certain functions such as the canopy opening are mirrored for both planes based on what the hosts plane is doing on their particular game.
I think maybe how the L:VARS work?
I was just wondering if you may know if the issue with landing gear not updating was a seperate bug or whether it may be tied to the way L:VARS function and not a particularly easy fix?
I can answer this for you. LVARS are local variables, so they are not recognized in multiplayer by other players. However we are working on indentifying which simvars are compatible in multiplayer for these animations to play. the flaps for example would be valid but it would force us to make a lot of structural adjustments in the flight model since they simulate the effects of sweep wings as well as the maneuverable flaps and slats of the f-14. But we are on it.
Thanks Jack. I did notice that when two of us were using the F18 I could see flaps and lights operate independently of one another but the landing gear sadly would not.
I only tested very briefly with the F14 but as you very kindly noted I imagine things like chains and chocks also come under local variables.
I need to do a little more testing with other planes, but also observed that when both of us load in as the F14, my planes wheels are contacting the ground as they should, but the F14 next to me was hovering off the ground slightly. It is something i have noticed before with the F14 but does not seem to be an issue when we both load in as F18’s for example. Do you know what may be causing this?
Thank you again for your reply.
That goes in relation to the static parameters of the contact points of the flight model. These static data affect, for example, those points where physics are not being applied: for example, when the plane is in the hangar, or when you load the plane in cold and dark and see the panoramic view of the plane, there, physics like damping compression are not being applied. I understand that this applies to multiplayer as well. If MSFS, for example, takes frame 0 of an animation with 100 frames lenght as a reference, frame 0 corresponds to uncompressed damping while 100 is the more compressed one and that would explain why you see the plane next to you levitating with respect to yours (because in yours physics are being applied). We are aware of all this. and it is something that we must see how to correct
@DEAN01973 just want to give you all a big thank you for continuing to hear the community and have a realistic look at what is practical and what issues have come up with updates. Other than BR I haven’t seen this type of attention 
Thank you Jack. Very much appreciate the detailed response.
Jack got here first but, for the most part, it’s an Asobo problem that was the same in FSX and Prepar3D - the multiplayer has trouble reading the “states” of even basic animations such as gear and flaps of other airplanes. It seems to depend on when you join the server - the MP assigns a state to other players’ airplanes that may not reflect their actual positions.
When dealing with customers sometimes the pain exceeds the pleasure, and you have to say bye bye. Bye.
I am quite happy with what we have, but will never turn down the opportunity to take the Super Tomcat for a spin!
Thank you for the detailed responses. I really appreciate it. 
Hi Jack,
Thank you and Deano for all the answers and information you have provided on this forum! I have read through most of the thread and have a couple of questions relating to RNAV/VNAV and the autopilot.
First, let me say that I have most of the cockpit button toggles bound to my throttle controls. I do notice that sometimes, even though I select the appropriate toggle on my control, the graphics in the cockpit don’t change (the switch doesn’t move), but the tooltip over the switch changes to indicate a change in function.
With that said, I was arriving in KTEB today trying to capture the glidepath on an RNAV approach (RNAV GPS Y Rwy 6). The lateral guidance worked fine, but the glidepath was never captured. As I passed the IF (JUGGY) at the proscribed altitude and started dropping to the FAF (STICC) altitude, I saw the glidepath indicator on the vertical deviation scale, but never saw “G/P” show on the HUD. I continued along, enabling the Approach button, and this immediately took me out of GPS and into VOR mode. I put the plane back into GPS mode, but never caught the glidepath and never saw the GP HUD indicator.
I tried to follow all of the instructions you wrote in your post (#1047) above:
“APPROACH SWITCH (upper ACLS ILS switch): Enables Approach mode (with GlideSlope) During an ILS approach (also called precission approach) with a valid ILS frecuency tuned, the plane will try to head the localizer position and catching the Glideslope if succeed. During RNAV approach (also called non preccision approach), will follow a glidepath not displayed in the MFD provided by GPS (However in final approach a manual intervention will be probably required in RNAV, while on ILS the aircraft can land automatically with Autopilot and Autothrottle). For ILS landings, a valid tuned frequency and NAVGPS switch in VOR MODE and AP Master ON is required in order to work (to ensure success, try to enable Approach mode when you were more or less aligned vertically with the GS displayed on the HUD). For RNAV landings, GPS driven is required.”
Is selecting Approach supposed to be taking me out of GPS NAV mode? If so, is switching it back taking me out of Approach mode?
On a separate but related note, should I be able to enable VNAV on that approach, as long as the approach is in the flightplan?
Thank you.
Much appreciatted really!
I think it doesn’t, this is something that happens on all planes. You see, it seems that we are the only ones to implement a switch that disables the GPS, but this seems to have an effect only when there is no active flight plan. When there is an active flight plan it seems that the approach inverts the state that the GPS had at that moment. If it was disabled, it is enabled, and vice versa. We realized with the concorde and it is corrected in the F-15, but not in the f-14 apparently. It is clear that if you do not take a GS it is because the gps is active. You can do a switch reset to make sure the GS is intercepted. That is, if you have to take a detour, do it.
VNAV together with autothrottle what it does is fix the speeds during the different phases of flight. From take off to landing if you go with autothrottle and the F-PLAN is active. My idea is to change VNAV for ACLS, this is that you can make the landing with a speed whose calculation is based on an interpolated value, based on GW and real charts, this is already working in F-15 and it works really well. The problem with VNAV is basically that it must also calculate the vertical speed between the aircraft’s altitude and the next WP’s altitude. But there is a problem with MSFS and that is that sometimes the altitude of that WP is 0 if the flight plan has not been set correctly, which means that the plane will crash. That is why I think it is better to replace it with the real function of the plane which is the Auto Carrier landing System.
I will try the switch reset and see if my timing of setting the system back to GPS was faulty.
With respect to your logic, it’s an interesting feature/bug of the system to invert the state of the GPS when selecting Approach when there is a flight plan active. What does the aircraft consider a flight plan?
Let me explain: I use Aivlasoft’s EFBv2 to set up procedures, establish waypoints and Direct Tos and I really like the way they show the plane in real time on the glide slope as well on their charts. EFBv2 writes to the GPS system and updates it whenever a change is made in the routing/procedure, etc. - what they call the “Flight Plan.” However, because of limitations within MSFS, changes to the GPS system directly don’t reflect graphically as updated flight plans. The waypoint information is updated in the cockpit displays, but the path/track is not updated. So, is the system thinking it has an active flight plan or not?
Because of that, I also use the PMS50 GTN750 when I want the in-cockpit flight plan represented graphically when making changes. I just find it a lot less flexible and harder to use than the EFBv2. I will try the same approach both ways and report back when possible if there is a difference between a GPS-only flight plan and a GPS flight plan that is also represented graphically in the cockpit displays.
Yes, I have seen very strange VNAV behavior and it certainly looks like the system is assigning a 0 value to the altitude of many waypoints. The speed that the system selects seems to be too high for approaches also. It sounds like ACLS would be an ideal solution.
What is weird is that even assigning an altitude to a waypoint in the GTN750, and seeing the constraints on the GTN’s map, the plane’s VNAV system still ignores them. Maybe those constraints aren’t making it into the flight plan or into the tables the aircraft’s VNAV system is reading.
A flight plan is any scheduled flight either from the selection menu or from any available browser or any external program that correctly creates a *.pln and loads it. In this case the F-14 does not yet have a Physical FMC but uses one in the background for the logic to work (but we are in the process of including it in the RIO). What you use the GTN750 is at your own risk since it has happened to us lots of times that users have come to us to complain that certain autopilot functions of our planes stopped working or that the screens stopped working directly, that is because mod 750 alters certain base files that are shared by all screens, fmc or devices that have to read these files, and this developer, although he is aware of it, has not yet deigned to solve this problem. Therefore, as long as this developer stops hijacking the base files I will not recommend its use with our planes.
Our VNAV does not read the legs of an FMC, but the variable: A:GPS_WP_NEXT_ALT. Therefore, if the altitude of the next waypoint of the flight plan is correctly defined (either via FMC, menu or external software) and it updates this variable to the correct alt value, it shoudn’t be 0ft, but in reality it is not.
I am going to write this more for memorializing and confirming what you wrote just above, but you are 100% correct and I appreciate your taking the time to explain it.
I did four landings in KTEB (the original approach that I had asked about - RNAV GPS Y Rwy 6). The first was with a flight plan created from the world map selection menu. It worked as you said. The flight plan showed in the instruments and I selected approach mode before the FAF and the autopilot caught it (even though it changed from GPS LNAV ALT on the HUD to TRK FAC ALT G/P on the HUD and still followed the GPS course (and the NAV/GPS switch was still showing GPS was active). Of note, I selected 140 knots as the airspeed and the plane lands about 200 feet too short at that speed.
The second was one where I loaded a flight plan into the GPS system only (no *.pln file) through Aivlasoft EFBv2 and while the GPS flew it, once I selected Approach mode, I got kicked out of GPS mode into NAV and the Navigation mode selector by the “magic switch” also got turned off. Needless to say, nothing worked at that point with respect to the RNAV approach (HUD started showing LOC ALT G/S). I selected GPS and re-enabled the Navigation mode, so lateral guidance worked, but not the G/P.
On the third attempt, I loaded the GTN750 (understood about the pitfalls of using that mod, but it seems to be the only possible way of loading a flight plan that the aircraft will recognize while in the air or without going back to the world map) with the approach and it worked as well as with the original attempt. Again, landed short due to speed.
On the fourth attempt, used the GTN750 again to set the flight plan and everything worked well again, with the exception that I selected 150 knots as the speed. The plane approached almost perfectly (maybe a tad short), much better that at the slower speed.
In none of these attempts did the AP or Auto Throttle seem to disconnect 85 feet above the ground, something I think should have happened.
On the VNAV information, I will see if I can input a *.pln file with the necessary (correct) information.
Thank you so very much again, Jack!