MU-2 progress towards update

[tkyler]

Some new liveries too. Some of these are on the org, but I've included in the upcoming update along with the new paint kit.

Edited February 20, 2012 by tkyler

[NLewis]

Looks amazing! Can't Wait

[MaidenFan]

Wow, that's a huge improvement in the number of liveries!

[Dozer]

awesome! let's remind everybody' what's coming.

It's a generation better than v1.1.1 Tom - and I reckon my tired old PC will be happier with it too. I'm looking forward to saying goodbye to nearly all of the 2D panel gauges. 3D instruments look so much better and they're easier to render. That, and the extended systems simulation - it will be great! Can't wait.

[Jezzebell]

Fantastic Tom! Can't wait.

[RojanTrojan]

Update is looking very tantalising fellas.

Rhydian.

[Emalice]

Soooo, tomorrow is Friday, I guess tomorrow is Moo day ? You know what, guys ? The update is very close now. Very very close. Very very very close. Will Tom raise me another "very" ?

E.

[tkyler]

sure..why not. I've added 10 new pages to the docs, rewriting the autopilot section and bringing the docs into conformance with all the system updates....and fixing the typos (I hope). Writing a few notes on hardware setup today and then will get with XA on packaging....which means newsletter, promo screenshots, web page update.... and that will probably eat a few days too. Exact release depends on XA and my schedule. My wife is in Las Vegas and I'm doing double duty managing the household. We'll see how it goes.

TK

[hobofat]

Awesome news! Really looking forward to it. Thanks for putting all the work into this that you have, Tom, even though it may no longer be your main income. It's still the main draw to X-Plane for many of us!

[tkyler]

Thanks hobotfat. I'm sorry the 3D exterior and cabin is a bit behind current tech. I'm even a bit disappointed in the engine model.....but that just goes with the territory of evolution of technology I guess. As long as tech moves, I'll have to keep reworking this thing I guess. I just hope you guys can still enjoy it even with it's warts.

Tom

[jagipson]

Perhaps you can 'fix' the MU2 (so it works reasonably) for XP10, then you could make (and sell) an new MU2 product strictly for XP10. I'd be willing to pay for it again, if that got the kinks worked out and saw a few additional improvements.

[carthorse]

Perhaps you can 'fix' the MU2 (so it works reasonably) for XP10, then you could make (and sell) an new MU2 product strictly for XP10. I'd be willing to pay for it again, if that got the kinks worked out and saw a few additional improvements.

Yeah, Me too. I've been so satisfied with the first version, and I see that the second version is almost a new plane as far as effort goes.

Edited February 25, 2012 by carthorse

[tkyler]

Big day today. Not because I wrote more docs...but because what I WAS writing...some particularly annoying "known issues" and "workarounds" are no longer issues or workarounds. Turns out I tried to fix something in the plugin and broke it pretty bad. In the course of fixing it, I ended up fixing some things that have been bothering me for the better part of a year now....things where I WAS going to have to tell the users how to work around it but don't have to anymore. For the first time since I started this simulation, I feel like it's running where I don't think "that's just not how it is". There are still a few known issues in what I'll call "fringe cases" where you do things that you would never do in the real aircraft....BUT if some intrepid soul got to experimenting, they might come across it. Anyhow...with MANY little quality improvements in the simulation reliability, I can now write the final page or so of the docs explaining the joystick throttle setup. This thing is as good as off to XA for gift wrapping. It'll take a several days or so ( as usual )...but I can honestly say that in my mind, Im' ready to pass it on...including the docs.

Edited February 26, 2012 by tkyler

[Emalice]

Hurray, that's wonderful to hear. I am glad to soon be flying in a greatly improved aircraft, and I am so glad it is one you will be proud to see flying out there.

Thank you so much for all your efforts. Can't wait to try it out. And I promise I will read the manual first, from cover to cover. I always do.

[PWJT8D]

This is excellent to hear, thanks for all of your hard work!

[tkyler]

You are welcome. Here is an excerpt from the manual that covers what's new. Yah yah...I know there's a typo or two.

whats_new_1.5.pdf

Edited February 26, 2012 by tkyler

[carthorse]

Nice documentation. Just read the whole thing. Very exciting!

[Andydigital]

So is only one throttle lever supported? If so the other 5 levers on my quadrant are going to be INOP with this aircraft. Im not sure if I like the method for assigning the throttle either, I can see many support enquiries in your future from people being unable to assign the throttle to the correct axis due to some other axis interfering i.e. a noisy pot.

Edited February 26, 2012 by Andydigital

[tkyler]

So is only one throttle lever supported? If so the other 5 levers on my quadrant are going to be INOP with this aircraft. Im not sure if I like the method for assigning the throttle either

I don't like it any more than you do Andy, but that's all I have for the moment. X-Plane will not allow custom datarefs to be assigned to analog axes. Adding just one extra axes for calibration means I now have to write a custom calibration screen like Austin does and that would delay the release way too long or the procedure would just be too complex. This is the price I pay for pushing the limits of xplane customization for hardware uses...it's an evolutionary step. While you may not see the advances, they are in place in the code base and once I can get a utility written, my works will allow full customization for hardware users. While I can rewrite the plugin to use the standard "throttle_ratio" dataref for the joystick...I cannot do the same for the condition levers as I do not have the same override functionality that I do for the throttles. Without writing my own custom screen, there is no way to get 100% simulation accuracy...especially given the fact that Austin's engine simulation doesn't really take the Garretts into account. I DO very much want to write my own calibration screen and will look into that for the future.

As far as a noisy pot goes, I've already dealt with two hardware setups with that situation and have overcome it in code...at least for these two test machines. If a pot is noiser than I've allowed for, then folks should get another pot. I normalize the joystick input to unity and you have to overcome 65% of axis travel in order to pick up the axis. It's important that the calibration step is done prior to the 'picking up the axis' step because Austin stores the high and low values during this step and that's what I use to normalize the input. So a pot would have to vary by 65% of it's limit. I've tried it on about 4 differing hardware setups. If I have a unique situation, then I'm willing to try to overcome that for that individual. I think that's pretty good service; however, I am sure it won't be 100% but nothing ever is and someone always gets left out and is unhappy. I am sympathetic to these individuals for certain, but I myself have been the odd data point at times and that's just the way it goes. I am a pretty picky individual and the system works pretty good and is very very quick. It's 'livable' for a free upgrade to a 30.00 simulation that is not too bad. Simulation has its limits....all I can say is I'm committed moreso than just about anybody to getting to a level where cockpit builders and folks with complex hardware setups can work with my products and I can still maintain simulation accuracy. X-Plane's setup is still a bit too generic and if you get one thing, you usually give up something in return. I will continue to field enquiries though and make improvements..that's all I can promise. If it's any consolation, I'm building a throttle quadrant for my MU2 that I can't use either until I write the code to support it...so we are most definitely in the same boat.

Best,

Tom

EDIT: Andy, Dozer has come up with a suggestion that I will explore using "unused" datarefs whereby you can assign two of your levers to the condition levers 3 & 4. If this works....and without detents on your hardware though, you will have to be careful about not pulling the condition levers past the taxi position as you'll risk shutting the engines down. I am not going to put a "toggle reverse" command for the condition levers too...bad enough doing it for the throttles. As far as the power levers go....unfortunately, you will still only have the one input to actuate both levers. This was a tactical decision as we rarely used levers independently in the real thing...but the problem stems from the fact that x-plane will not allow per engine prop override. So because x-plane does not simulate prop locks, when you override one prop during a single engine "prop lock" operation, the other prop will get overriden as well. This means you cannot shut down your engines independently of one another without causing prop pitch problems on the restart. Now this only occurs when you shut down and restart the engines in the same sim session though..which is not a typical scenario..but it does exist. I have requested 'per engine' prop override and gotten an OK from Austin, but it's not in the sim as of version 10 yet either. I will say though..that when we shut down the engines, we allways did both at the same time...so what I have simulated is pretty accurate with regards to 'normal procedure"

Edited February 26, 2012 by tkyler

[PWJT8D]

All I know is that I'm just really excited to fly it. I purchased your MU-2 about two weeks ago and I loved it the way it was! I had no complaints and it is a joy to fly. I was ecstatic to read here in this thread that it was being updated to be even more awesome then it already was... something I didn't think was possible.

[Dozer]

I'll go and remove MU-2 Command from the .org, as it's a) nearly redundant now and b ) features a horrendous misunderstanding of how plugins can handle commands.

Thinking of workarounds for plugin input - clearly it's too late now - but I've just checked and I can assign joystick controls to, for instance, Mixture 3 and 4, and get the input by reading the dataref sim/cockpit2/engine/actuators/mixture_ratio[2] and [3]. That could be a possible way to map USB joystick axes to custom condition levers etc.

I'm really looking forward to this Tom!

edit: having read the manual - is there a reason the MU-2 plugin can't republish the normal toggle_reverse and condition lever (F3, F4) commands? For example,

XPLMCommandRef myToggleReverse = NULL;
int myToggleReverseCallback(...);

void XPluginStart (...) {
  myToggleReverse = XPLMCreateCommand ("sim/engines/thrust_reverse_toggle", ""); //note: this is the same as the normal reverse-thrust command
  XPLMRegisterCommandHandler (myToggleReverse, myToggleReverseCallback, 1, (void *) 0);
  // by putting '1' as the third argument here, we make sure our callback function gets called first,
  // before X-Plane can process the command.
  ...
}
void XPluginStop (void) {
  XPLMUnregister...etc
}
...
int myToggleReverseCallback(...)
  doCustomMU2ReverseStuff();
  return 0; //by returning 0, we stop this command from continuing onwards to X-Plane.
}

I've used code like this to intercept the default X-Plane radio tuner commands, to stop the user from being able to rotate the <1MHz tuner across the x.00MHz mark. (The default X-Plane behaviour lets you go straight from xxx.95 to xxx.00 in one click, but the real unit can't rotate a full 360 degrees, so you need to go the long way round through xxx.50.) The plugin introduced the correct behaviour of this instrument without needing any changes to the 3d cockpit because it used the default radio tuner commands.

If there's no reason why this couldn't work for v1.5 MU-2, I'll make a MU-2 Command v1.5 which reassigns the default reverser and prop commands to those three MU-2 commands you'd listed, so the user's existing control assignments will work with the MU-2.

Edited February 26, 2012 by Dozer

[tkyler]

Hey Jack. I've can't say as I've ever tried republishing commands. Notice that those are Version 2.0 SDK features....guess I should stay updated

That does look like it will work. If I can basically steal the default "toggle_reverse" command where I get control rather than x-plane, just using it as a flag (because I can't afford to let x-plane control my prop modes)...then I'm all for that. I certainly don't want to be fighting x-plane for control....but if that works, folks won't have to remap that button in such a case.

SUCCESS on the reverse toggle. Ditto on override "prop up/prop dn" Scratch navigating to custom commands. Thanks Jack.

As far as the condition levers go using indicies 2 and 3 of the mixture...I'll check into that as that'd keep the standard USB HIB guys with multiple levers happy. Definitely not too late....I can compile plugins up till the last second. Thanks for the suggestions Jack... I'll see about sticking it in.

I still need long term solutions in code though to handle various hardware. The whole "toggle reverse" thing is a concession to the practicalities of using a joystick without detents but when I get around to finishing my hardware, I want none of that "toggle reverse" business. This is one reason my plugin decouples from x-plane datarefs and I do not like using the default condition and throttle datarefs as they're too limiting and always require these goofy workaround; however, at least I have the flexibilty to plug into the extra datarefs for this case yet still use the same code base for more complex cases in the future.

Tom

Edited February 26, 2012 by tkyler

[Emalice]

Ha ha, I have no idea what is going on, but It seems to be working out great. An ever better MU2 two minutes before release...

Thanks Tom & Jack !

E.

[Dozer]

It may be possible to use the condition axis 3 and 4 as well, giving 4 repurposable input axis, or the reverse axis - I didn't properly investigate those though. Glad to be of help!

I wonder if the SDK could be extended to allow assignable axis to be created (or repurposed) in the same way as the joystick/keyboard commands. As a stopgap Austin could throw in a bunch of generic axis. Of course the ideal way is to throw the stock FADEC out the window, override the throttles, and do everything in the plugin!

Edited February 27, 2012 by Dozer

[tkyler]

It may be possible to use the condition axis 3 and 4 as well

No go on that one Jack. I got lucky with Austin allowing mixture input on indices higher than the number of engines in PM. For prop/throttles though, any indicie higher than the number of engines seems to be non-functional. I have asked Austin/Ben for custom functionality on joysticks and didn't get too warm a reception for various reasons that I can't recall. The operation is pretty smooth now as it is....good enough to get by till I write my own engine stuff.