Leaderboard

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

This little Beaute is from T50's link. For freeware she's quite spectacular inside & out--but you have to follow all the rules to fly her even 20 mile and land her!!!!!! If anyone tries or has tried her let me know Please Cheers

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

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.

I almost have the same birthday as you, xenonkatze!

I still need to get my teensyduino going. I'll be pinging you on that one day Jack. Not in that exact paradigm. Lua uses tables for data storage...tables that have both index and hash components. They are highly adaptable to many physical paradigms. Tables can hold both data and functions and so can mimic classes but there are also other ways of approaching object oriented code. The Lua table library manages the tables in lots of convenient ways for you, including iterating in numerous ways and automatically growing/shrinking it for you along with "garbage collection"...so think of it as a ready-made linked list for you and you don't have to roll your own list algorithms for most tasks. It's made me 10x more productive on simulating systems...the entire 737 classic is written in Lua and to a very high level of fidelity, probably 30,000 lines + with nare a performance hit. Ben told me I'd get hooked and he was right. If the goal is accomplishing a simulation (as opposed to exercising ones brains in the joys of programming and learning C++ for other reasons), then I have definitely found my comfort zone. I can focus more on the algorithms and not get bogged down by code structure. It works great for me. Tom

Yes, but with a 3D pit.