Dozer

Once upon a time, I had a brilliant book - 'Alice in Quantumland'. I think I lent it to someone. Very very vague memories of Feynman diagrams from my physics classes in 6th Form about ten years ago now - up/down, charm/strange, left/right 'flavours' of quark wasn't it? Good work getting it ready in time for Christmas Tom! I hope it gets many new users during the long nights of the northern winter.

If a member registers with the name 'downquark', will you annihilate each other?

I would be absolutely amazed if Gizmo doesn't work with 64-bit. It's a very important element to all X-A's products, including the IXEG737.

Fantastic! I'll look forward to seeing screenshots of other people using it while I look for a job so I can pay for a graphics card and possibly an entirely new PC so I can upgrade to XP10! (This is not a criticism. If MU-2 v1.5 was XP9.7 compatible, I'd still need to do all of that. My onboard graphics chip on this PC can't even draw the Falco in v9.7 without mech errors and missing textures.) Congratulations on the imminent release Tom! edit: so will you be updating the banner image in your sig?

You could, if you really like custom thingies on joysticks, and don't mind voiding warranties or solder, combine a joystick with a Teensy board. Use the existing joystick electronics for basic buttons and axis assignments through your OS, and use the Teensy to drive other switches, LEDs, displays etc. I'm planning to have a go at building my own flight controls. I don't want much more than what you get on a real control column: autopilot disconnect, PTT, and perhaps electric trim switches and/or a hat. Probably loosely styled on the De Havilland Comet control column, which is hinged just behind and to the left of your left ankle, then leans across your lap to put a yoke in front of you. A nice long travel between the pitch stops, and provision to have a motorised centering spring, are priorities. I'm tired of desk-mounted spring-loaded tiny joysticks!

Looks amazing. I love the Avanti. Are you building this in XP10; do you expect it will work with 9.70? Glad you're using some plugins. It is possible to do a LOT of things with generic instruments and nested 3d animations, but really the best way for describing system logic is with code (C++ or Lua), if the cost of learning to write the code, and learning to make code work (compiling, SASL/Gizmo clashes etc - quite different from writing!) can be borne. Also if you're using custom datarefs and commands for things, it's much much easier for people to make custom hardware for your aircraft using Teensy boards. If you animate a warning light to be lit when the engine temperature is over 800°C, and then put that animation within another animation which hides the lit texture when the electrical power is unavailable, the hardware builder has to reverse-engineer all this logic by dissecting your cockpit.obj or by making careful observation with DataRefEditor. And then rebuild this logic in the Teensy's code. But if instead your plugin/script creates a dataref for that warning light, a dataref which is 1 when the temperature's over 800 and the power is available and the bulb isn't burned out etc etc etc, and 0 otherwise, you can animate the warning light with a single simple animation. And the hardware builder can link an LED to that dataref very easily and get the exact same behaviour with hardware as seen in the 3d cockpit. It's much better for everyone, unless you really really enjoy writing logic in the language of 3d animations instead of in C++/Lua! For the 3d modelling, instead of using textures for the text, have you considered polytext? Guy M-P wrote an excellent article on why he started using it.

That's the system I just suggested! I haven't used it yet, but I hear it works with the v1.1.1 (current) MU-2. But if it doesn't work with the Falco, it won't work with the updated MU-2, which will be even more Gizmoidian than the Falco. *goes off to see if SASL KLN90B can be ported to C++*

I was about to suggest the freeware KLN 90B, but it uses an incompatible plugin system that won't work with the MU-2

1 - buy a Teensy board 2 - install Arduino and Teensyduino and the TeensyControls plugin 3 - plug the Teensy in and open the Arduino IDE 4 - enter this code: FlightSimFloat brakes; void setup() { brakes = XPlaneRef("sim/cockpit2/controls/parking_brake_ratio"); pinMode(LED_BUILTIN, OUTPUT); } void loop() { FlightSim.update(); digitalWrite(LED_BUILTIN, (brakes > 0.0)); } 5 - set Arduino IDE to 'Flight Sim Controls' and upload this code onto the Teensy 6 - launch X-Plane and admire the little orange light that comes on whenever your brakes aren't completely off.

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.

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.

And what sweet relief it will be to link Teensy LEDs to those datarefs. I've spent a disproportionate amount of time showing people how to build their own annunciator simulation on a Teensy board, because the default X-Plane annunciators aren't so useful. I ended up writing a class which links LEDs to datarefs very elegantly, which also includes an optional master warning system and some other features. It didn't bypass X-Plane, it bypassed the entire computer! I didn't go as far as to model bulb failures. It's hard enough getting real hardware to work properly... Simulation should rightly be done by the aircraft's plugin/scripts. It's very daft to do anything more involved than interfacing in the hardware! Hopefully by the time v1.5 is released Paul will have added a couple of missing features to Teensyduino and I can use the MU-2 to demonstrate how to handle custom datarefs. I love the idea of unreliable switches. In Lua/Gizmo can you create classes for repeated elements like that? And join them in a linked list or some other convenient container, so the 'sim experience director' model can automatically step through the list and find an element to fail, regardless of the scale of the code? I know next to nothing about languages which aren't C/C++. Writing classes is almost as much fun as using them to build stuff. 'Signal-light ATC communications' is also on the long, long list of things I'd really like to model in X-Plane. Ever since seeing "Flashing green light: clear for takeoff (not applicable for ground vehicles)" in the British Gliding Association rulebook.

I didn't even get that far, because in rural Tasmania the internet connection involves shouting into a tin can on the end of a piece of string and it dropped the download twice in quick succession. I'll wait until next month's 'high-speed' internet ration gets activated to download it, and avoid asking Cameron to reset my downloads counter again. I'm quite fond of this Duchess!

Oh yes, the Falco definitely has a GPS power switch (also a circuit breaker), no problem there. I love that feature. I'm not asking for a good Garmin. I'm just asking for the option of no bad Garmin in future projects. That's my gripe with the Planemaker instruments - my strong preference is that an instrument be missing than implemented as a default-textured instrument. I'd find the absence less jarring! I'm probably coming across as a bit obsessive. I think that's because I'm a bit obsessed! I don't post critical comments on most of the aircraft I've purchased, and that's because - maybe it's unkind of me to say this - because most of the aircraft I've purchased didn't really hold my interest for long. They were far enough from 'my kind of sim aircraft' I didn't speak about how they could be made better because there was no point, I had no realistic hope they could be made into something I'd like to fly routinely. I have a much deeper affection for the Falco and MU-2 though, which is why the minor blemishes aggravate me so. Thanks for the explanation Tom, although I had no right to expect one! I appreciate how open you are about the development process. @Cameron yes, I don't actually fly like that. The difference is more obvious as a marked difference in texture brightness but it's harder to get that across in a small screenshot, especially on a machine without a graphics card. And yes, let's get back to the v1.5 MU-2!

I must be one of your more demanding customers Cameron! (edit: how come I'm not seeing the ALT SET window on the bottom of my panel?) Bear in mind this is the ONLY negative I have about the Falco. In every other way it is unsurpassed.

Looks fantastic Tom! One plea, even if I can't use this myself: model the GPS power switch, or circuit breaker. Its stock 2d panel ugliness looks out of place here. Ideally release a version with a KNS-80 in its place - a friend of mine has a simulation of one which might be used by the MU-2 if asked nicely. I noticed something yesterday I hadn't noticed for years. The little rectangular gauges on the bottom of the Falco's panel (fuel, oil pressure, volts etc) have 3d animated needles! I thought they were stock Planemaker gauges, because you seem to have used Planemaker gauges for the background. Dear Tom, why??? Please promise me you'll never use stock Planemaker gauges in your panels anymore, except for the GPS screen, which will have a functioning power switch at least and ideally a non-GPS panel option! Big T, I can strongly recommend the Falco. It's still a beautiful cockpit, and the systems modelling is fantastic. It's got nice features like what must be a fully-modelled Garmin GTX327 transponder (full of different timers, altitude monitors, information readouts as well as just being a transponder). I've had a lot of fun with it on short IFR flights. The only negative is that there's a couple of Planemaker gauges on the panel which really look out of place. I did manage to remove them on my old PC but I forget exactly how.

That's great news about the systems coding - I'd love to see more stuff in the spirit of the Falco's undercarriage circuit breaker! I mitigated the C++ compile/reload delay by writing the AircraftSwitcher plugin, where you can assign X-Plane commands for loading specific aircraft. I set up Shift-1 to 'testing aircraft 1' and Shift-2 to 'testing aircraft 2', using two copies of the default King Air as testing platforms as they load fast and usually DataRefEditor for speedy input/output. Compile plugin, install in aircraft 1, press shift-1 to load and test, compile changes, load into aircraft 2, press shift-2 to load and test... it is very fast! (Source code is on github here, and a Windows-compiled version is on the .org file library. It uses PPL. Look at the source code! It's just 82 lines, and that includes code to read the selected aircraft path from the .ini file during runtime!) I'm a bit disappointed about the v10-only news, as I'm still on v9. I have two PCs, one that's just been retired by the local council and another that's stuck in England. The first has a low-form-factor case and no graphics card - it can load the v1.1.1 Mu-2 with unreadable cockpit textures and 19fps framerates, so it's only really useful for testing Teensy code and plugin-writing. The English PC can just about cope with the 3d cockpit if nothing exciting is going on. It's also unupgradable (AGP graphics card). It remains to be seen if I can source an affordable, low-form-factor graphics card for the ex-council PC which would allow me to run XP10, but I'm likely to be XP9-only for a while yet. I'd like to think that if you're replacing large swathes of XP10 with your own code, you'd be in a situation where you could port the code to XP9 and replace large swathes of XP9 to give the same results and for minimal effort. But I'm probably naive of the complexities of exactly what you're replacing and exactly how you stitch your work into the rest of the sim. Don't be so hasty to judge the compass system stable - I've almost completed writing a C++ object-oriented reimplementation of the GeoMag 7.0 magnetic declination modelling software, which I will then put into a HistoricWorld plugin and also submit to Austin for use within X-Plane. Soon it will be possible to have reasonably accurate magnetic declination for any location on Earth for any date since 1900, and it will be possible to fly over historic (rather than current) scenery using historic charts and navaids. Anyway, one way or another there will be updates to the compass system...

Of course, I'd forgotten you were porting everything to Gizmo at the same time!

Definitely not knocking Australia! I have the privilege of dual citizenship in the UK/EU and Australia. I was between jobs, short-term rolling tenancy in the UK, visiting my family down here, and became persuaded that life would be more productive down here. So I simply didn't go to the airport on the day my return flight was booked. I'm afraid I don't have a clue how the camera limits work. I should have read your question more thoroughly! Where did I draw this name from? I think it was the pilot/helmsman of the hovercraft Nebuchadnezzar in the first Matrix film. And my tendency to be asleep at inappropriate times. On that note, it's 3am. I'd better go to bed.

Actually, right now, I'm not using v9 or v10, I'm using vF, where the F stands for 'forum'. My X-Plane PC is in England while I have moved to Australia, and I don't have the cash right now to ship it out - this is what happens when you move continents almost on a whim. The lower part of the control panel (everything that's under the line of eight preset buttons) is only for setting limits on the camera position. It's for setting a box which the camera will stay inside. X1 is the left limit, X2 is the right limit, Y1,Y2,Z1,Z2 are the upper, lower, forward and backwards limits (not sure which order). Were you trying to set limits, or create camera preset positions? Were you trying to set view presets? There are eight view preset buttons in a row, a button and a checkbox, just above the X1/X2/etc bit. To set a preset, basically, you click on the button of the preset you want to assign (make sure the checkbox is checked too), then move the camera to the position you want and press 'save'. That's the save button in the middle of the screen - the one at the bottom is for saving the limits, I think. With older versions of PilotView you had to move the camera with the buttons on this Control Panel screen, not the normal X-Plane view commands, but I think newer versions might let you use either. There's a video I made a year ago where I mumble incoherently, but it might be helpful: It's with a slightly older version of PilotView, and X-Plane 9, but it is probably still valid for PV 1.61 and XP10.

Looks great! Hope it goes well.

Thanks for the answer Cameron. I love the way Tom codes aircraft - the way the undercarriage actuator can blow its circuit breaker if you pull too many g in the Falco is one of my favourite X-Plane aircraft features of all time. I'm certainly aware of the complexity of the MU-2 plugin. I'm glad that new users are enjoying the v1.1.1 MU-2. My comments were possibly too harsh. I've been spoiled by screenshots and private betas of aircraft not yet completed! I hope to work as part of a development team in the not-too-distant future as well, as a plugin developer. I have an idea of building a preliminary plugin, which provides datarefs and commands for all the functions that will not be handled by the core sim, for use by the other developers. Initially all the custom datarefs and commands would be either mapped directly to a core dataref (the sim ADF needle instead of my own ADF simulation for example), or to an 'empty' simulation which records switch positions, and perhaps will turn status indicators on and off, but does nothing more. Hopefully it will be possible to build a modular simulation (modular at the source code level, producing a single compiled plugin, probably) which would allow features to be introduced incrementally and keeping the project as a whole never very far away from a usable release. But to do this I'll need to close this tab, start googling for international shippers, find someone to lend me money, and get my PC and all my stuff shipped out here from England first though. I can't even run X-Plane right now!

The problem is, we DO have it now. We have v1.1.1 now. We've had v1.1.1 for three years, while many radical improvements sit idle on a hard drive in Texas. For three years, the stock EFIS instruments have looked more and more dated, and the beautiful new 3D panel which looked so extraordinary in the screenshots two years ago becomes matched and even surpassed by the MU-2's competitors. The MU-2 v1.1.1 was stunning, in 2009 - that's the review which made me an X-Plane user and a MU-2 customer. It was completely cutting-edge in the XP8/XP9 changeover era. But now it's 2012, and why would I stare at those blurry 2d instruments when I could be flying the Duchess, or the Falco, or the DC-3, or the CRJ, or the T-28? There's a concept in software development: "Release early, release often". Streamline the process of shipping updates to your users so they can gain the benefits of your new features as soon as they are completed and pass testing. Completed features which are not yet available for your customers are wasted, as Joel Spolsky recently argued. Cameron, please have a look at that article, I think it is relevant to you. Is there any reason the work done for the MU-2 since v1.1.1 couldn't have been parcelled up into smaller, incremental updates? Perhaps the X-Aviation product update process is fuelled by unicorn tears? If that's the reason, the update process really needs to be optimised! Manually updating an aircraft frequently would be a bother for users. But for two very important groups it wouldn't be an issue. The first group is the new customers. Do you realise the MU-2's been at the top of the bestseller's list at X-Aviation for three years? That's a great achievement, but all those newcomers to X-Plane in that period have seen the 2009-era panel and perhaps believed that that's still the state-of-the-art for X-Plane. They could have seen that 3D cockpit instead. If I was a newcomer and I bought v1.1.1 today, frankly I would be disappointed. The second group are the enthusiasts who passionately enjoy the product and will be glad to spend effort to have the most advanced version possible. There's the group which has become invested in a particular version, for example hardware builders who will need to reconfigure everything to new datarefs and commands, and modders who will need to reapply all their mods to the new version. Frankly, I think they can cope! There is merit to delaying a release until it has a complete set of features, instead of releasing two versions one after the other. Holding off for three years, though, is a bit far. I've focussed on the visual appearance of the instrument panel, rather than the flight model and systems model, because that's the differences are most obvious, and where v1.1.1 is most limited. I even made a replacement altimeter because the original (a stock Planemaker gauge) was unusable. But I really appreciate deep systems simulation too. An aircraft needs both to be compelling - a beautifully-modelled panel, and interesting systems like the NTS to keep on top of. Without the systems the flying is boring. Without the good instruments the flying is not rewarding. At this point, it is probably best to keep to the current plan and release v1.5 as one big bang as soon as everything can be completed. It would probably be a wasted effort to put everything currently available into a v9.70-only release when so many customers are v10 now. But, please, for future projects, Release Early, Release Often! I hope it goes without saying, I have massive respect and gratitude to Tom Kyler, Cameron, and X-Aviation for the MU-2 and their other contributions to desktop flight simming. I say all this because I wish I could have been enjoying the MU-2 more over the last two or three years. It's a lovely model, and a perfect FS aircraft. The right level of performance and systems complexity to be a really rewarding aircraft to master. Smaller aircraft are undemanding and larger aircraft are overwhelming unless simplified.

PilotView drops a file into the aircraft directory, IIRC named 'pilotview.dat', which contains the settings. If you back it up somewhere before making an update you can restore your settings without hassle if the X-Plane updater deletes it for some reason.

I managed to get a Logitech C160 webcam for $7 yesterday. I'm going to find some IR LEDs and use Freetrack to have a 6DoF headtracker. If it works, there's some friends of mine who'll need two as well!