Litjan

Hehe, the places you people fly to! Thanks for the report - it is the same iteration of the known bug, where the FMS is having a tough time with conditional waypoints and their desired direction... Jan

Hi and thanks for the report. I think the weird route in pic 2 is caused by the plane not being able to make the second waypoint after the bypass. To cure this, try to put RIDSU right after ODAVU or reduce the speed at ODAVU. This is a classical "double bypass" situation, where the FMS has a tough time. We will improve on this eventually. Just for grins: The real FMS will lock up on a "triple bypass" situation (where it can´t make three waypoints in a row), so you have to be careful with the way you code procedures or enter waypoints. Cheers, Jan

The ADF functionality is a function of X-Plane´s ADF system. It will not allow selection of 0.5 kHz and only go to a certain range (999 kHz). Sorry. Jan

Hi Julian, I will doublecheck with my cockpit videos, but I am pretty certain that the FD master lights extinguish when an AP is in CMD. Thanks, Jan

Hi and thanks for the report -- I have never seen this, but could think of a few causes: The N1 should go to the value specified on the TAKEOFF REF page - depending on environmental factors, a derate or thrust reduction selected this could be between 83 and 93% (or so). If the A/T is not achieving this N1 after pushing the TO/GA buttons, it is most likely because either the THR HOLD speed is reached before the A/T is done (this is at 84kts), or because the users joystick is interfering. This would happen if you move the joystick thrust lever down a bit during the takeoff run. The logic interprets this as an attempt to reject the takeoff, and the thrust control is handed back to the joystick thrust lever. To avoid this, follow the procedure that we suggest in the tutorials: After pushing TO/GA buttons, advance your joystick thrust lever ALL THE WAY FORWAR TO THE STOPS immediately. Don´t try to follow the "ghost throttles" or try to adjust to the correct position. All the way forward very rapidly, then don´t touch them. Let me know if this helps, Jan

Hi Graeme, yes, I think you are onto the core of this matter - the only question is if the "REAL WORLD" VOR is also displaying this "wrong" behaviour or not. I have seen it on many VOR´s in California, for example. The published course between VOR´s on V-airways are not corresponding with the magnetic bearings between the VOR´s. I would expect the "VOR NORTH" value to be published along with the database by navigraph or Aerosoft, This is the corresponding line from the earth_nav.dat for the ROI VOR: 12 66.56253900 025.82040800 661 11770 50 0.0 ROI ROVANI VOR/DME The "0.0" before ROI seems to be the VOR NORTH value, and it looks like it is 0 in the default nav-database.... maybe it is wrong in the database you are using? Cheers, Jan

Yep, it is a bug - we are tracking it and hoping to fix it soon! Thanks for reporting it, Jan

Yeah, this is something we have seen occasionally - it is on the list, thanks! Jan

Hi Graeme, To clarify things when I spot differences like that, this is what I do: I output the MagVar and other parameters on the screen. For EFRO I get 11.9 deg var East in X-Plane. Skyvector has a variation of 10.0 deg East. This calculator: http://www.ngdc.noaa.gov/geomag-web/ has it at 11.2 East (and changing to more east fairly rapidly each year, so X-Plane will be more accurate in the next years...) Now there might be a local distortion to the calculated field at EFRO, and X-Plane could not allow for that unless it moved to a tighter grid of var datatables, but since they are mostly "handfilled", this is not feasible. The VOR NORTH value I am not familiar with, but I would assume that this is the TRUE direction that the 360 radial is pointing at (otherwise you would have to change this value again with every shift of the magnetic field). So (just an assumption) this would be the true direction of the magnetic north (the variation) at the time the VOR was INSTALLED (not todays!). There are also some (accepted) discrepancies in procedure design in the real world, I guess. Look at KPHX ILS 08. The runway is TRUE 090. The variation is 10W. The magnetic runway track should be 080, yet the official ILS chart calls for 078... Jan

All correct, but not relevant to the question - this is the barometric decision height used in a CAT I approaches and will never be set on the ADI DH window. That window is exclusively for radar altitude decision heights, and those are only used for CAT II and CAT IIIa approaches. For the 737 the DH is around 100 feet for CATII (you can find the value on the charts) and always 50´ for CAT IIIa approaches. So you need to dial that value to -20 for most approaches (that way it blanks and doesn´t call minimum), UNLESS you do a low-visibility CAT II or CAT IIIa approach. Jan

Difference in EGT/Oil Qty and pressue is normal and intended - different levels, different engine age, it is random. If you open the crossfeed, fuel will never balance if you keep all pumps on - this is a common misconception! One set of pumps is always a "bit" stronger than the other, and if you understand fluid dynamics, you will see that that tank will then supply fuel exclusively. To balance fuel: Turn open crossfeed. Turn OFF the fuel pumps for the tank with less fuel (memorize: Low fuel - low pressure). Wait until levels equalize, then turn on all pumps again and close crossfeed. Jan

The subject is very complicated and not many people can understand and follow an explanation of this. Just in a nutshell: The variation in X-Plane is not always accurate - I made it and it is going to be accurate in 2020 and a bit inaccurate before and after that (it gets worse later, then I will have to make a new table for Austin). The radials of most VOR´s are not accurate - i.e. Radial 360 is not pointing in the direction of 360. This is because the variation changes, and they would have to physically adjust the VOR´s to keep up, and they don´t do that. So it is perfectly normal to track a VOR radial with a different magnetic track than the radials "name". Jan

Thanks for the log - this will help us narrow down on these problems and fix them! Jan

We support LAT/LON as far as they can be found in the FIX database. Jan

The intersect field will take data for a runway intersection takeoff - either the displacement in meters, or the name of the intersection. In the real plane the position of the FMS will update to the runway beginning when you press the TOGA buttons. If you take off from an intersection, this update would be erroneous, since you are not actually at the beginning. So you can enter an intersection value (i.e. 900m) and the updated position will be correct. If the FMS position is being fed GPS data, this update will not be taken into account - so it does not matter if you enter anything or not. The IXEG 737 will always have GPS updating, so entering anything (or nothing) into this field will have no effect. Cheers, Jan

Ok, so it seems to be widespread - I am already on the dev build for the next version - where Nils did some changing of the pointers for the wind-sound... I think it was previously getting the wrong soundsample. At any rate, I am not hearing anything like this on my build, so I would assume that this is fixed for the first "real" update. We are planning to do one more hotfix before that one, though - and this fix will probably not be part of that (only code, no content). Jan

This is excellent advice, and the way I do it - even in the real plane. The electric trim is too sensitive at those speeds. Grab the trim wheel with the mouse-hand and move just a bit. Jan

Hi, I have not noticed this so far - I will try to reproduce it on my end. Do you have the details of your soundchip handy? Thanks, Jan

Hi guys, this is very interesting and I am not sure if this ties in with the general problem of having a limited amount of sound resources at your disposal or if something else is going on. Could you try and do a flight without the VATSIM or PilotEdge plugin installed and see if that helps with the sounds? If so, that would be a great lead... Jan

No, there is no D-TO to my knowledge. Checking the thrust rating on the CDU is essential to avoid having the wrong "max thrust" selected. On my airling, a derated thrust was never used, not sure if other airlines even do that... The effect of R-CLB washes out to 15.000 feet, but I am not sure if the label will change from R-CLB to CLB... something I never consciously watched in 10 years of flying the plane. Simply don´t know and the manual doesn´t state it clearly, either. Jan

Hi Boki, thanks for the report! We will keep working on these crashes - but to find them we need a lot more information - if you want to help, please read the bug reporting guide in the manual, or at least post the gizmo log so we know what the exact nature of your crash was. Thanks, Jan

Or from any other live virus scanner, like Avast, etc. Jan

I am considering it. Jan

No, you can´t cycle like you do in FSX... Jan

Hi Tom, there are different configurations to the gear warning horn, depending on the model used. The one we model can not be silenced at FLAPS 15 if both thrust levers are < 30 deg. Jan