Litjan

Thanks, Ben - I dare not to tinker too much with my router settings. I remember an unfortunate attempt a few years ago to open some specific ports and that went really not well at all. I prefer the "get the long LAN cable out of the basement and run a bypass" solution . Cheers, Jan

Update: Finally got it to work, and I am posting how here to help other people with the same problem and X-Aviation in troubleshooting the problem. This is how my computer is connected to the internet: 1.) The signal (DSL) enters the house and goes into a WLAN router. 2.) The line goes from the WLAN router into a second WLAN router (in my office), type Netgear WGT624. 3.) The line goes from the second router into my computer. This configuration did not work with the download. However, when I plugged my computer directly into the first router (bypassing the Netgear), things worked flawlessly. Off to some winter flying! Jan

By using a conversion table - and now look at that: It is mounted right in the cockpit for your convenience. Gee whiz! Jan

Update: Tried with the firewall off, seems I got a bit further this time - about halfway...

Hi Cameron, yes, I run the regular firewall that comes with Win10... I always get the message at the same "spot" in the download, when about 1/3rd through the first (of three) packages. Never had a problem with downloading from X-Aviation before, so this is somewhat puzzling... Cheers, Jan

Hi everyone, during the download I got this error several times - only "ignore" allowed me to get past it (see attached screenshot). Then, during an attempt to load seasons into X-Plane, I get an onscreen warning and this in my log.txt: 0:00:00.000 D/HID: HID Bridge Running 0:00:00.422 E/SYS: +------------------------------------------------------------------------------- 0:00:00.422 E/SYS: | There was a problem loading the scenery package: 0:00:00.422 E/SYS: | Custom Scenery/SeasonsXP/ 0:00:00.422 E/SYS: | The scenery may not look correct. 0:00:00.422 E/SYS: | Please see the Log.txt file for detailed error information. 0:00:00.422 E/SYS: | (io_locate.cpp:394) 0:00:00.422 E/SYS: +------------------------------------------------------------------------------- 0:00:00.422 E/SCN: Custom Scenery/SeasonsXP/library.txt: 0:00:00.422 E/SCN: Incorrect version for scenery library file. Will skip. Running XP11.20. Any ideas? Thanks, Jan

Hi Patrick, we use a whole bunch of custom code to control systems, so not everything that works for the default planes will work for ours...however: I don´t have the PFC but you may want to check any buttons for moving "mixture" to lean or cutoff, I think. The engine controls are pretty much default X-Plane, and when they run, the only thing stopping them is either the "mixture" setting (emulated by the idle/cutoff switches) ... or you may be toggling the fire switch inadvertantly (check on the center pedestal if one is "up" a little bit)... For the spoiler, reversing the direction may work - or it may be assigned to a lever so it won´t react to button input, no idea how you try to control it. Good luck, Jan

Thanks for letting us know it worked for you! Cheers, Jan

Hi everyone, I discussed the behaviour with Laminar Research, and they found this out: ************************************************************************ I got to the bottom of this. There is a nosewheel spring constant entered in Plane-Maker for the IXEG that is NOT in the LR 737. More details: 1. X-Plane 10 allowed a spring constant on a nose wheel or tail wheel, e.g. think bungee steering on a C172. 2. X-Plane 11 supports this ONLY for tail wheels - the code for bungees is a little hacky and doesn't work with the newer wheel physics in v11. Having proper nose wheel bungees is on Austin's future todo list, but for now X-Plane only uses this for the tail wheel (true for ALL of v11) for 11.30 Austin has a wording change coming until we fix all of this. 3. X-Plane wheel steer with differential brakes automagically if the plane has bungees OR castoring. So: set the spring force to 0 (correct value for an airliner, right??) and the brakes will stop braking. In the future we (LR) may start ignoring this variable if there is no tail wheel. ******************************************************* So please try to change this (if you are affected) in planemaker: Opem the 733.acf in planemaker, then open STANDARD/LANDING GEAR and click the GEAR DATA tab. In th top right corner you can see the "nosewheel spring force" - it is currently set to 30. Try to set it to 0 and let me know if this fixes the problem! If this fixes the problem, we will change this for the next update! Cheers, Jan

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