Litjan

Hmm, I just tried - I can click the button on my joystick assigned to "one notch up" as fast as possible and don´t see anything like you show. There are also separate commands in the IXEG command menu for every flap setting - so you can just map a button to "flaps 15" and that should take care of the problem. Cheers, Jan

Here is the latest BETA for gizmo - I run it and it works great (more smooth on the framerate). However - make a backup of your old folder, first, then overwrite it with the new beta. Two things: 1.) You will have to "copy and paste" your email for authorization, the new beta does not recognize the @ key sometimes. 2.) You will have to edit manually: X-Plane/output/preferences/gizmo_prefs.txt Find (or create) this: { name="AutoLicenseUpdate_Always", value=false, },   Make sure the value is false.  Otherwise it will run in an endless loop asking you to update your license. Cheers, Jan

I have to say again that we have not heard of any incompatibilities like this before. I would assume that there are many people running Skymaxx and the IXEG. So there may be something more specific to your case than simply those two "not being compatible"... Cheers, Jan

Hi Speedbird1229, it is really not possible for us to tell what is going wrong on your system - at the least we would need to see some of the diagnostic files - like the Log.txt from your X-Plane folder and the GizmoLog.txt. I think that the IXEG and SkyMaxxPro run well together, as otherwise we would have heard a lot more about it. Chances are that they are either interfering with another add-on you are running, or that you are running an older version...or maybe have upgraded to 11.50beta? Cheers, Jan

Thanks for your help and input everyone!

Hi Jim, sorry to hear that you have problems - first time I heard about the AVG...and I don´t have that myself. I am sure there must be a way to set up an exclusion, maybe google it or even ask at the forums. Maybe someone with a Mac and AVG can chime in? Cheers, Jan

There are two strenghts brake that you can set in X-Plane. One is 50% (B key) and one is 100% (V key). I am sure you could map those to different buttons? Cheers, Jan

Not sure I understand that request? I can set the amount of brakes individually with my brake pedals going from 0 to 1.0 seamless. Using the autobrake allows preselecting a deceleration rate. Note that MAX is not the maximum possible. That can only be achieved with full manual braking or the RTO mode (not to be used for landing). Cheers, Jan

Doing some testing and shakedown flights to make sure all new features and fixes work as planned. So far things are going really good. ...at least for the passengers on MY aircraft .

Hi Cassio, The update will be applicable and work for all XP11.30+ users - and with some caveats to all other users at well: It must be noted (and we will make everyone aware at the time of download) that it is tuned for the "new experimental flight model". This means that if you run an X-Plane version that does not have this flight model option (which will become the norm in the future), your IXEG 737 will still work and fly - but the performance will be off (a bit). To make our 737 work well with the new flightmodel required tuning of the aerodynamic model in planemaker and airfoil maker, and it is not possible to switch those modifications on and off in the code like we did for our "scripted" flightmodel adjustments. So for the XP10 and pre XP11.3x fliers out there: The 737 will still work as before - you can either not apply the patch or you can live with the slight discrepancy in the flight model. I really don´t see a reason to not upgrade your XP11 version to the latest, though (you can still run OpenGL mode in 11.5x+!). In general it is obvious that we would like to have continuous support for all three versions (XP10, XP11.0x and XP11.3x+), but eventually the complexity of this is getting too big. Just like X--Plane itself our product is evolving and following progress...which means that older versions may become obsolete after a few years. I know that some people can´t afford to upgrade to newer hardware that supports XP11 or have built elaborate home cockpits that run XP10, only - but I don´t think it is fair to the vast majority of users that stay in tune with the development of technology and X-Plane to forego an evolving product to cater to this small (yet sometimes very vocal!) minority. Cheers, Jan

It is the former (equivalent amount of time). The FMS is getting more of a full rework as opposed to just adding a few items to patch it up - this will entail a full shakedown testing and therefore require a bit of time (work is underway on that). This isn´t necessarily dependent on XP12 - if that was never to come out, we would still do this FMS update. We know that XP12 will come out sometime. I don´t think it will take "years" until we see it. It will probably bring new features and requirements that will make us want to adopt our aircraft to it. So it is an apt milestone for us to aim at for the next big update. Cheers, Jan

You can "tweak" your response curve accordingly - basically drag it all the way down to "0" around the middle point - that way a slight deflection will yield no response -> null zone. Cheers, Jan

Buon giorno, there could be many reasons for that - I suggest reading/watching/following along the tutorials I made for this aircraft, all found in the "Documentation" folder of your IXEG 737 installation! Ciao, Jan

You may also want to look at the tutorials I have done for this aircraft - they are included with your installation (look in the folder Documentation). They are both in written format and include a link to youtube tutorials as well. Cheers, Jan

That is correct - Airbus recommends to keep autothrust on (they know the pilots they train )... Airbus´ flight-law augmentation will compensate the pitch moment from the engines for you, so this does not pose the same problem that Boeing has. Cheers, Jan

Hi Doeke, 1.) Not sure - if you just got this aircraft, you should already have the latest version. 2.) I don´t have enough information on what you did (or more importantly what you didn´t do!). Are you sure the GS was armed (APP mode)? 3.) Oil pressure and quantity have no real effect in X-Plane - but I haven´t seen them being low, I think. So maybe you can include a screenshot of what you see so I can tell you if it is normal or not? 4.) Yes, unfortunately our VNAV code still has some problems with altitude restrictions during the descent. We are working on fixing that - for now use the FL CHG or V/S mode to descend te aircraft in time to make the restrictions. Cheers, Jan

Hi Jaime, can´t resist a good discussion like this ;-) You summed up the operation of the different modes nicely. I would just like to clarify the function of the ARMED autothrottle mode. In this mode the autothrottle will "wake up" whenever it is triggered by any of these events: autothrottle reversion (low speed, placard) TOGA mode activation (take off, go around) automatic activation (MCP SPD, RETARD) in case of pitch channel mode change while in autopilot or flight-director flight OR triggered by yadar altimeter during approach at 27ft RA if in MCP SPD. The last point is the one that offers reason for different views. It was originally implemented as a safety feature. The logic is that it would be dangerous if the pilot forgets to add or reduce thrust when the pitch channel changes (i.e. the plane levels off -> gets too fast). So Boeing thought it would be good if the "current speed" is maintained automatically. The downside to this good idea is that when you are flying manually WITH flight-director (the majority of airline pilots in many parts of the world can not fly without it anymore), this MCP SPD mode will engage again and again. First when ALT ACQ engages, then again when ALT HOLD engages, then again when you command a vertical speed, and so on. While this is a nuisance (you have to command "deselect MCP SPD" to the pilot monitoring all the time), it has also caused confusion. Many pilots did not understand this behaviour and have gotten in trouble controlling the aircraft manually while the autothrottle commands thrust (pitching moment!). The danger here is that the autothrottle reduces thrust on level off (to maintain speed) and the pilot does not notice - the nose will sink! Now the pilot pulls back to climb back to the assigned altitude and the autothrottle will increase thrust to maintain the speed in the climb - now the nose rises too much! Try to fly the IXEG with autothrottle commanding speed for you - it is not that easy! So Boeing had to act and recommends now to totally disengage the autothrottle when in manual flight (with flight director). Of course it is more dangerous to fly without the autothrottle in ARM (one less safeguard against speed mishaps), but the above behaviour is also dangerous and they probably had to weigh what is more likely to cause a crash. Two more remarks: 1.) You NEVER set the MCP ALT for the MDA for a non-prec approach (if flying according to real procedures). It will be set to the missed approach altitude. Setting it to MDA is dangerous, because you could forget and then the autopilot will try to level off! ESPECIALLY with the autothrottle in OFF this is a recipe for disaster. 2.) The autothrottle is supposed to provide gust protection on approach. That is why you don´t set any wind-correction speeds while doing an automatic landing. The autothrottle is supposed to handle that. I personally think that this is a lie (from what I saw during the automatic approaches I did in the real aircraft), but the reasoning here is probably that a.) on a low-vis approach (with it´s associated wind limits!) the wind isn´t strong and b.) even if the speed decays by 10 kts before the A/T covers it - its not going to kill you ;-) So in conclusion: If you fly manually, fly with the autothrust not commanding speed. It is ok to have it command N1, of course. I personally would recommend having it in ARM during the approach at least (where you are likely to encounter a low-speed situation). Setting go-around thrust manually while at the same time flying the aircraft manually (you have no second pilot to do it for you in X-Plane) is at least very challenging. You want to hit the correct N1 value fairly quick to stay within the certified performance for the go-around. It works well to have it in ARM during fully manual (no flight-director) flight as well. It won´t engage during level-off or other pitch-channel changes (since the pitch channel of the FCC isn´t even working). Having it in ARM will provide the benefits of it´s protection, though. If you fly manually with flight-directors...go with the Boeing way, I guess. Cheers, Jan

...and have adjusted the lights up for the next version.

I will give it some thought!! Cheers, Jan

We do get complaints about the lights being too dim from time to time. For me the lights are pretty much like I have experienced them while flying this plane. So I attribute these reports to two categories: 1.) Reports like yours where the screenshots are quite a bit more dim compared to what I see! 2.) Reports of users that expect aircraft landing lights must be really bright because how can you see the runway without them? Landing lights are tilted down, so they can illuminate the touchdown zone as you approach it (with 1-3 degree pitch up). So while sitting on the ground, they don´t shine very far, they are angled down 4-6 degrees! They are designed primarily to increase visibility of the airplane for others, not to illuminate a dark runway enough to land on it. That being said, I think they could be a little brighter, but: You can adjust the intensity in Planemaker, viewpoint. I think they are already as bright as they can go (700 meters out of a maximum of 999 meters) - so just like the annunciators in the cockpit they could be a little brighter in my opionion, but X-Plane´s lighting code does not allow that. Cheers, Jan

Does it work when you just use the buttons? Note that if you assign an "axis" (like a lever on your joystick) to the speedbrake, the button commands will not work anymore. You will then have to move your speedbrake with the lever. The autobrakes (position RTO, OFF, 1,2,3,MAX) have nothing to do with the speedbrakes, they only work on the wheels. Jan

Yes, that is essentially what I see, too. I didn´t see your mouse when you clicked the the ALT HOLD, but if you did it, then the behaviour is of course correct. The two things that are not right are: 1.) Orange speed cursor moving "up" to maximum speed (it should move down slowly in relation to "VNAV PATH ERROR" shown on the vertical deviation bar). 2.) Aircraft descending while in ALT HOLD. It looks like it is "trying" to follow the VNAV PTH, but it should not at all while in ALT HOLD. It could very well be some variable going to an extreme - this is the type of bug that is hard to troubleshoot because you often have to have the "exactly right" conditions to see it. I invite you to watch this behaviour and see if you can repeat it consistently. Of course you did the right thing - when the automation *** up, reduce the level of automation or even revert to manual flight. We are Boeing pilots, not Airbus ;-) Happy flying, Jan

It should not go down, and if you look at your video, it didn´t - it stayed at the flight level and increased speed (that was wrong). I think you maybe pushed on your yoke by accident, the autopilot went to CWS pitch for a second. Pushing on the yoke while the autopilot flies will actually change the pitch a little bit... I just tested the behaviour here on my end and it worked as it should. The speed cursor drives down slowly, while the VNAV PTH changes to ALT HOLD. Energy trading. Not sure what happened during your flight, some weird combination of values, maybe... Cheers, Jan

Hi Jaime, I have to check this behaviour again - what you see (initially) is quite normal - the aircraft will start to reduce speed to "trade energy". In other words, it assumes (if you have not reset the MCP as requested) that you need to maintain the current altitude for whatever reasone (usually ATC, some traffic below) but would later on like to regain the pre-calculated descent path. So it "helps" by reducing speed, which you can then later regain (by descending more steeply) and therefore have an easier time re-intercepting your calculated descent path. The minimum speed commanded should be green dot (minimum clean), though. Looking at your video it looks like the speed bug goes to maximum speed (and the aircraft accelerates), though. This would clearly be a bug! Thanks for bringing this to my attention, Jan