Litjan

Ok - Try to output field 8 (joystick deflections) and field 11 (flightcontrol deflections) in the DATA OUTPUT tab. I just did a test-takeoff with those fields activated and there is almost no roll after takeoff. Here is a screenshot: I am at the end of my wits as to what is going on on your end Cheers, Jan

Hi Jean, I can see the usefulness of this - I will file a feature request and see if Tom can add this in a future update! Cheers, Jan

Yes, those videos should show that critical sequence. Basically you need to disengage the MCP SPD mode (you can also do this by clicking on the SPEED button on the MCP or bind a custom command to it). Then you will see the green FMA in the EADI go from MCP SPD to ARM. Now you move your hardware throttle and should see the "ghost throttles" appear - when they match up, you can see the thrust levers in the virtual cockpit become "in sync" with your hardware throttle again and you have manual control. It is puzzling that your X52 does not trigger those commands reliably. Yes, I have added many more commands in one of the recent updates, but those ones have not changed, I think. Here is what the EADI should look like after moving the AT switch up to ARM: Here is what the MCP looks like after engaging the MCP SPEED mode: Here is what the EADI looks like after engaging the MCP SPEED mode: Here is the command you must set up to disengage the MCP SPEED mode prior to manual landing: And here is the cockpit after you disengaged the MCP SPD mode and are trying to syncronize the thrust levers of your joystick with the "ghost throttle": Notice how the MCP SPD in the EADI changed to ARM again and the two white "throttle knob" frames on the right appear? You need to move your hardware throttle up until those two white frames match the two A/T grey throttle knobs above them. Cheers, Jan

Hmm, I think there is a fundamental lack of understanding how the autothrust modes work in the 737 at play, here - combined with confusion of how to regain control of the thrust levers once the autothrottle does not control them anymore. I would suggest watching some of the tutorial videos I made (you can fast-forward to the relevant sections of approach, for example) to see how it is supposed to work and then try to get the same commands working on your joystick buttons. It is imperative that you check the FMA (flight mode annunciator) labels in your EADI - the leftmost will tell you the mode the autothrottle is operating in (ARM, THR HOLD, N1, GA, RETARD, etc.). You can not control your thrust manually unless that leftmost column is in ARM or totally blank. Cheers, Jan

Go ahead and doublecheck your button bindings. Test the disconnect of the A/T switch while you are sitting on the ground, not during final approach...that is a bit late to find out that your keybinding isn´t correct. For realistic operation do not turn off the autothrottle switch, just disengage the speed mode (there is a command for that as well). This way the A/T switch stays on, so you can use the A/T in case of a go-around. It will automatically switch to OFF about 2 secs after touchdown. Make sure you have the right "throttle option" selected - due to the improvements for VR pilots there is also now an option to NOT SHOW the ghost throttles, this makes aligning your hardware throttle a bit more difficult. I am not quite sure what is going on with your joystick, but (fortunately) you are the only one experiencing these kind of problems . It is possible that your X52 software is somehow acting up and interfering with normal X-Plane interaction. In my experience it is never a good idea to use the software for joysticks and hotas setups, they only add an additional layer of complexity and default Windows can recognize and interpret the signals of most hardware just fine. Cheers, Jan

There is a different trim setting during takeoff, so setting the "correct" trim will lead to higher-than usual yoke forces needed (due to different downwash model) and the drag is different (due to the different lift/drag of the fuselage during high AOA flight). Both of these things are not super obvious, but you will notice, especially if you are used to flying "by the numbers". Cheers, Jan

Airlines used to be "free" in the way they make their checklist...and in a way they still are. Still there is a strong momentum and benefit to using the manufacturers checklists: Legal liability. If you make your own and things go wrong - your fault. If you operate exactly per manufacturers instructions and things go wrong: Manufacturers fault. The engine driven hydraulic pumps specifically are not turned off - unless there is a malfunction (or if you are pushing back without a steering bypass pin inserted). Never ever. There is no need, because they will only put out pressure when the engines turn. The electrically driven hydraulic pumps are switched off when leaving the aircraft - you do NOT want them to become powered when ground power or APU supplies AC power, because that may suddenly move flight control surfaces and hurt a human being close to them (however unlikely that is). It is procedure to only turn them on after receiving "hydraulic clearance" from a person outside overseeing the aircraft surroundings. You could work around the issue like this, if you prefer to do otherwise (hey, you paid 75$, you own the aircraft!) - just turn off all pumps when you are done, leave computer running with X-Plane open until you want to fly the next day! Cheers, Jan

I don´t think you can really tell - there is no feedback to the user at all. The checkbox in the GUI is not influenced by the setting in planemaker - it will simply stay the way the user has it (on or off). The setting in planemaker will override the setting in the GUI. Cheers, Jan

No, you can not determine the state of switches when loading the cold+dark scenario. I changed the position of some switches recently to bring them more in line with the way switches are in the real aircraft when it is found in the cold and dark state. But out of interest, which switch do you think is positioned wrong? If you can convince me that is should be in another state, I can change them for the next patch. Otherwise I would suggest amending your checklist - instead of amending the plane to go with a wrong checklist ;-) Cheers, Jan

Huh, this is really strange! I checked the output of the datarefs in the pic you posted - and the rudder was the only one deflected, but it was deflected to the left (negative) while the plane was banking to the right...so I believe it is the yaw damper working against the turn, as it should. Wind is not a factor (it is zero) The discovery about your X52 window being open is interesting - and confusing! I do not know how this could make our plane turn. I would try to not use any buttons on your joystick just to test - use the keyboard key "G" to control your landing gear? Also did you check the fuel balance? Cheers, Jan

Keep in mind that I observe the calculations for descent not dealing well with a cruise flightlevel change...while they work "ok-ish" if you pretty much follow the planned profile, changing the cruising level (or starting your flightplan while already in the air) does not work well with the descent predictions. I would recommend leaving the cruiseflightlevel alone (you can still fly higher or lower, just don´t "tell" the FMC about it ;-)) for now. That is something also slated for improvement. Cheers, Jan

Hi, I have no idea and this is the first time I heard about a problem like that with our plane - but this is what I would do to troubleshoot this: 1.) Output "weather" data to screen (little green numbers). A lot of people DO have wind influencing the aircraft but don´t know about it (even a wind set up at 30.000 feet will blow with the same strength on the ground). 2.) Output "flight control deflection" to screen. Really make sure that there is no aileron or rudder deflection when you see the roll happening. 3.) Make sure that both engines spin with the same N1 and that one reverser isn´t open inadvertantly (check orange reverser unlocked light). 4.) Make sure that there is no lateral inbalance due to fuel being inbalanced - both wing tanks (1 and 3) should show the same fuel level. Cheers, Jan

Yes! That being said - the behaviour you are seeing and describing on the FMC is correct. The cruise flight level in the FMC has to be changed by the pilot. Just dialing in something new on the MCP doesn´t do this (this is no Airbus) - in Classics with the ALT INTV button you can use that one to make the entry, but a lot of the older Classics (and the one we model) don´t have that button. So the correct procedure to do a step climb would be to enter the new cruise flight level on the CRZ page and then select an appropriate vertical mode to climb (or descend) to it. Cheers, Jan

Hmm, to tell you the truth I don´t remember if we ever had icing cues on the windshield wiper...we did have it on the windows (the "eyebrow shape"), iirc. I have to check when I get home tomorrow (currently on a trip, flying) if I get icing on the wiper screw...and then talk to Tom if we miss this effect on the CPT´s side. Cheers, Jan

Errm, this is really not much of a problem - you can simply switch the FO´s nav display to show the map and then you will be able to see it on your side as well - the 737 only has one FMC, both CDU´s access it (think like it is a computer with two keyboards attached). So you can simply select the display you want on the FO´s side. You can even realign the IRS you shut down in ATT mode (just wait for a few minutes while flying straight and level). It will realign in attitude mode, so you can now switch your EADI back to it...but it will not supply positional information, only attitude (like an artificial horizon). You will not notice the positional information missing, though - you still have data from the other IRS and also from the GPS receiver...they both update the FMC position, so your map display is still accurate. Cheers, Jan

Hi Fred, yes, when you are flying higher it gets more cold and the rain will appear as snow. We do plan to add more functionality to the IXEG for the XP12 version, including a more comprehensive failure and wear+tear model. Other than that it is coming I know nothing about XP12 that isn´t common knowledge. Cheers, Jan

Yes, we considered using librain, but the Vulkan thing kinda ruled it out. We will definitely wait for XP12 to see if LR offers some native rain effect before we spend much effort on improving our own ;-) Cheers, Jan

Glad you are making progress with finding out what is going on - make sure to let us know when you find the problem, there is bound to be other users who may run into the same problem. Happy flying (and stay away from the ground, except for landing! ) Cheers, Jan

Hmm, are you sure you have not tuned an ILS frequency instead of a VOR? The CPTs side equipment works exactly like the FO´s side, the EHSI can only display VOR and LOC information, not GPS, so there is not GPS/NAV switch on the 737. Not sure, maybe a plugin can interfere, but if the RMI needle shows the correct direction this means that the respective VHF NAV radio has tuned and is receiving valid radial information from the VOR transmitter station and both RMI needle and EHSI deviation bar should indicate correctly. Maybe make a short video clip showing what you do and I can take a look and compare if this is happening for me as well? Cheers, Jan

Hi Fred, 1.) I doublechecked, and everything works as it should on my sytem. Make sure that the needle faces the "correct way" - the little "crossbar" points to the course that you dial in on the MCP. Here are pictures of the aircraft sitting at EDDF 07C, facing towards the FFM VOR (set on CPTs side) and the RID VOR (set on FO´s side) is on the right aft quarter. These are the indications on the EHSIs: As you can see both are showing TO when the needle´s tip (crossbar) points TO the VOR. 2.) I have no idea if that works - we use the standard X-Plane AI aircraft information to read and display traffic information...so if Global Traffic writes to those datarefs, it should work - maybe someone who has Global Traffic can chime in here? 3.) When using the IXEG, it is best to completely forget about the default X-Plane sound sliders, it may be necessary to reset them after exiting the 737, there is some crosseffect...we hope to completely move towards FMOD with the XP12 version of our aicraft...then we will use default XP sound and those problems will be gone :-) The airconditioning sound slider does work on my system, though. Cheers, Jan

There is no dedicated information - the clock works like the real one... You can use the CHR button to start/stop/reset the chronometer. You can use the DATE button to switch between time and date display. You can use the ET (elapsed time) knob (bottom left) to start a long-term timer, it is independent of the chronometer (we use it to time total flight time). The knob on the bottom right is used to set the clock - RUN is the normal setting (it runs), HOLD is used to hold the time until the exact time is reached (i.e. 0 seconds after the minute) and the other two positions fast-forward through the time or date. Cheers, Jan

No idea - one can find other (proprietary) material on the internet, but this stuff is so special. We pilots did not even have those as personal copies, they were on board the aircraft, only. They were issued by a department at my airline - the basis was performance calculation done with the charts from the Performance Engineers manual (climb gradients, etc.) You could do some basic tests yourself were you do some accelerate - stop testing at different weights and different temperatures. Use the "distance traveled" dataref in X-Plane to help you with that. You can also do the same (cut an engine at V1) to determine the net flight path profile. Now measure distance to obstacle to find the required profile and then you can do some ballpark guestimation at which temperature you still "could just make it" (add 0.8% to this for margin). Of course all of this changes with runway state, intersection takeoffs, tailwind, anti-ice on, etc... Cheers, Jan

Hello Jose, often this is caused by using XPUIPC, the 737 is only compatible with one of the older versions - here is a link to a thread where someone else had a similiar problem: https://forums.x-pilot.com/forums/topic/18276-throttle-xpuipc-acars/?tab=comments#comment-156727 The power increase/decrease works fine without it - the only problem we ever heard of was with XPUIPC :-) Please let me know if that helps? Cheers, Jan

I really don´t want to promise anything, but we will certainly look at it. Some sceneries have a very dense terrain mesh, so sampling this mesh takes more time and can be perceivable as stutter. This may become even more prevalent with XP12, if the mesh in it is increased in density - so we will have to do something about it ;-) Cheers, Jan