Litjan

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

Hello Sabre, there could be many many reasons for this - did you select the scenario "ready to fly"? That should have your engines running (unless you run out of fuel). If you can not increase the thrust levers your joystick may not be set up correctly. Cheers, Jan

Hi Matt, yes, that is still very much on our roadmap...yet we want to complete the items that are still missing for "normal" enjoyment of this aircraft first. There are some failures already built in (go to the failures menu in the IXEG menu) and you can also do some native X-Plane failures. The details of our wear&tear + failure modeling have not been decided yet. Cheers, Jan

Ah, now I understand. We will likely add more commands for home-cockpit builders in the future, I collect all requests and we try to add them as we have time. I have to look into the issue with switching views to "no cockpit" (or HUD), I think there was a reason why this could not get enabled....maybe we can now. Good bye, Jan

3. There is a little "board" that you can click on (it will flip forward for a second) and it will turn all landing lights on at the same time

I just checked - and you are right! The right turnoff light switches are not correctly connected to the commands, same for the APU. Most users will operate these with the mouse or VR controllers, so it was never noticed. We have added these commands mostly for people building home-cockpits, so they can connect them to their physical switches. Recently a lot of manipulators in the cockpit were changed for 1.3 and I think these commands got broken. I will add an item to the bug list and we will fix these for a future update. The other switches you mentioned you have to operate with the mouse - we may add commands for them later (I will add your request for that as well). Thank you again for letting us know, Jan

We have not updated the paintkit yet - so if we leave the "very shiny" inlet in the download, everyone (all liveries) have to fly with the very shiny inlet. So we change it back to a moderately shiny one. Later every painter will be able to select the "shinyness" (if I understand that correctly). Cheers, Jan

Hello, all these switches are custom commands for the IXEG 737, you have to search for commands starting with ixeg when you set these to joystick buttons. The normal X-Plane commands for "lights" will not work. Cheers, Jan

Yes, Laminar Research is also investigating some reports of switches not working and it seems to be the combination with Vulkan that brings this about... Cheers, Jan

Hi Stephane, Here is your problem: Loaded: D:\X-Plane 11.50 BETA/Resources/plugins/UltraWeatherXP/64/win.xpl (uwxp251.xpmgraphics.xyz). It is known to cause this: https://forums.x-plane.org/index.php?/forums/topic/217345-ultra-weather-xp-v26-issues-situation/ Cheers, Jan

No, I don´t have any other ideas. You can ask X-Aviation support - but I doubt that there is anything that they can do, as thousands of other customers can download the patch just fine - so it is pretty much impossible to find out what is wrong on your end. Cheers, Jan

Well, you can see plenty of blinking lights and knobs in VR, too! You just can´t touch them...well, the VR controllers "buzz" a little bit when you do, so there is haptic feedback for "touch". I have seen some succesfull homebuilt cockpits, but I have also seen an unproportionally higer amount of woes and sorrow related to that. People asking (crying) for help on various forums (including this one), asking for datarefs, commands, "detachable displays", endless expermentation with Arduino, XPUIPC, fly-with-lua and so on. Eventually most give up, because it is very complex and our aircraft (like most 3rd party) is not designed with the idea of being "home cockpit compatible". Compare this to VR where all you need to do is put on the headset and immediately you sit right in that cockpit - and the feeling of realism is incredible. Yes, there are some things to get used to and technology has some improvements to make as well (mostly resolution, but also cockpit interaction) - but if you want to fly in a "real" cockpit more than you want to work on a "real" cockpit, I would go VR. Jan