Litjan

Another successful testflight this morning - Flagstaff, Az to Tucson, Az. We are still ironing out some issues, but here are two screenshots (one showing the current look of the new GUI).

We are making good progress!

I would like to chime in here - I have worked with Tom on this over the last week intensively - previously I had test flown the 737 in XP12 (after we fixed the major roadblocks of even getting if flyable, like making the flaps work, etc.) and I had tuned the flight model. Tom worked hard on 3D modeling over the last months with little for me to do (I am too stupid for blender and those things) and now with him approaching the end of that work, I dove back into flight and system testing. The more I test, the more stuff shows up that does not work anymore, because Laminar changed things - and these changes are all improvements in modeling systems, yet they still leave our "old" way of doing/overriding them unusable. So in a very real way we have to redo a lot of the things we already did for XP11, it is not a quick conversion at all - and this is something we definitely underestimated when we initially said to "upgrade to XP12 for free". The move from XP11 to XP12 is not an upgrade, it is in many areas a repeat of the dev work work we already did for XP11. And I am thankful for most of our customers to be very understanding of the fact that we charge a small price to compensate us for this! I think the old 737-300 still has a lot of life in her, I thoroughly enjoy my "test flights" and find myself again and again to "just finish this approach" even though I was just testing some autopilot PID constant ... simply because it is fun to fly and looks great in XP12 . Cheers, Jan

Maybe work on your eyesight before taking up flying

The answer (as good as you are going to get one ) is in the first post.

Gizmo is under constant development...there have been reports of incompatibility with other plugins before, but to my knowledge those were resolved many years ago.

I am fairly hopeful that the flightmodel bugs will be very few, this is something that we can test in-house fairly well. As for user bugs, yes - there is inevitably a large array of different systems and even more so different ways that users operate the airplane that reveal things not working as intended...so every major new release will be followed by collecting user feedback and rolling the resultant fixes into a short-term update.

There is also a potential - and much more likely - failure mode on your proposal. Most of the time, people will NOT have their hardware throttle at the "approximately correct" position when they disconnect their autothrottle, they will simply forget to align it before disconnecting. Then they will disconnect, and it will cause their engines to either spool up to maximum power or loose thrust to idle...which will mess up their manual flight and especially on short final is hard to recover. My advice to avoid YOUR potential failure mode is: Do not get into a situation where only adding full (overboosted) thrust will save the aircraft . In "most" situations of "being a bad pilot" and being too slow, the reversion modes of the autopilot or autothrottle (if in arm) will kick in to save the aircraft. In other situations you can click the TO/GA buttons to advance power automatically to maximum GA thrust. IF you ever get into a situation where you need to apply maximum thrust you need to remember to cycle the thrust levers from idle to full power once (which will take 0.5 seconds), but yes, you need to remember and this is different in the real aircraft. It is the compromise we have to make for not having motorized hardware throttles.

Normally it is not necessary to "see" the ghost throttles to regain control of the thrust levers. You just need to have your hardware throttle be at the "same" position as the virtual throttle AND the throttle must not be under control of the autothrottle. This is what confuses most users, they try to regain control but have not disengaged the autothrottle. Once the autothrottle is disengaged, just move the hardware throttle over the full range of movement (from full forward to idle power) and you should "capture" the virtual throttle along the way somewhere. A little more refined is the method as above, but move the hardware throttle slowly while watching your virtual throttles - as soon as they start to move, you know that you have regained control. This is independent of using VR.

@AngelOfAttack That is certainly viable - and I know some airlines also use the DH to provide some sort of terrain awareness. However, you still get the automatic radio altimeter callouts, so if your minimum is 200 feet above the threshold, the automatic "200" callout will double as a (close) reminder. When approaching in considerably better than minimum weather conditions we used to be just brief "minimum is visual" but that was later reversed as sometimes weather was surprisingly worse than expected and no minimum was set that the crew could refer to as the plane got closer to the runway but could not pick it up visually.

It is not recommended (and even against regulations) because the radio altimeter will say "minimums" when it measures 200 feet radio altitude. But since the terrain in front of the runway may be a hill or a valley, this may not really be "200" feet above the threshold - as it is required for a CAT I minimum. If the terrain in front of the runway is very flat, this will work. But legally it is required to reference a DA (decision altitude) with regard to MSL - not a decision height with regard to radar altitude, like you would on a CAT II or CAT III approach. Even on a CAT II approach you will often not set your DH to 100 feet - but to 98 feet or to 102 feet or so - to allow for undulating terrain in front of the runway threshold.

Great video, you have a good eye for nice shots!

You are close to an "inner marker" - it is a radio transmitter near the end of some runways that will alert aircraft on approach that they are about to see the runway (if they fly in clouds). You can move forward until you dont hear that sound anymore, fly from another runway or disable the sound by deselecting the "marker" audio channel on the audio selector panel.

Today some high altitude flightmodel testing for the conversion. The picture shows steady state at FL350 and M.74 with 46.000kgs. Book values (official POH) are: 82.8%N1 and 1009kg/h FF.

The first thing I would do in your case was posting in the correct forum, corresponding to the aircraft you are trying to fly. Good luck!

The engines start fine :-)

And initial testing is promising... IXEG XP12 initial testing.mp4

Thanks for the nice feedback and the solution to your problem! The 737 classic is the plane I enjoyed flying the most, and I hope it shows in our simulation...although all the credit of bringing it to life in the virtual world goes to Nils and Tom - they are the true artists behind this project. I use the speedbrake in our simulation exclusively with the X-Plane commands for "Speedbrake - extract one and Speedbrake extend one". This gives you perfect control over all the necessary steps of movement (down, armed, flight extent, full extent). Cheers, Jan

Hi and thanks for the kind words! I suspect - and this is just a hunch - that the speedbrake does not registers as "completely down", or the flaps are not "exactly" in 1 or 5 - this sometimes happens with hardware "axis" assigned to those functions, instead of buttons or keyboard presses. To "test" this you could a.) display the values for flaps and spoilers using the "data out" function - it will show you the exact values for those flight controls in green numbers on screeen and/or b.) unassign thoses axis (temporarily) in the setup of your Honeycomb hardware and operate those controls with buttons or key presses (or the mouse in the virtual cockpit) and see if that makes a difference? Another thing to test is pushing the thrust levers forward really quick during taxi-out before your second take-off - just to test for the takeoff warning - it beats finding out about the problem earlier than in the middle of your take-off run ;-) Let me know how that works? Cheers, Jan

There is nothing special about the way we model the nosegear steering on our 737, it is just default X-Plane logic. So if you can do it on the default 737, for example, it should work on our aircraft, too. Cheers, Jan

Hi Daniel. there is some variation between airlines, but most common use for takeoff would be: 1st bug to 80kts, second bug to V1, third bug Vr, set speed cursor to V2, fourth bug to V2+15 (this is the speed that is minimum for going over 15 deg bank), fifth bug to 170 (for flaps 5 and 15 takeoffs), this is the speed to retract 5 to 1. For landing we set 1st bug to Vref, speed cursor to target speed, second bug to Vref + 15 (min speed for going over 15 deg bank) and i often set another bug right next to the second one if planning a flaps40 approach (as a reminder). Cheers, Jan

Did you see the "descent helper" sheet that is available for the avitab?

Hi Daniel, I did not check your calculation step by step, but it sounds about right. Naturally if you change your remaining distance to the airport you also need to change your angle of descent - the best way to do that is using FL CHG mode. VNAV will have a hard time regaining the path - as it descend steep to get back onto the path, it will overspeed and then pitch up - that is the "wavy" descent that you observe. VNAV descent will ONLY work well if you fly exactly on the planned path and never get too high - otherwise you need to revert to a more basic mode and do the math in your head (remaining distance x 3.3 is a good approximation). Viele Grüße in den Hunsrück, Jan

Interesting! And you are correct, there should not be a CWS indication with FD as the commanded mode - just a blank channel. I will try to recreate and fix this for the next update, thanks!

No, the reason for this happening were never discovered or reproduced.