The B737 Classic Project

[tkyler]

I was cleaning up a few files on my computer and came across this older pic of the cockpit with some more 3D in it than we've shown before...but untextured. I just like it for some reason. It's not the most current though

We're still working on the FMS, we had a bit of a slow down with the transition into the fall and general family thing for each of us to deal with but we are still moving forward. Here is another development snapshot of the LNAV testing. As you can see, so far so good on LNAV tracking. The waypoint locations shown on the EHSI are inconsequential in this screenshot, they are not part of the final code obviously...this was just a route draw / AP track test.

Tom Kyler

Laminar / IXEG

Edited October 10, 2012 by tkyler

[MTR1994]

1 month - 2 screens... great...

Edited October 10, 2012 by MTR1994

[Airbus]

I hope you guys can simulate this

http://youtu.be/Te7031hMjds

[den_rain]

We're still working on the FMS, we had a bit of a slow down with the transition into the fall and general family thing for each of us to deal with but we are still moving forward. Here is another development snapshot of the LNAV testing. As you can see, so far so good on LNAV tracking. The waypoint locations shown on the EHSI are inconsequential in this screenshot, they are not part of the final code obviously...this was just a route draw / AP track test.

Tom Kyler

Laminar / IXEG

Good! We wait for you!

[Litjan]

I hope you guys can simulate this

http://youtu.be/Te7031hMjds

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

[Dozer]

It's masterful work. Have you encountered any problems from X-Plane's magnetic-declination model? I've heard reports it is outdated, and as VORs are aligned to magnetic North, if X-Plane's idea of magnetic North is wrong, the VORs will be misaligned.

This is not a problem which should be in the scope of the IXEG 737, but given the amount of work you're putting into the navigation systems, you're more likely to be affected by this than anyone else.

A solution I began a while ago: rewrite decades-old public domain code which implements the IGRF and WMM magnetic declination models into a modern C++ class which can be used by a plugin to give good declination values for anywhere at any date between 1900 and 2015 (and able to be extended when new magnetic data is released). Then reimplement radio navaids from scratch. So far I have half an ADF system and some spherical-harmonic functions I don't understand but have weaned off of global variables.

Edited October 11, 2012 by Dozer

[Nils]

Indeed we have. One challenge is when we predict initial climb out waypoints on "runway heading" and try to make those align reasonably well with Austin's runways headings which are incorrect/out of date. But as you point out, there's only so much we can address within the 737 project.

[Litjan]

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

[Dozer]

Is it too late to switch to modelling a 737-200 and omit the FMS?

It sounds fantastic Jan! Really looking forward to it!

Sorry if this has been said before - are you going to have system failures and systems degradation? (ie a generator that's still working, but only at 60% of its intended capacity.) Beyond X-Plane's default failures, of course. If occasionally the 737 will decide it's going to fail the 2nd transfer bus, I must remember to switch the position lights to 'BAT', or deliberately choose to fly without position lights to save battery.

If the 737 will automatically fail its systems, can this information be logged somewhere? "2012-11-05 03:31 Elec Transfer Bus 2 total failure (automatic random failure)"

Can the 737 be set to load into a 'not-perfect' configuration, where there will be a constellation of failed/degraded minor systems but the aircraft still fit for dispatch? And presenting a defect sheet for the incoming pilot (the user who's just loaded the plane) to review?

If not - no worries - if you're presenting all failures and abnormal conditions as datarefs, functionality like this can be added by 3rd party plugins (hello!) post-release.

[Litjan]

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

[Dozer]

Thanks for the explanation Jan. It's good to know airliners aren't like the buses I used to drive! Some of them could only climb hills at 40kph.

[79carboy]

Are we going to get any outside shots of exterior soon?

[xp10fan08]

eta on release! that is the most important piece of info, you can have all the juicy details and images but with no end in sight to me makes it not worth it

[Morten]

eta on release! that is the most important piece of info, you can have all the juicy details and images but with no end in sight to me makes it not worth it

The end is in sight, but we don't know exactly when. When we do we'll let you know!

Anyway, there is LIGHT in the tunnel

M

[GrahamH]

eta on release! that is the most important piece of info, you can have all the juicy details and images but with no end in sight to me makes it not worth it

You must be new to x-plane. Devs that make this complicated, detailed, beautiful of a plane can never give a release date. It just doesn't happen. Sometimes you'll find a developer who has given a release date prematurely, but it always comes back to bite them. No end in sight doesn't make it not worth it, but all the more exciting. In my opinion, looking forward to a plane is almost as exciting as flying it.

Edited November 14, 2012 by GrahamH

[Benedikt S.]

The end is in sight, but we don't know exactly when. When we do we'll let you know!

Anyway, there is LIGHT in the tunnel

M

Yeah Lufthansa... Looks nice

[meshboy]

Gggrrreeat shots and lightning.

Cant you add some photos/videos on the ixeg.net?

Its easier to have all photos in one place.

How about a nav-video or fms-video?

It doesent need to be perfect its just so intresting videos jan is making. The enginestart video i probable seen 500 times!

[Morten]

We'll start putting exterior shots on the site as soon as all the 3D details are in place.

[Litjan]

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

Edited November 30, 2012 by Litjan

[Dozer]

You're posting this message in different places, so I am going to reply in different places too

I could see this developing to use a Role-Playing Game engine underneath:

User casts APU Start, 14 needed for success

10kJ consumed from battery

*roll d20*

Base roll: 13

Modifiers: +2 Pilot Luck; -4 Altitude; +1 APU Condition = -1

Modified roll: 12

User action fails (13 - 1 < 14).

I'm kidding. But if there is an underlying element of luck (good and bad luck) when it comes to questions like "will the APU start first time at x altitude" it makes the choices you describe more interesting. It's about playing the probabilities instead of boolean logic. I expect someone will tell me that pilots never need to gamble in reality, but in extremely abnormal cases (for example, double generator failure) is this still the case?

[tkyler]

You're posting this message in different places, so I am going to reply in different places too

yea, well at least I can reply here Jack.

Thus far we have not implemented any type of failures or chance / random scenario control. We DO have hooks for that though, the system was very much designed to be open ended and accessible at many levels. For example, we have relays that control the electrical system switching...and our relay data structure has a "isfailed" property so we can fail any relay. We also have 'isfailed' properties for busses, switches and a lot of other stuff....so unlike xplane which just fails a major system, we can fail a component which of course can bring down an entire system. This can result is multi-level "problem solving". One user might simply want to do an engine out situation....another might want a random failure of a really obscure component and then have to sleuth their way to finding it....pushing their knowledge to the limit.

Regarding obscure situations...we really try to hold fast to physics as much as possible. The aircraft is a machine after all and works in a very well documented environment. For a scenario like the APU start in flight, we would probably do some research on operating limits and only allow the APU to start in the "comfortable part" of those limits. In the transition areas of the limits, we might put a sliding randomization factor that makes it anybody's guess, including our own. In such a case, your knowledge of the limits of the APU would play a part in making darn sure you make the best decision.

Tom K

[ptru]

...and our relay data structure has a "isfailed" property so we can fail any relay. We also have 'isfailed' properties for busses, switches and a lot of other stuff....

That sounds excellent. Really like your approach guys

Edited December 1, 2012 by ptru

[Dozer]

yea, well at least I can reply here Jack.

That's something I hadn't considered Tom!

 

So you have these failure flags, but not hooked to anything yet, right? That is the situation I expected - I've been told before that failure simulation will come after v1.0.

 

I have subjective and aesthetic reasons to like the idea of limited randomness. It helps disguise the fact I'm actually sat in front of a big box of numbers linked by hard logic, instead of in something absolutely ruled by fluid dynamics. The huge depth of systems in the i737 disguise this a lot, as Janov said elsewhere - the needles moving gradually, the lights fading dynamically, due to the interplay of systems, and without needing any randomness to fill in the gaps.

 

Meanwhile I use srand() to modify the time it takes to close a generator field into the 2 to 4 second range in my own project. I could try and simulate the generator field relay control system, and include the various factors which might alter the length of time it takes to close the generator (for all I know it's just a timer relay - the Pilot's Notes don't go into THAT much detail) - but srand() is much simpler and gets nearly the same result, which is that the user realises they can't be completely certain how long it will take the generator to close, they'll have to keep holding that switch in until the light goes out.

I could try to make a complete electromagnetic model of the Earth, with coastlines and powerlines and terrain topology and air-mass refraction and thunderstorms all bending radio waves in subtle ways, and end up with a VOR needle on my RMI which is only accurate to +/-2°. Or I could just use a noise generator to get an indistinguishable result in much less time. The important thing is, now my TACAN system has meaning, as it is accurate to +/-0.3°. (I'm making numbers up here, but I think the ratio of precision of VOR and TACAN is similar to those values.)

 

Clearly this is not the same thing as simulating electrical systems, hydraulic systems, the flow of heat and air through the aircraft. These things are internal to the scope of the simulation. They are things which interact with each other, and they need a simulation made from interacting elements. But the stuff on the boundaries of the simulation's scope, the frontier between internal and external - VOR accuracy, generator relay control systems, and exactly how much air pressure/temperature is needed to start an APU - in these areas, controlled randomness I think can be useful.

 

I think I'm starting to split hairs - it's extremely unlikely that anyone will notice or complain if the APU starts 100% of the time at 20,000ft but never at 20,001ft. This is the kind of problem that seems to matter when I'm writing a forum post, but not when I'm sat at a compiler or actually - gasp - flying the sim.

Edited December 1, 2012 by Dozer

[Ben Russell]

what is this "fly" you speak of?

[Dozer]

what is this "fly" you speak of?