Litjan

Thanks for letting us know, teelo! I will try if I also get this with my Rift - and maybe it is also possible with the mouse? Normally the guard being closed will also close (connect) the battery, but maybe it is not checking the "state" of that guard but rather the "movement"... Cheers, Jan

Thanks for letting us know! Happy landings!

hi grizzly air, I have a hard time seeing it on your screenshot, but the mode annunciations on the EADI look correct. There are three reasons why the LNAV would not follow the magenta. First maybe you had a gizmo crash before and closed the window to keep on flying (this may mess up all calculations of the aircraft´s code) or second the waypoint did not sequence properly (i.e. you bypassed a waypoint too far abeam, so the FMS doesn´t consider it as "passed over"). The second problem can usually be fixed by going "direct" to the next desired waypoint again, so in your case click on the top (highlighted) waypoint - this will put it in the scratchpad - then enter it again on top of itself into the first line. This should give you a "dashed white" line emanating from the nose of the triangle-aircraft-position symbol to the desired waypoint. Hit the lit EXECute button and the plane should turn towards the waypoint. The first problem can only be solved by clicking the "reboot" option - but that will reset your aircraft to the startup situation, so make sure you pick "ready to fly" first and then "save" the flight like I show in my last video... The third possibility is that you have discoverd a bug...so if you can reproduce this situation somehow please let us know so we can track down why it happened? Cheers, Jan

Hi Torbinator, Tom has changed (fixed) the way that altitude and speed restrictions are read into the LEGS page, now you often see things like /5000A9000B which previously didn´t happen. He also enabled the user to input all sorts of combinations of speed and altitude restrictions, you can now enter 260B/5000A9000B which previously wasn´t possible. As far as the FMS actually considering these restrictions it is entirely possible that this got worse, as possibly the new format isn´t read properly by the FMS. So this will be fixed with the VNAV rewrite, but we will take no effort to band-aid fix this any earlier. I would say that if previously this worked somewhat for you, you got lucky! In general I would state that arrival scenarios with altitude restrictions simply do not work. Cheers, Jan

Hi, you can use the map view (key M) to set up for approach: 1. Extend flaps to 30 2. Set Vref for flaps 30 3. Pause simulator 4. hit key M 5. click on airplane 6. increase altitude and then speed, then drag airplane to position you like 7. click M, then P to unpause after landing, repeat

Hello! 1.) You should enter V1/VR/V2 for takeoff. Then fly to destination. Then before landing enter Vref. Do not set Vref before getting ready to land! 2.) PROG page is still not working well - we are working on making it calculate fuel and times better! All the best, Jan

It is normal if you use both autopilots - this is a feature called "mistrim" which the dual-channel approach does on purpose to make the nose pitch up (for safety!) if the autopilots disconnect on an autoland approach. If you intend to do a manual landing, only use one autopilot. Cheers, Jan

Too bad, I was hoping that was it... no, I am afraid there really isn´t a way to clinically compare the files. Another thought - do you have any type of live virus checking running? It could be that the attempt to read data from the NavData folder is not fulfilled in time because a live virus check is stalling that data stream. We have a similiar problem with the live checking of Windows Defender, and users have to exempt the X-Plane folder from checking or it will slow the data exchange down too much. Cheers, Jan

I may say that - I also fly the A320

Maybe a lua script writing to a dataref or something?

Oh, thanks! I will check that out! Cheers, Jan

Hi Ian, I recently tested a lot and always had the GW displayed on the APPROACH page as I need to be at a certain weight for my tests - and it has been updating just fine. I wonder if there is something unique to your setup that may influence this, as you also reported the problem with the grossweight being wrong after the turnaround? To my knowledge we never had any waypoint data on the ND, neither the times nor the restrictions (same for the RTE DATA on the LEGS page). This is planned, but not yet implemented. Cheers, Jan

Ok - I was hoping that would help Now I have to ask you to move all of your plugins (except DataRefeditor, the PluginAdmin and the two .framework and Gizmo) into a different folder to test if they affect your installation. Let me know if that helped? Cheers, Jan

Hmm, I can´t really tell anything wrong from the log files. Here is what I would suggest: 1.) Make sure you are updated to the IXEG version 1.32 (currently latest). 2.) Try to run the latest Gizmo beta (you should have gotten an email with a download for an "updater" which will keep your Gizmo version current). 3.) Remove (physically move to another folder) all other plugins and see if that somehow helps? If those steps don´t help, we need to wait for Tom to come home (Monday) or maybe @Ben Russellcan help with what that error message may mean? Cheers, Jan

I really can´t - I don´t even know what a paintkit is, to tell you the truth! Sad but true... Tom will be able to answer this, but he is out of town on family business and won´t be back until Monday. In all likeliness that is still the official paintkit, to my knowledge there was not a new one done. Cheers, Jan

After reading up on the forums - I decided to skip beta 15 and wait for 16, so I can´t verify your problem here. However I am convinced that it is isolated to your setup, as we would otherwise had more reports already. So please try and post a screenshot of when it is happening to you with the "brakes" value displayed on screen (little green numbers), also post a log.txt file and tell me which airport you are trying to taxi at. Thanks, Jan

Hello Hawk, we would need to see a full log.txt file attached (find it in your X-Plane directory) to start diagnosing this. I will also draw your attention to this post: this may help in singleing out the problem. Cheers, Jan

Ok, let me get home and I will try the latest beta - I am on XP11.50b14 still... Cheers, Jan

Hi shabani, yes, i would like to know the same thing - is anyone else seeing this? If not - maybe you can check if any third-party code is affecting this? Lets see what we can find out! Cheers, Jan

Hi, the only thing I can see here is the brake still being set, or some hardware axis being assigned to braking inadvertantly - you can check the status of brakes by displaying the corresponding value in the Data out tab in the X-Plane gui. We also had one or two reports of unusual rolling friction when people used some custom third party airports (I think there was one Bergen, Norway that was causing trouble)... Let us know if you find out what happened? Cheers, Jan

I agree! There were some really easy "low hanging fruit" gains and its always very rewarding to just kick the tree and see them all fall down .

That is very encouraging to hear! I see the same thing, sometimes the results on the LEGs page are a bit different than what one would expect, but I can always clean them up without problems. This is mostly due to us having to make some fairly dogmatic coding decisions ("when changing the STAR, ALWAYS....") which may lead to an odd situation where that dogma just doesn´t fit quite right. But trying to code for every possible permutation will lead to overflowing complexity and errror levels rise. When changing routings while flying in LNAV it always pays to review the modified route and prune/close up everything before clicking that EXECute button...just like in the real aircraft . Cheers, Jan

Oh, I have seen the VNAV calculation do the craziest things... even telling me I was 10.000 feet too high when I was only flying at 5000 feet . It may have gained self awareness and wants to get rid of all human pilots. For now I would take all of its calculations with a grain of salt, especially if the route was changed after liftoff an/or contains restrictions on the descent path. Cheers, Jan

Hi Daniel, yes, these are the sort of problems we will solve when the VNAV code gets rewritten... Good job on doing the calculations in your head - its good practice but of course we want to have the FMS be able to do the job as well! Cheers, Jan

I have this, too. As Ben said - it is not imparing the desired result, because if you have the menu open and try to "click" the options (or slide the sliders) you are not going to use the mouse-wheel. The only ill effect could be if you try to zoom in while over the gui window and inadvertently change a value of a manipulator behind the window... Thanks for pointing this out, Tim, Cheers, Jan