Litjan

Good to hear you got it solved! Jan

I looked at your log.txt and you are running more (possibly conflicting) plugins than I could count in an afternoon . I would ask you to remove them (temporarily) to find out which one is the culprit. My money would be on flywithlua or FSUIPC, possibly also the python interface. There is a boatload of warnings about "unassigend joystick axis" in your log as well, so I am not surprised that something isn´t working right... Cheers, Jan

Its not modeled in the IXEG 737, but certainly works in the real aircraft. We are planning to add it later - a (poor) workaround is making the point visible with the FIX page (enter a bearing and a radius, use HDG SEL to fly to the intersection of those). Cheers, Jan

Hi Ian, this sounds exactly like the problem Stephan describes. I have filed a report with Laminar - I can not figure out what our plane is doing differently from the default 737 (where just one axis for yaw works fine...) Cheers, Jan

Ok, I have just tested myself: The same thing happens to me, if I only assign one axis to "yaw", but no other axis to "left brake" and "right brake". Iirc Austin talked about this - as a mean to "help" people turn the aircraft if they can´t use brake pedals. Some smaller aircraft need to use the wheelbrakes to help turn the aircraft... I am not sure when they implemented this, but I will file an (angry) bug report right now. For you the only option right now is to live with it, or assign some other axis to "wheel brake left" and "wheel brake right". Ideally get some rudder pedals with brakes, they are pretty much essential for realistic flying, anyway. I will let you know what they say, Jan

Hi Stephan, put out the values for gear steering and brakes to screen (using the Data Out tab). That way you can see what is going on. I don´t know how you control the wheel (rudder pedals, twist stick, mouse?), so I can´t say anything but that this is not what I see on my end Cheers, Jan

Thanks for the feedback! No idea why your autobrake disarms . All other points are known, noted and agreed upon, we hope that we can remedy those in the near future! Cheers, Jan

If you check out the airport in the map view (M) you can see that the opposite ILS (runway 10L) also has the frequency 111.10. I think it may be possible that you are catching a signal for that ILS inititally. To check that theory, click the checkbox on the general setting page in X-Plane 11 that says "Disable downwind ILSes". Let me know how that goes! Jan

The answer to your question is in the text you quoted. Please post again if you are having trouble finding it! Cheers, Jan

Hi, you will need to file a ticket with X-Aviation if you are having a problem with the license. The normal download contains the latest gizmo version, so there is no need to download that extra. If you are having problems with your license, only the support at X-Aviation can help you. Cheers, Jan

Ok everyone, I have worked a bit more with N55E008 and he has been very helpful in identifying and isolation the problem in XP10. Indeed it turns out that in our move to support XP11 I have made a mistake in changing the script for the fuselage drag. This will indeed result in a drag in XP10 that is too high. This error is most prevalent at higher speeds (of course), so you will notice mostly during speeds in excess of 250 kts (climb and descent). Cruise and lower altitude operations should still be ok, although technically the drag is a bit too high as well, naturally. I have fixed the script, we will run it through some internal testing (I would like to avoid another embarrassment!) and then we will distribute it to those interested (= still on XP10). I expect this to happen very short-term. Thanks for everyone´s patience and especially N55E008´s help! Cheers, Jan

Hi Base, if the wind is coming from the side, an airplane must point the nose towards that wind to keep going in a straight line over the ground. Imagine yourself in a boat, rowing across a fast river. If you want to keep going straight towards the dock on the other side of the river, you need to point the bow of the boat upstream, right? Otherwise the river will flow your boat "off course". Same with an airplane in a moving airmass. Cheers, Jan

Steering with the rudder pedals should not disarm the autobrake - I will try on my end to verify that it doesn´t. I find it extremely difficult (on my CH Pedals Pro) to steer a lot without accidentially triggering the brake pedals, though. And there is not "null zone" that you could set for those. We are using the default autobrake logic for X-Plane for now. The real plane requires a certain amount of brake deflection over a certain time to disarm the autobrake, I think in X-Plane ANY short tapping of the brakes will disarm them. Custom joystick axis polling is a can of worms and VERY difficult to achieve (due to the need to detect the correct axis on a multitude of devices and setups) and therefore we try to stay away from it as much as possible... That being said, you also need to watch carefully in the real plane for accidental disarming of the brake, it happens easier than you think and the pilot monitoring must carefully watch the light and call it out "Autobrake Disarm!" when it illuminates. Cheers, Jan Edit: I just tried in 1.21 and XP11.20b5 and in both RTO mode and regular autobrake mode (tried setting 3) I can fully deflect the rudder/nosewheel without disarming the autobrake.

The estimated time over the next waypoint is calculated with the ground speed calculated by the FMS dependent on speed planned - just like in the real aircraft. So it is more or less independent of the ground speed indicated. The real plane will calculate the waypoints downstream with the FMS speed (converted to ground speed by applying wind entered either in the LEGS page per leg, or by the cruise wind or the wind component) - wind is not calculated by the IXEG yet. The real plane will also consider actual wind for a small portion of the current leg. The estimates calculated in our IXEG simulation are very rough for now - we hope to improve them along with further refinement to our FMS calculations. Jan

Hi, I have run this performance test on X-Plane 11 (I don´t even have XP10 installed anymore), but I don´t think anything should have changed with regard to the performance. I have used my official flight planning data for the 737-300 I used to fly. These are the test parameters: Airport at sea level Temperature ISA +10 (25C). Brake release weight 58.000kgs. No wind. Climb schedule: V2+15 to 1500 feet. Then 250kts to 10.000 feet. Then 290kts until Mach is 0.74. Then 0.74. Full climb power. Watch for the IAS/MACH changeover, if you are on FL CHG it will automatically change from 290 to 0.71 at ca. 26.000 feet. That is too early, you need to revert manually to IAS and switch over when the speed reaches M.74 (c/o button). Here are the values I get (first the flight test values with IXEG 1.21, then the values from the book): Altitude Distance(IXEG) Distance (Real aircraft) Time (IXEG) Time (Real aircraft) 6.000 11.2 10 3:25 3 10.000 18.2 17 4:54 5 14.000 29.8 29 6:59 7 20.000 48.3 47 9:59 10 24.000 64.9 65 12:29 12 28.000 86.4 89 15:33 16 31.000 102.3 104 17:46 18 33.000 117.0 125 19:50 20 Climb rate just before reaching 33.000 feet was 800 feet per minute. Cheers, Jan

Tons is 1000kg - so its the same unit, basically. Its like km and m. Jan

Regarding the autobrake: Try to fly without X-Enviro to test this - there have been occasional reports about the ground friction getting affected in some weird way - just to test, disable it in the plugin menu. Also, un-assign your hardware thrust lever and use the default keys (F1/F2) instead for this test - sometimes thrust axises aren´t calibrated properly and "0" throttle angle is not achieved, even with hardware at stop. You can also output the relevant data to screen to test this (go to the DATA OUT tab). There will be no "disarm" light if the autobrake fails to work because thrust is not at idle - since it is not "disarmed". There will be a "disarm" light if you disarm the autobrake with manual brake input, though. Also note that there is an X-Plane bug that will prevent the autobrake from working again if you reject a takeoff and then do a second one and try to reject that as well (iirc). Cheers, Jan

No, it doesn´t help. The startup sequence was modeled according to videos I made of the real 737 starting up and things like starter cutout are modeled according to the real manuals (it does not depend on N1, but on N2). Also note that the exact start sequence depends on many factors like when you move the engine start levers to run, ambient pressure, and temperature, APU start pressure, engine age, etc. No two engine starts really are the same, so even posting a video would not prove anything. I am pretty happy with the way we portray it and I don´t see us changing anything about it. Cheers, Jan

Hi NZWW, thanks for the kind words. Most of the things you mention we are well aware off and agree - they are on our list of improvements to do! Some things are harder to whack - i.e. the GLIDESLOPE warning is realistic - its just that in real life there is no reception of the glideslope as you use the opposite runway to depart on, hence no warning. I do get that nuisance warning in XP as well. That being said, I am not sure which SOP´s require setting navaids for immediate return - all the SOPs I am aware of require to set navaids for the SID, instead. The autobrake works fine for me (and most people) - make sure that your thrust is really idle upon touchdown. The deceleration rate is default X-Plane, but I did some measurements and found the values to be pretty much in the ballpark for the real 737´s autobrake. The "cockpit lit with seatbelts off" is a X-Plane limitation - it is actually the cabin light "bleeding" through the rear cockpit wall. To avoid that, just keep the belts ON. You can see the dome or emergency exit lights in the cockpit illuminate (fixture is bright) when they are lit, so you can confirm it is neither of them. I have to check the climb N1 again, but I was pretty sure it gradually washes out to full N1 during the climb... Cheers, Jan

I go from about 3 degrees pitch to 6 degrees pitch. This is a change of 3 degrees. If you are coming down on a -3 degree glideslope and want to go to a 0 degree flightpath, this is the minimum amount of degrees that you need to change your pitch to enter level flight. Plus you need to another degree or two for a short time to "decelerate" your sinkrate. This is called the "break". It is not a "significant" rotation, it is the minimum needed on any aircraft to change the flightpath by the corresponding number of degrees. Just like Morten said above: It could be that the Zibo is an .acf file that was never saved on the newer XP-version, so the new pitch-down does not take effect (Laminar has implemented an opt-in model, you need to resave your aircraft for the new aerodynamics to take effect). Otherwise I do not see how the zibo mod would not be affected. Last but not least - if we had a chance to "deselect" this nose-down effect, we still could not do it - without it the plane would lift off by itself during the takeoff run. In fact we had an artificial "nose down" effect before XP11.10 to avoid the plane rotating early - its effect was limited to "on ground", only, though. If you want to go and harass Austin to "soften" the effect, please be my guest - I would not mind a small reduction, but overall the effect is realistic and needed for the airplane to perform correctly during takeoff. Jan

Happy you got it sorted out! Jan

I am really not sure what the problem is for you folks experiencing lack of elevator control or "sucking down" effects - make sure that you have upgraded to the latest version of the IXEG 737 (1.21) and the latest version of XP11. I have made a little video to show that things work perfectly fine on my end - with plenty of elevator authority remaining during landing. Cheers, Jan

Hi Sylvain, you would turn ON the autothrottle ARM when entering the runway for takeoff. Not earlier, so if you accidentially touch the TOGA buttons while taxiing around the airport you don´t want the engines to go to takeoff thrust. The autothrottle should ALWAYS stay in ARM (never turn if OFF) during the whole flight. This guarantees that it is ready to jump into action when needed (pressing TOGA, getting too slow, going to MCP SPD when changing the pitch mode, during ALT AQC, for example). The autothrottle will automatically revert to OFF 2 seconds after touchdown, not pilot action needed. Recently this was changed: Boeing now allows to turn the autothrottle to OFF if the pilot does not want the "combined modes" - for example when capturing the GS or when going to ALT AQC, the autothrottle will automatically engage in MCP SPD. This requires the pilot flying to command "disengage SPD mode!" to the pilot monitoring repeatedly, so Boeing allows to turn the autothrottle to OFF when flying manually. It is undesired system behaviour, so to say. Cheers, Jan

Hi Sylvain, the autothrottle system is very complex and can´t be explained in a few words. Google for a real 737 FCOM (there are plenty out there) and read up if you want to know the whole story. If you just want to know how to use it "normally" I would suggest watching and re-flying the tutorial videos I made for the 737. Cheers, Jan

I think mfor is right - when the right IRS is being fed by DC only (you should see the corresponding amber warning light), you will get a horn sounding - it is the same horn that sounds for the low-airflow warning if the equipment fans aren´t running. To avoid this, always enable AC power supply before aligning the IRS units. If you operate the plane according to the book, you will never hear that horn. Cheers, Jan