Dozer

Yes, I knew about that, I didn't get far with learning that technique (ie making it as fluid and unthinking as just using the hat switch) partly because, on my system and with a first-gen TrackIR, it was a significant amount of hassle to get the TrackIR running each time and the benefits over just using the hat switch, for X-Plane IFR-type flight, just wasn't worth it. Also I had to tie an infra-red LED to my forehead with a lanyard, with a wire running down to a battery pack somewhere nearby - a homemade system to replace the ineffective retroreflective dot. It was cumbersome and confused the heck out of my housemates :-)

I have TrackIR (the first version that's 2DoF only - it lets you turn your head but not move it) but it's a royal pain in the neck trying to click on a switch on an instrument panel while your head is moving the camera at the same time. In real life, I can move my hands completely independently of my head, but desktop gaming technology hasn't really caught up with that yet! so I use a combination of hat switches and PilotView-plugin preset camera positions to navigate the panels. So being able to remove the yokes is a mandatory feature for aircraft like this if I am to use them, rather than panning the camera forwards to peek over the yoke. TrackIR is fantastic in combat sims, especially where there's no need to use the mouse in 3d space because all the commands are mapped to the keyboard. Couldn't do without it in Il-2 Sturmovik!

Purchasing today gets you this update for free in case you weren't aware. Although with the amount of work that's gone into 1.5 I am a bit surprised you haven't made it a paid update! I think you'd be justified doing so - but I also think that my values on spending money on artistry are not 'normal' in the pure statistical sense of the word. I love those flags - details like that are what bring a model to life. (Why does the altimeter depend on avionics power though? I thought it was purely mechanical, driven by air pressure and springs, and only needing electricity for transponder Mode C altitude reporting, lighting, and possibly to drive an agitator to keep the mechanism moving.)

Thanks Tom! It's looking great!

I'm very sorry Ben, I don't know what I was thinking!

Have you actually seen the manuals Ben? Have you actually read this thread and understood the context of my reply, Dozer? Yes and no, evidently.

"New Sunrise livery honors cultures where those colors mean prosperity & good luck"....read China Which is also why it's the -8 rather than the -500 or -600 or any of the other numbers associated with previous attempts to enbiggenate the 747-400. Also why the A380 isn't the A350 or A360, and why the first (and so far only) A380 is the A380-800. 8 is a lucky number in the far east! It's a bit sad if any of the aircraft-buying population of the far east are taken in by such shallow marketing though. Unless it's meant to be a symbol of how much Airbus and Boeing are committed to the far eastern market now.

Have you actually seen the manuals Ben?

You should add Compile list of remaining tasks to that list for completeness! It's looking very good Tom; nice to see the return of the panel behind the autopilot controls atop the glareshield!

My guess? Completion.

You'd better get the card unlocked if you're going to use it to make purchases!

Makes me feel cheerful to look at that Tom!

I have a theory it's possible to add stuff to existing aircraft's 3d cockpits by careful addition to the cockpit.obj file. I haven't tested it yet though. If it is true, then when XYZ System Simulations build a Garmin 150000, they could provide a 3d mesh, textures, cockpit.obj code for it (so you could create a new blank aircraft in Planemaker, add the XYZ Garmin 150000, load the sim and have a 3d cockpit consisting of the Garmin floating in front of you in some reference position). Then XYZ System Simulations, or enterprising MU-2 users, could provide the offsets to position it correctly in the MU-2's cockpit and specify exactly where XYZ's code needs to be inserted in the MU-2's files to make it appear and function in the MU-2. I haven't tested this though! I think it should be possible for users to add instrumentation to aircraft without requiring the extremely valuable time of the aircraft's authors. Is this an objectionable idea though?

Boo - burn the Garmins, bring back the 1980s, give us a Loran if we're well-behaved else let us use radio navaids ;-) As for the v1.1.1 MU-2 altimeter, I've made a replacement here: http://forums.x-plane.org/index.php?app=downloads&showfile=12337 It's not particularly realistic as it uses the default X-Plane LED readout to replace the blurry pressure-settings display - but it is readable!

Looking great Tom!

Sounds great Tom! I remember when I first flew the MU-2 after my X-Plane hiatus, getting annoyed at the roll on takeoff and thinking either I'd mis-set the fuel controls or that the DRM had decided I was a pirate and was subtly messing things up. (The DRM for army game/sim Armed Assault did clever subtle things if it thought you were illegal - it would let the game run, but all the gunsights would be about 15° off so you could never shoot straight, as I found when I tried to run a no-CD .exe file! I left the CD in the drive after that.) Spent some time playing with the v1.1.1 fuel switches - then I read the manual, and defined aileron trim on my joystick In fact I printed the manual! Would it make sense for the MU-2 to instantly move its fuel into a sane configuration on startup to counter X-Plane's 'drunken illiterate refueller guy' implementation of ramp service provision (assuming it can be done without upsetting xeconomy)? Actually, that's probably not the best idea, because the randomisation means we're forced to check 'is the fuel configuration ok' before takeoff, increasing immersion, like the 'is the gear light actually green' check when landing the Falco. And it demonstrates the intricacies of the model you've just built of the MU-2 fuel system!

In the meantime, thanks for providing me with new desktop wallpaper ;-)

I've uploaded stuff where I spent more time on the documentation than on the content! (Mostly the PilotView preset uploads, really). It's looking amazing Tom! It's looking like v1.5 would be suitable for releasing as a new paid-for product rather than an addon! (Although that would probably upset some people...) This is probably a really stupid request - but if you reach a point where you've completed everything but the documentation, would you release v1.5 without new documentation with a strict as-is, no-support basis until the docs are finished? I can't wait to fly this! I have no idea how much work is involved in the 'shipping and handling' of the update, I'm just impatient :-D

Looking very good Tom! I see you've separated the left and right landing light switches - are they animated separately now too??

Looking really good Tom! The first screenshot looks more realistic I think...

Go for it, it's very straightforward (unless you're trying to paint horizontal lines across the nosecone :-D ). I'd make more, but I don't really have the artistic imagination to think of any plausible schemes. How about a BOAC MU-2?

It is uploaded! http://forums.x-plane.org/index.php?app=downloads&showfile=12725 It's an excellent paint kit Tom, really easy to use. I opened the old one to see if it had non-Banditerated reflections I could use and it was a bit of a shock by comparision! (And it didn't, because the texture I needed is in the enpennage file that doesn't open in GIMP.) Must confess - I have done a silly thing - uploaded those files without testing them on my own X-Plane installation. But they're the same as the ones I used in the screenshots, and they looked identical in Blender, so all's ok, right...

Cheers Tom! The enpennage file was OK - until after I'd finished :-/ In all likelihood, it's a bad idea to hit 'file/save', and while it's still saving hit 'file/save a copy'. That's probably what did it. I have a bad habit of making a post, then using 'Modify Post' to reformat it. Preview function doesn't seem to like attachments, at least with this browser. My enpennage file basically consisted of rectangles of solid colour, and text, painted into the appropriate layers. And some messing with the Perspective tool to make the Ensign fit the line of the vert.stab. I'll rebuild it with the new paintkit! Edit: I'll rebuild it with the paintkit you've just uploaded, then post it on the .org.

TO SAVE SANITY, TURN OFF .GIMP PNG-FILE COMPRESSION!! Seriously, once I'd learned that useful fact, everything happened much faster. Before, I'd be watching a little blue bar inch edge across the screen for twenty seconds after every change. (Yep, my PC is old.) Finished! Sort of. It turns out that FINAL_Enpennage.psd (what is it about that file???) is now corrupted and I can't open it again. But I didn't try to open it until after I'd decided I'd completed this scheme anyway. Ended up redoing the nose textures anyway. Much happer with v2: By the way, this is why I don't fly VFR. This is X-Plane with 'clear skies' at midday in July. Can you see how I cheated? I'll upload it to the .org when someone can tell me: should I turn .png compression back on again for the final files? I'm assuming so, because all Tom's paints are about 500kb/file while mine are 8mb uncompressed. Edit: 100 posts! Nice way to commemorate it.

Thanks Tom, but I deliberately chose to make the plugin global because it's NOT MU-2 specific! (It's useless if you don't have the MU-2, but that's not exactly the same thing...) It provides unified commands for the landing light and engine start switches. The commands provided by my plugin will operate either the default X-Plane commands or the MU-2's commands, depending on which aircraft is loaded. That way, I can for example bind Ctrl-1 to dozer/mu2/start_engine_1. If I've got the MU-2 loaded, when I press Ctrl-1, MU2 Command will activate your xscenery/mu2/engine_start_left command exactly as if I'd got Ctrl-1 bound to it. If I've got a different aircraft loaded, Ctrl-1 will activate the ordinary /sim/starters/engine_start_1 or whatsitcalled. This wouldn't work if MU2Command lived in the MU2 directory, because it wouldn't be loaded when I'm using a different aircraft! Code snippet from the dozer/mu2/startengine1 command handler: if (inPhase == xplm_CommandBegin) { if (isMU2) //isMU2 is global bool that is true if a/c identified as MU2 { XPLMCommandBegin(MU2Start1); //MU-2's custom engine start command } else { XPLMCommandBegin(XPStart1); //normal X-Plane engine start command } } MU2 Command as it is today crudely uses the .acf description string to identify whether or not the aircraft that's just loaded is your MU-2. A better method would be to check whether the MU-2's plugin is enabled but I didn't think of that at the time!