Litjan

Hi Cameron, I had the same windows crash with the same error message that pmorris showed in post 21 (left picture). Good job so far, looking forward to the fixes, Jan

Hi guys, I can confirm the two reported bugs (framerate loss on pause, Event Inspector crash) when testing the IXEG 733 with the latest gizmo beta in 64bit. The framerate does not recover for me, though (I have the framerate limiter off). I also get random crashes (X-Plane has stopped working) when in areas with lots of objects (like NYC) - dropping objects to a lower setting seems to help. Overall I get very good results with this beta, and haven´t spotted anything not working on our prototype as before. Yet. Jan Edit: also captured this guy:

Alright, since there were few questions regarding the content of the previous installments I assume that everyone knows the autopilot insideout and you guys are ready for the 3rd installment of this little series. Exam coming up next week! . Enjoy. Jan

Most bigger airliners have 3 autopilot systems. This is called a "fail operational" system - even if one autopilot freaks out, the other two can continue to do the job of landing the airplane, as they can simply overpower it. Boeing has a system of grading the landing capability on more modern aircraft - they usually asess their own landing capability and announce it on the FMA. The 737-300 can not do this - the pilot is expected to asess and apply the correct minimum. "Land 2" would be a fail-passive system that allows autoland, but with a certain decision height that allows the pilot to take over if one of the two autopilots fails just before touchdown. "Land 3" would be the fail-operational system, where the two remaining autopilots could land the aircraft if the other autopilot fails. These system can actually have no decision height, meaning the plane will land even if the pilot sees nada. Don´t confuse Land 2 and 3 with the Category II or Category III approach, though. While related, it is still different. For example, the 737-300 would technically have a "Land 2" capability (fail passive) if doing an automatic approach with two autopilots. This would enable it to fly a Category IIIa approach, though (50´DH - 200m RVR). Jan

Yes, Rhydian, the two flight-control computers are totally redundant during regular flight. It is important to know, however, that FCC A (left side autopilot and flight-director) are hardwired to the left side instruments like altimeter and VOR/LOC receiver. So if you set the ILS frequency on NAV1 - the autopilot B will never fly it! Thats why the captain will always use autopilot A and the copilot will always use autopilot B. The one exception is a malfunction, for example A hydraulic system down - in this case autopilot A won´t work, and the captain - even as pilot flying - could use autopilot B. During a dual-channel-autoland ILS approach, both autopilots work the flight-controls at the same time. This has the added benefit of a "fail passive" system setup, meaning that if one autopilot freaks out and wants to roll the plane inverted, the other one is strong enough to stop it from doing that . There are several parameters that must be met before being able to engage both autopilots - so it can´t be done for regular flight. Even though you can engage both as soon as these parameters are met, the second autopilot will only actually start working when well established on the ILS. Jan

We haven´t decided on a sound solution, yet. The development version is running with the dreamengine plugin that the developer was nice enough to let us use for our prototype - hence the nice sounds you could hear on the LFMN pattern movie. For the final product I can only say that we will not be using default X-Plane sounds - because we totally agree, a realistic sound scenario goes a very long way in the suspension of disbelief. Jan

Hi everyone, we are busy chipping away on the 737. The exterior is coming along nicely, recent work added landing gear detail and further improvements in various areas. We had quite a time getting the landing gear strut compression and damping coefficients right to maintain the great crosswind capability this aircraft enjoys - so I figured I upload a video of a crosswind landing like I did many during recent testing. The video shows a landing at a very stiff crosswind, more than I have ever done in the real aircraft. In fact the limit for dry runways for us is 30kts. Boeing demonstrated 35kts - but thats for testpilots, the right stuff and all that . Tom is also in posession of the next two autopilot videos, narration and cutting is done, he just needs to annotate them with his nifty arrows. This might give you guys a chance to follow my rapid-fire rambling. Pester him to finish and upload them if you please. Jan

Nice videos! I am sure everyone is aware, but these show the 737-200, the "classics" predecessor, that got phased out in the 90s (just saying so no one comes online and complains how the cockpit looks so different from ours ;- ). I trained on the classics in ´96, we still flew the -200s then, but unfortunately I wasn´t trained on them anymore. All the pilots that flew the -200s loved them for their small aircraft feeling - jump in, tune the VOR and off you go. Funny how I think the classic is like that, compared to the Airbuses I fly now :-(. Jan

I really couldn´t say if it would, because I (and the other teammembers) don´t have one or know how the MCPPRO interfaces with the simulation. I know Tom is very interested in making this aircraft accessible for cockpit builders, so I would definitely not rule out the possibility of getting it to work. I know it is fairly easy to make custom datarefs available to "hook" them up to certain keypresses or joystick buttons, though. I have a few autopilot buttons (TOGA, A/T off, toggle AT speed mode, disconnect AP) mapped to my joystick, for example. If using the MCPPRO is working in the same way as mapping those to regular joystick buttons, then I don´t really see a problem in adding all the MCP buttons to the list, so you can map them. Jan

Pilot viewpoint, a good subject. When you are in the real aircraft, you will try to position your seat in a way that allows you to see the bottom of the ND over the yoke (high enough) but also low enough to still see the yaw damper indicator. If you are too far back, the yoke will block the ND, if you are too far forward you can´t work the controls all the way (dependent on the size of your belly ;-) ). You also move a bit constantly, dependent on what you focus on - outside for landing, inside for IFR or manipulating switches on the various panels. While it´s not easy to find a perfect head position in the real aircraft, the problem is even bigger in a virtual cockpit. The closest you can get is with the aid of some virtual reality controller - I use TrackIR, and I am sure the future will see some really cool stuff (oculus rift?). If you can´t afford a technical solution like this, then preset viewpoints for various situations will be the next best thing. This (X-Plane allows you to set and store like 10 of them) in conjunction with right-click and mousewheel for zoom will allow you to adapt the view to your needs. Also, as Morten said, we have a UI panel that zooms you to some default view positions for various tasks (overhead, FMS, etc.) Jan

Yes, having the real Boeing manuals is certainly great - unfortunately reading official FCOMs is REALLY boring, and I sometimes struggle to remember the stuff I read a page ago . For me it works best when I put into context what I read - so if I read about how the logic of the pneumatic isolation valve works in auto mode, for example, I have a big question mark over my head - but when you get a chance to throw some switches and see the effect, it becomes crystal clear very quickly.

The 737 NG and the "classic" are very similiar in most systems, so if you are proficient in a NG you should have no problem flying a Classic and vice versa. I think the EADT 737 is an absolute masterpiece and work of art, so it´s definitely a viable option to get accustomed to this class of Boeing airliners. Jan

As far as the pure availability goes, we want to have a bit more option than that - just having the GPU plugged in already has an effect on the electrical system of the aircraft, so we want the user have the option of having it available or not. In real life you will have ground power at most destination you fly to, and using it is strongly encouraged as it saves precious fuel in APU use. But sometimes its not available, especially if you fly to an airport that doesn´t service bigger aircraft regularly (diversion type scenario). If worse comes to worst and your APU isn´t working, you´d have to service the aircraft for turnaround with one engine running. First the right one (so passengers can disembark on the left), then crossbleed start the left one again and shut of the right one (to enable fueling/cargo service). I fortunately never had to do that. Once I arrived at an airport where the GPU wasn´t working with an inop APU and we just had to shut down the engines and the passengers then disembarked under the gloomy lights of the emergency lighting system (I warned them beforehand ;-)). Jan

Yes, the passenger cabin will be modeled in full 3d, Tom already has a few rows of seats in, and you can move about in it. We plan on doing some ground equipment, but it´s not on the highest spot in our priority list, and implementation needs to be in a (sorry Austin) "plausible reality" way. We are unsure about stuff appearing out of "thin air", but would also be not happy with trucks driving through buildings and such. I guess we need to look at the competition and see how they do it . I personally could see the GPU wires come out of a ground socket like they do at many airports... we will see. Jan

On behalf of the team I would like to thank everyone for the kind words. I am also very excited about this plane - currently, as the designers are busy on 3D and textures, my job as a technical advisor has become a bit more quiet. Usually I will just add some input if I think something looks odd, but since all the pictures, movies and drawings are in our repository, they can do their job without my input, and a great job they do. This gives me time to just fly our plane - and I don´t want to tease you, but it is just so much fun! The systems are pretty much done, with the exception of some small stuff like the fasten belts signs, passenger oxygen, emergency exit lights switch and such. So I can operate the plane very much like the real one, and I fly it back and forth all over the place, different times, different weather, different approaches. I keep adding small stuff I find to a big list of minor quirks that will need polishing before release. The 3D is coming along nicely, and we will be able to show some really awesome detail-shots pretty soon. I also plan to do another movie in a bit, this time about the autopilot/flightdirector system and it´s modes. Jan

I totally agree with you, I enjoyed having the windows there. But the airlines did a survey on their necessity, and the verdict is that they aren´t as useful nowadays as they were back then when airliners still did more low circling approaches and had to rely on spotting other traffic more than today. So they decided to fill these windows with "plugs", thereby removing the need for maintenance on them and saving quite a bit of money in the process. There are nowadays no 737s in use at Lufthansa that still have those windows. Jan

I used to fly all 737´s that we have, so not limited to a certain registration. Also note that the real D-ABXX carries the name "Bad Homburg v.d.Höhe" - while this one has the name of my hometown. It´s more of a working livery to keep me amused ;-).

Is it just me or does anyone else have really no clue what this is all about?

Thanks - I was wondering why the views on it splurged ahead like they did! And thanks for everyone´s nice remarks - we are humans and definitely cherish the appreciation. Just like a soccer team plays better when they get cheered on by the homecrowd ;-) Jan

I hope it will fly as well as it looks! Very impressive, really looking forward to this! Jan

PROGRESS REPORT Hello everyone! We are back working a bit more aggressively on the 737 and I wanted to provide a short update. We are currently working on exterior 3D elements, flap mechanisms and soon to be texturing. In addition, we are filling in holes in some of our systems, for example in the electrical system we have now implemented automatic galley load shedding, the magnetically held ground service switch and ground service bus with automatic GPU disconnect as well as galley loads, so when the coffeemaker or hot-air oven comes on in flight, you will see this reflected on the overhead ammeter gauges drawing power from the generators. We have also implemented a custom battery drain model that works exactly like the real thing, even when in emergency standby mode. You will have to manage your power draw very closely within limits and think twice about when and if to try to attempt an APU start when running on standby power (battery only) as the APU starter engine draws enormous current. We have included the battery charger model with charging modes of T/R, charge and pulsing. When the battery gets close to full charge, the charger will pulse current into the battery and you can see this on the DC ammeter. In fact, when you do an APU start and deplete the battery a bit, you can then observe the battery charger immediately after the APU comes online once you connect the APU to a generator bus. If you have the GPU connected, then the charger will begin charging immediately after the APU start sequence. Current and voltage are tied closely so when the battery starts to lose EMF, the current will also get smaller. Generator heating with amp loading is also modeled, along with the IN/RISE indicator. If you ask yourself: "How will this affect my daily flying?", then the answer is "not much if everything works correctly". This electrical stuff works behind the scenes, and you would have to watch indications closely to catch a glimpse of all this. But the beauty of modeling it to this extent is that you get VERY realistic behaviour in non-normal situations. If you loose the ability to generate power all this becomes very important. Suddently your life depends on that battery that keeps your instruments going...Boeing guarantees 30 minutes including one APU start attempt. What if you are 60 mins from the next airport? What if the APU won´t start, or can´t be connected to it´s generator? Do you want to descend to assure it starts? But then you are too low to get to land quickly enough if it doesn´t! Will you turn battery power off to have some juice left when you get to that airport (you need power to run the ILS receiver!), but then you´d loose the IRS and your primary attitude information... a dire situation, and with the way we model this you can actually run through the options and see how it turns out. We will include some "special situations" like this on top of the tutorials, just to introduce you to the depth of the simulation and give you an idea of the choices you would have to face as the pilot of a 737-300... We will definitely get a movie or two out before Christmas, highlighting some of this stuff and showing you how far the plane is really along! Your IXEG dev team

Hi Dozer, all great ideas and we have discussed that already quite a bit. For our V1.0 this will not be included, we simply want to get this done with the basic (normal) functions as fast as possible. But functionality like that should be easy to add later, as a matter of fact Tom has already done a script that can deliberately "fail" any bus, so we can check the respective equipment going dead as it should. I know that the hydraulics is also coded in a way to handle "leaks", for example. Some default XP failures work as well (i.e. engine failures), and of course there are all the failures that can be emulated by simply switching "off" the system in question. Actual "degradation" of systems is not really something that is a big issue in passenger jets, except for the tires, maybe. Most systems either work flawlessly or they are replaced. If a system gives us advance warning by performing less than nominal we consider us lucky. Usually stuff simply fails. Jan

Hi everyone, development is going kind of slow these days. Working on the FMS is really tedious, this component is a total bug-generator! While just getting the "normal" operation working is challenging enough, the "what-if" scenarios are absolutely mind boggling. It is not suprising to me that the real FMS is already at version 10.7 and still quite a few documented bugs persist... To take a little break from that and to give ourselves the reward of making something visually more impressive we have recently implemented the outside lighting (minus the emergency exit lighting and wheel well illumination, those are still to come). I have created a little video for you, and would like to point out a few prominent features to look out for: - Outboard landing lights, with correct timedelay for extending and retracting - Inboard landing lights, all with correct angles and light cones as specified in the manual - Runway turnoff lights pointing outwards from the wing roots - Taxi light that turns with the nosewheel - Position lights, either powered from the transfer bus 2 or the battery bus, dependent on switch position - Logo lights in the wingtips, illuminating the airline insignia on the tailfin - Strobe and anti-collision lights, both with custom frequencies - Wing illumination lights to light up the leading edges (for ice detection) All lights are powered by the correct busses, so if you turn off engine 2 during single-engine-taxi-in you would (as in reality) loose the left inboard and right outboard landing lights, right runway turnoff lights and logo lights. Unless you have the APU generator power main bus 2, of course... The video was created with HDR on. B733_9.mov Jan

No, thats a NG in that video - airflow from gasper outlets is radically different on the classics on a submolecular level that will float anything BUT aluminum balls . Jan

Hi everyone, we are still deep into the FMS and it´s implementation - but we feel that we are over the hump and will have this section wrapped up within a few weeks. Tom, who is in charge of generating the lateral navigation (LNAV), has posted a new blog over at our website: http://www.ixeg.net/...ve-lnav-routing I just want to share this screenshot I took yesterday night when testing the path-drawing algorithm on an approach to EDDV (Hannover, Germany). It shows me coming in from the north towards the Celle NDB (CEL), followed by the RNAV transition to runway 27R. I named the screenshot "Childrenofthemagenta" as a reference to the excellent video that was linked to in THIS post by Andy Goldstein. This guy has it perfectly straight: http://forums.x-plan...11 Jan