Leaderboard

When using the nosewheel there is an effect that is similar to a "stall" of a wing. The wheel will put out force corresponding to it´s "slippage" - until you pass the critical angle and it starts "gliding". This effect is real - try driving a car on ice or snow and see how gentle movements of the wheel help in keeping in control - once the car starts sliding, it is very hard to get it back under control. The problem in X-Plane is that the force put out by the wheel under a certain "slippage angle" is way too low. So people tend to naturally increase the steering angle to compensate, entering the range of free gliding (stall) where the actual angle becomes irrevalent. Try to use small movements, like jaguado points out. Try to steer smoothly and deliberately and control your speed to be less than 10kts in turns. I will keep pushing Laminar to make this more realistic. Cheers, Jan

This is a lengthy post, explaining our VNAV situation, or at the least, how we arrived where we are today, and where we're going from here. This is a tale of how being too ambitious and trying to be all things to all people bit us and our customers. In the beginning was nav data in XML format....whether other formats were avail in the beginning, I don't know, I only know this was my beginning because I inherited the FMS work and this was the dataset that landed on my plate. It was from Navigraph. The first thing I did when I started was to open up a few XML files to get the lay of the land. I noted several differing "types" of data like so: and decided I needed to know every single type in the dataset so I could design algorithms around it. So I wrote a program to go through all the files and log each unique occurence of a data type, i.e. "Star" "Sid". "Sid_Transition", "Approach", etc. After I had that list (because I couldn't find any spec), I set about programming the FMS....for a few years. All was pretty well. THEN....somewhere towards the end, we loaded up the same XML format dataset...but this time by Aerosoft, thinking "hey, lets support both providers, since there are plenty users of each". ...and for a while things were good; however, we started seeing some issues related to the fact that Aerosoft had additional XML types that Navigraph didn't have...and for which I didn't have code to handle. So I started throwing up 'band-aids' to get the Aerosoft dataset integrated....which would lead to some anomalies for Navigraph users...OK...a few more band-aids ought to do it. And this went back and forth until I had all 10 fingers plugging up holes in the dike. But turns out I needed a few more fingers....OR a more robust dike (hint...that's where this is going). Over time, we'd see bug reports for navigraph users that aerosoft users weren't seeing and vice-versa. Without exception though, the most obvious problem spot was in "decent FMS entries", i.e. STARS, Star transitions, etc. Entering these procedures were frought with all sorts of bugs and gizmo crashes. For online users who frequently enter these procedures in the air, as they approach their destinations, this simply was a deal killer. So...fast forward to today when I'm revisiting the FMS code from a much higher level and seeing that these band-aids just didn't cover the wounds well enough. So..case in point. Here is how Aerosoft and Navigraph each represent STARs with runway transitions, specifically KBOS. Aerosoft uses a data type "RwyTransition" to denote a runway transition waypoint, whereas Navigraph does not. This is where things went south originally when we tried to support Aerosoft users late in our development process. Now when a user enteres a STAR, and no arrival runway has been selected, then you'd expect to load those waypoints in the STAR that are not unique to runways, i.e. "common points". If you're using NAVIGRAPH, you will note that each XML "block" is associated with a runway. So if no runway is selected, we have no way of knowing which block of code to load for navigraph users. If you're using Aerosoft, then I can load the STAR waypoints only (and not the transition waypoints)....except all my code was written for the navigraph formats....and trying to make this work "last second" ended up causing more code confusion and debugging difficult. If I had a bigger picture of all these types from day 1, I would have written better structured algorithms. The good news, is I can see it better now and CAN write better structures; however, better than both these XML formats is the XP1100 dataset that we plan to migrate to in the future. But there is still more good news. Looking at the code with clearer eyes and hindsight, I can see a few trouble spots that I can fix that should make this whole VNAV decent business improve significantly. Indeed one or two poor lines of code can bring down the house and does for a few instantces of entering STARS / Transitions. We are going to add a new message to the CDU, which is NOT realistic, but required in our opinion to avoid confusion. If you select a STAR that is associated with a runway, or has runway transitions, we will display a message "RWY SELECTION REQD". While Aerosoft has the necessary common points separated so as to load those without a runway selection, recall my code was not orginally written for it, and so for the moment, I am not going to create a fork to handle it just yet. Knowing we are switching to XP1100 navdata format, I'll have to gauge the effort of accomodating Aerosoft's transition points differently than the Navigraph data vs the effort of just focusing on the XP1100 integration. It could be, that accomodating Aerosoft's transition points is not so difficult...and in this case, a user could select a STAR and STAR transition without having an approach selected; however, Navigraph folks, we simply need to know the arrival runway before we can load up these "runway transition" STAR types. For STARS that are NOT associated with a specific runway, but serve all runways, this arrival runway selection is NOT required before STAR selection. Many times users don't notice that the STAR they are selecting are unique to a runway (and subject to the case described here) and so in the course of their simming would see inconsistent behavior with STAR selection as they flew differing flights around the globe. This "RWY SELECTION REQD" message will let them know. And finally....my code handling STAR transitions for these "runway transition" STARS was completely borked (by a poor band-aid), messing up the waypoint table and rendering any VNAV calcualtions / representation completely useless. This is why some folks see good VNAV behavior and others do not. It is dependent on which route your are flying, which STAR type you select and whether or not you selected a transition. I believe this CDU message will fix a lot in the interim, but ultimately the swap to XP1100 nav data format, with its consistency and basis in ARINC 429, will be our final and most durable solution. Aside from the issue described here, the other glaring issue is the waypoint altitude restrictions. We will be attacking those soon enough and with clearer eyes, I expect to get this cleaned up also. -TomK

thanks for your quick reply - as i am writing this i am testing xpuipc 2.0.4.8 with several acars systems and the ixeg - that version might solve the problem , seems stable now. seems like the ixeg throttle and virtual airline acars systems will work with 2.0.4.8 but might habe problems with versions below and above....will keep testing. very strange indeed. appreciate your support

Very happy so far with VR

How to Land Pocket Rocket Taildragger using Propeller BETA - Assign Propeller BETA Button to your Joystick - IMPORTANT: Use Propeller BETA to Stop and Taxi - IMPORTANT: Use Plane Maker to increase Landing Gear Rolling Friction Coefficient to 0.025 - X-Plane Experimental Flight Model ON - IMPORTANT: to Land use Flaps 30 - Trim Airplane Properly On Approach. I recommend to Keep Rudder Trim at the Far RIGHT Mark like for Take Off - IMPORTANT: At Touchdown Keep Speed around 60 Knot (KT) - After Main Wheels Touchdown, Lower Tailwheel and Keep it on the ground (Keep Stick Full Back) - IMPORTANT: Now move Throttle Full Back and apply BETA Mode to Stop Airplane. Use Wheel Brakes if Required - Use Reverse if Required but Remember - Reverse very Powerful and could easily turn over such light airplane!!!

It is 'healthy' to bring the plane to a stable position, then you can activate the AP, YD it activates with the AP. You can activate only the YD, if you want It is great that the 1.12 is addressing some of your issues I hope that Saso @skiselkovwill help us getting back the plane in pristine condition

Any status updates on v1.1? Haha...some of us have been holding our breath all week. Thanks in advance! Robert

Hi Torbinator, I have seen the same (and stranger!) things with VNAV in descent. But I am pleased to report that Tom has implemented some coding changes related to STARs and it´s transitions (as posted above) that also seem to have a very positive effect on VNAV. I have done a few flights with VNAV descents, and I still see some quirky behaviour (mostly not adhering to the first of multiple AT restrictions), but overall the VNAV has become more predictable and more reliable and I am sure we can build on that and improve it further. I am curious what you guys will report when flying the next (1.32) patch. Cheers, Jan

Try out different liveries. There are multiple interior and panel colors. Find the one that suits you best and replace the files in each livery to match your preference. The grey, red and white panel are a bit brighter. Hope that helps.