Litjan

Correct, we need to concentrate on this one first. Easiest would of course be the -500, just very minute changes. The -400 has a little more system difference, like a zone-controlled airconditioning system, for example. The -NG is a whole step up and would require extensive work. Also keep in mind that we do get tired of working on one aircraft (-family) all the time, so I am not sure we would want to jump right into another 737, even though we could reuse a lot of our code. This is not only about making money, it should also be fun from time to time. I do expect us to spend almost another year or more on this one after release (updates, additions, etc.), so a new one is REALLY far off... Jan

Dev update: I am currently taping movies for the tutorials that will be included in the documentation (most likely on youtube in our channel). So when you can´t figure out what we ment to say in those tutorials, there is now a video to watch alongside, so you know what we would like you to do! Cheers, Jan

Sorry, no. Unless you leave your computer running while you are away, the plane should be in the state you left it in (unless you ran out of fuel/battery juice)

Yes, the tutorials will be free, both written and video. But they will cater to the average simulator pilot, starting with a very simple flight-pattern all the way to more complex flights with full use of FMS and autopilot system. I am pondering the idea to make more in-depth and detailed videos, covering special aspects like approaches, abnormals, etc. at a later stage, possibly as payware for a small price. But the basic documentation and tutorials for this plane to get you up and flying from quick-flight to serious LNAV and VNAV are always free!

During our initial beta testing all the testers went through our tutorials, which were in "written" form. While we will have those, all testers said that a video would go a long way in making everything even more comprehensible. So I am likely going to start on the tutorial videos soon, and there is a chance that we will release those before the actual plane on our youtube channel. Not decided yet, however. Cheers, Jan

Not yet, and quite likely not for version 1.0, due to time constraints. But it´s entirely possible to fly from the FO´s seat and have the weather displayed on the CPTs EHSI. You just have to glance over. It´s not ideal, but possible. Aside from that, in the real airplane the crews will often pick ND settings that complement each other, it´s not like a strict "this is mine, that is yours". For example you can have the expanded rose with a radial on your side during a VOR approach, while the other crewmember has the map displayed with weather or terrain superimposed for situational awareness... Jan

The NG is a possibility, although so far we are not even thinking of the next airplane as all of our braincells are busy working on this one! Cheers, Jan

Take a look at the KPHX-KLAX video part 1 - at 09:40 I am entering the V speeds... Cheers, Jan

I would like to point out to anyone who hasn´t received word about this move yet, that all information and discussion about the IXEG 737 has moved over here: http://forums.x-pilot.com/forum/169-ixeg/ All video´s can be watched here: https://www.youtube.com/user/IXEG1 We are looking forward to your questions and contributions in the new forum - we are still excited about our aircraft, and it is slowly getting time for you to get excited, too! Cheers, Jan

No, the version of the FMS we are modeling does not support this. Later versions of the FMS (as found on 747-400s, for example) do that. You can just enter airways, and the FMS figures out the intersecting waypoints. But the one on the 737 Classics couldn´t.

Yes, the CWS mode is almost never used. It would - for example - not stop the climb at the MCP ALT. But if you just engage CMD A then the default mode is CWS P and CWS R. In this mode the autopilot WOULD actually level off at the MCP ALT (changing to ALT ACQ and ALT HOLD).

CWS P (as a pitch mode in the CMD mode) is used all the time during climbout, when you don´t want to exceed 7 degrees of nose-up for fear of the trolleys tipping over.

Hi everyone, this thread has been quiet all too long, and it is mostly our fault for not providing more frequent updates. This time we don´t have a new video for you, but things keep progressing nonetheless. We are still targeting a release in 2015 - again this is not a promise, but our very urgent desire. So where are we at? As you all know, the airplane is almost complete, save for some minor 3D items, like the outboard landing lights, movable cabin doors, a moving ouflowvalve vane, and a few more. The bulk of the documentation is also there, but it needs to be formatted into a nice document. The biggest chunk is still the FMS. We have the PERFormance part working, maintaining weights, takeoff page, approach page, etc. The RTE page and entry of a lateral route already works (as you could see in the latest videos). We are still missing the VNAV calculation, and the PROGgress calculation (estimating times, fuel usage). Two weeks ago, Tom Kyler, our lead FMS programmer, spent a week at my place in Germany, so we could crunch down on the VNAV part. We had done a similiar session a few months ago, where we worked on the VNAV climb part, now it was time to do the VNAV PTH and SPD descent. So what is VNAV? In a nutshell, VNAV is the vertical path that the plane takes along the lateral route. The climb, cruise, descent and missed approach phases. VNAV is pretty complicated, as the computations try to predict the vertical profile (a non-linear climb), and the descent (mostly an idle-power descent), provides altitude and speed predictions for the waypoints (therefore changing the lateral route again, due to changing turn radii) and heeding several different types of restrictions. The climb is "fairly" straightforward: The aircraft will climb with maximum climb power to the cruise altitude. It will, however, change airspeed at least three times, and possibly come up against altitude restrictions that delay the climb. All of this can be changed and modified by the pilot, so we need to take that into account as well. The descent is almost a climb in reverse, but the goal is now to target a three-dimensional spot in space, again changing speeds and descent regimes, ducking under and levelling off for altitude restrictions, taking into account all sorts of influencing factors (wind, weight, etc.). We also have to provide steering cues for the autopilot to do the right thing - climb while in the climb phase, level off for altitude restrictions and the cruise altitude, follow a three-dimensional path during the VNAV PTH descent, hitting deceleration segments, etc. It is absolutely mind-boggling - but we are on a good way to get it right! Tom has actually written the code to identify the E/D (end of descent) point correctly and reliably. It is "the last point before the end of route or route discontinuity with an AT altitude restriction". Try to put that into code. Phew. We hope to have VNAV in testing by early October. The CRZ page and PROG page are mere matters of coding crunch, adding up mileage, divide by groundspeed, multiply with fuel-flow... that kind of thing. Not trivial, but a piece of cake compared to the LNAV and VNAV computations. I really hope that many of you will exert the effort to understand and use the VNAV functionality of this aircraft - unlike most real-life pilots, who consider the VNAV button a "magic button" where you "never quite know what the airplane will do". That´s it for now - you can expect to see more frequent updates here from now on until we relase. Cheers, Jan

Hi everyone, two new videos are up on our youtube channel. https://www.youtube.com/channel/UCcuYmGFREqwGyHhsYlDPtMA Enjoy! Jan

Hi guys, just wanted to share the changelog for the new internal beta that we put out to our small test-team just recently: Here's what's changed in Beta 2.1: Fixes: Incompatibilities with Carenado aircraftCalibrated several soundsSeveral problems with cabin control in auto/standby modeAPU CTD bugLight logic for fuel low-pressure lightsSeveral miscellaneous bugs related to auto-flight systemFlight model tweaks to improve handling in ground effectImproved effects for rain/snow on windscreenTakeoff config warning behaviorYaw damper engagement/warning logicSeveral fixes/improvements related to GUIEngine start sequence (speed, egt, etc.)Rudder deflection angles with trimDozens of small micro fixesRange of weather radarSpeed-brake servo behavior for RTO and auto-deploy/auto-stow What's New:Engine 3D fans/spinner and new soundsPreference checkbox for "vintage" engine steam gaugesPreference option for wingletsFly-out menus along left side. Move mouse cursor to left edge for main menu fly-out. Move mouse to lower left corner for views menu fly-outSeveral areas in the cockpit improvedEmergency cockpit lightingExtensive work on FMS route LEGS page entering/editingAuto-disco added between takeoff and landing proceduresLEGS page point deletion/discoLEGS page shortcutting addedLEGS page direct TO added (WIP, in flight routing not calibrated)LEGS page manual waypoint entry for navAidsVNAV for climb phase added (perf numbers not fully calibrated)LEGS page manual override for ALT/SPEEDS (WIP, not calibrated)Independent DUAL CDU entry on several pages (WIP)APU inlet door animationVisual nicks, scratches and reflections on windscreenMini EHSI preview window whenever EHSI controls are manipulatedQuick Ref Card. Click the little slot above the MCP to take out and put back Thanks for participating in our beta program to help create a better product! Cheers, Jan

I have an i5 2500k and a GTX770. Jan

Hi everyone, we have finished another short preview video, you can find it on our IXEG youtube channel or by directly following the link below. No, the plane isn´t done yet, the bulk of the remaining work lies within the FMS algorithms, and of course there are some loose ends all around that need to be tied up. I hope this video will get you over the holidays, and that this Christmas is the last one you have to spend without the IXEG 737-300 sitting in your aircraft folder! Merry Christmas, Jan

Alright, with much delay (after a rainy vacation in Turkey), here is the next sneak-peak at our beloved 733. Todays video is featuring the "Speed trim" functionality. While I explain very shortly in the video, here is the lowdown on the system: The speedtrim system was implemented by Boeing because the 737 can exhibit poor speed stability at very low speeds and high thrust settings (i.e. after a go-around). The nose-up moment of the engines can be stronger than the aerodynamic nose-down tendency for speed loss, so its possible that the airplane would get into very low speed regime with an unattentive pilot. Boeing has therefore tasked the flight-control-computer with watching the speed trend in certain situations. If they detect that the speed is going up or down, they will utilize the autopilot stabilizer trim to combat this trend. The pilot will sometimes be surprised, because the plane seems to "work against" him. He pushes the nose down to accelerate, and the bleedin´ plane trims nose-up again? What gives? Well, it works as designed. To avoid fighting with the speed-trim, use the electrical trim switches on the yoke. This will send a new target speed to the speed-trim mechanism, and will also disable speed trim for 5 seconds. Another way to disable it is to push the yoke in opposition to trim movement. This will ALWAYS cut out the autopilot trim, and also the speed-trim. Of course when you release the yoke, it goes right at it again. Here are the engagement criteria for speed-trim: - Flaps not up - Airspeed 100-300 KIAS - 10 sec after lift-off - 5 sec after releasing trim switches - N1 above 60% - Autopilot not engaged - Sensing of trim requirement Here is the video: Jan

Hi everyone, we are alive and kicking. The last weeks have been a flurry of activity. We are still in bug-hunting and polishing mode, with the FMC being the last big thing on the "to do list". No ETA, but several months to get that one up to speed, probably. Just a short list of issues adressed and fixed these days: Fixed bug where autothrottle would enter N1 mode during FL CHG descent if user propelled airplane aloft with local maprefined AFCS logic when changing pitch modes, to always correctly retain speed assignmentfixed a crash bug when shutting down or starting up engines if randomly assigned "engine age" reached extreme valuesfixed computational problem at extreme thrust settings which made thrust fluctuatefixed a problem with user preference not being saved between sessionstuned and improved starting behaviour of engines and APU to more closely mimick real lifefixed takeoff config warning to sound for all flap settings, except 1, 5 and 15fixed the overheat test button for the wing-body-overheat to stop making repetitive soundfixed the wing-body-overheat warning triggering the wrong master caution fieldchanged autopilot to also disconnect in case of electric stab trim, moving AP trim switches to cutout or moving EFIS/IRS transfer switchesfixed cabin altitude behaviour for going into safety-relief-valve mode during climb and then being stuck in that modefixed auto mode of pressure controller to honour maximum press differential of 8.0psi if flying above set FLT ALTfixed PASS OXY ON behaviour to trigger manual or automatically (14.000feet CA), a one-shot device (light stays lit)and several other small fixes and refinements I will try to shoot a short video for your viewing pleasure later on - might be Saturday night before I get to it, though. Jan Just two new liveries that Morten made:

Time for another short update - we have actually been really busy this last week, we squashed a bunch of bugs, and also added some detail. There was a total of 37 new revisions to our internal update system. Just today we fixed the yaw damper. Its behaviour is a bit curious, as it will stop working when it looses B hydraulic pressure, but the switch won´t drop to off, and the OFF light won´t go on! If you turn off the B flight-controls, it will revert to off immediately. And if it looses power, it will also go off, but only after a 2 second delay! This is the kind of detail that is keeping us busy these days. We also worked on stabilizing our GUI interface, you can see it at work in the little video I show you below. I am currently scrutinizing the electrical system, we want to make sure that everything is working just as the real thing - and even with a book in my hand its not always easy. The electrical system is quite complex, Boing has it very well thought out, and somehow electricity always gets to where it´s needed . I can´t tell you how often I thought I found a bug, only to find out that some relay opens and reroutes power halfway across the whole diagram. The whole system is a work of art, and we strive to reproduce that as close as possible. The video is about the dreaded TR3 disconnect relay. Few pilots REALLY know the electrical system down to the last detail, its complex and there is really no need. Tom did a great job on getting every relay and diode working right, and with modeling this TR3 disconnect relay he is really polishing it to perfection. The TR3 disconnect relay (also known as R9) is a favourite with instructors, as it packs a mean punch just when you thought you are home safe. If transfer bus 1 fails, not a whole lot will happen. The important DC Bus 1 gets power from the "other side" of the system through the TR3 disconnect relay. But when the autopilot or flight-director captures the glideslope, the relay will open and DC Bus 1 will loose power. And that one has some important users attached to it, like the auto-throttle, anti-skid, anti-ice for engine 1, etc... Stay tuned... Jan

Copy and paste from my mail to you, as it may benefit other users: Hi Chuck, simply select all the items that are in the second entry (from the DSF) (use shift-click first to last one) and drag them up to where the items from the apt.dat are. Now you can just delete the old header from the DSF entry. You should now have a structure on the right that is: world/airport/all items from both apt.dat and .dsf file. The warning you get is when you try to export a wed setting where not all items are within the aiport folder. In this case the DSF stuff you imported sits in its own folder, but not in the airport folder. Does this make sense? When you "export" your file, WED figures out which stuff goes to the apt.dat and which goes to the .dsf.Same for when you upload to the gateway - in this case you MUST select the airport file line, though (you can tell you did it right when ALL objects on the main screen light up with those little crosses). Only then can you upload to the gateway (and you must select the "export target" correctly. first). Let me know if this works, Jan

Hi everyone, Work continues - as a matter of fact development speed has increased again over the last few days. There is really nothing big to reveal, on one end we are adressing the roughly 30 issues and remaining items we have, on the other hand we are fighting the uphill battle with the FMS routing structure. Before release there is also the documentation to be done - most of the content is there, it just needs streamlining and editing. Just last night we have improved the APU operation. We now have a moving air-inlet door, the FADEC will wait until the door is open before it engages the starter, and the APU can also be shut down with the firehandle or by switching off the battery bus - in that case the APU inlet door will stay open, though. A funny thing happened when testing the new behaviour - with repeated APU starts and insufficient time for battery recharge in-between, two of us have accidentially depleted the airplane battery. We initially thought we found a bug, as you couldn´t even connect the ground power anymore! But it turns out the behaviour of our simulation is correct, because without sufficient battery voltage you can not even close the relays to connect electrical ground power. This does happen in the real aircraft, too - if a pilot, eager to get to the hotel, forgets to properly shut down the aircraft in the evening (battery switch off), the next crew in the morning might find a dead battery. The only way to get the aircraft going in that case is to connect a DC source to the external DC connector. . We also worked on improving the GUI - up to now we had to go through the plugins menu to access preference or setup menus, now we have a state-of-the art sidebar that you can get to by bumping your mouse on the left edge of the screen. Some menus (ground and cabin-crew interaction) can also be triggered by following real procedures (selecting the correct interphone channel, enabling receive volume, toggling interphone or radio push-to-talk switch), but if you don´t feel like that, just use the nifty sidebar-menu. Our menu interface will be fairly spartanic, for example the "preflight" one will allow you to pick three states (cold and dark, turnaround, ready to fly), and specify zero-fuel-weight + CG and fuel distribution. We decided against some more elaborate "seat plan" where you can click on every single seat to place/remove a passenger. It would take too much time to make, novelty of it would wear off after using it once or twice, and really in the end all the real pilot cares about is the weight and the center of gravity. There will also be no "real time" boarding and deboarding of passengers, this is something that is very hard to get believable without actual 3D people moving onto the aircraft, which to my knowledge hasn´t been done totally believable on any flight-simulation to date. We do realistic fueling times (if the user chooses so), but weight adjustments (loading/unloading) is instantaneous. If you want to roleplay, use a stopwatch and a figure of roughly 5 passengers( = 500kg or 1100 lbs) per minute . With development speeding up again, I expect to start posting some more content and dev-blog type info more regularly. Jan

1.)The CTRL-numpad thingy works just fine - the view-changing window is acutally a remnant from times when XP did not have this feature yet. We will probably keep it, because some users might like it (i.e. not having to go through setting up views and remembering which key is which). Fwiw, you can also adjust and save those views in the view-window. 2.) The sound you are hearing is a combination of aircondition airflow, avionics vent blower, standby-altimeter vibrator and engines running on low idle. Jan Edit: Ben beat me on 1.) ;-)

Of course you can always request liveries. We won´t promise anything, but Morten is putting out some really great ones, and I think he is grateful for some suggestions. Jan

Peter, I agree with you. Everyone enjoys different parts of a simulation like X-Plane, aviation is a huge area and there are many different things to do. Thats why many add-ons are out there, catering to different tastes and likes. I personally would never think of getting an add-on that changes the colour of the sky or the cloudshape - I simply don´t care - I place my emphasis on different things. We make an aircraft that caters to the more serious and realistic airliner experience. I still believe that one can enjoy our product in many different ways. Heck, you could even just look at it from the outside in chase view and still enjoy it. Is that worth the price of admission? Everyone has to decide for himself. There are many features in our model (and the real airplane) that our users (and the real pilots) will most likely never ever see in operation or use. Examples: LGTU, PTU, Stby Hyd System, Alternate flap system, etc. I have flown the real one for ten years, and never needed any of those once. Why do we put those in our model? Because the real one has them. We will provide a complete model with as many realistic features as technically possible. We will not finish it at 95%, just because we get tired or because of user demand. We understand that waiting for it is hard, but the history of software is full of examples where developers have caved in to the din of "release it, already, we don´t care what state it is in!!", only to find out that indeed the user does care about the state it is in ;-) It will be worth the wait! Jan