tkyler

A favor....to help me understand user cases better. I was laboring under the assumption that if a user had "dual levers" intended for a common function (power or prop), then they would logically map those levers to "1 and 2" (throttle or prop). So if you have multiple prop levers as mentioned in the previous post, then why would you not map those to 1 and 2 to begin with?....i.e what would you map the 'left' and 'right' ones to in another circumstance? -TomK

apparently I am the one going crazy. My sincerest apologies.....NO clue what I was thinking (or not...probably about pizza). So noted and on my list to look at. Again, really sorry. -Tom

There is no cabin rate of climb indication. The gauge on the left is "the altitude you want the cabin to be at"....so it won't change (sort off...more below). you set this 'desired cabin altitude to hold' with the cabin alt knob. The gauge on the right shows the actual cabin altitude...it should climb as you climb (well...depending on where you set the cabin alt) In your screenshot the cabin alt should climb to approx 3000', where you have the cabin altitude set..that's where your pressurization will begin and the DIFF PRESS PSI needle will begin to move. The tiny window on the bottom of the gauge at left tells you "We can hold 3000' cabin altitude until 19000' and after that, we'll be at max pressure differential and if you continue to climb over 19,000', then the cabin altitude will too...because we can't pressurize anymore...or we'll blow up the airplane like a popped balloon! How FAST the cabin altitude climbs is determined by the RATE knob on the unit on the left. full left is approx 50' minute, so with that low setting the cabin altitude will generally climb more slowly than your real climb (unless you're climbing at 50' minute)...and full right is ~ 2000 fpm or the rate your climbing if below that of course. Several folks have caught this...Its on my list! Excellent! I'll keep at it! -TomK

looks like your axes are reversed in the first video. Any luck reversing your axes in the hardware setup? Last video looks like some potentially funny hardware mappings. post screenshots of your hardware response curves maybe? Also...just to rule out any thing supernatural. If you disconnect your hardware and go "old school" with mouse and keyboard, can you control the levers with the mouse and get engine response as expected?

I've been corrected somewhat on the whole ARM librain thing; however, I do recall looking into this earlier and there being some kind of issue that caused me to cease for some reason I can't recall now... I may look into this again, but because the effect will be default in XP12, and in my long experience in X-Plane....new versions tend to leave old in the dust relatively quick, I can't say exactly when I might look at this again for V11. Its in the back of my mind just the same.

Don't forget to set the "detent ratio" value to match your physical dent on your hardware. I use that response curve window and then pull back my levers to the physical detent and then the number on the vertical axis...go put that into the "dentent ratio" field in the MU2 prefs. That setting gets your animation in sim to match your physical hardware for the ALPHA/BETA regions

Put on the short list Marco. Thx.

You're first description, of not being able to control the engine at all with the power lever....I have seen an unexplainable glitch only one time that suggested a corrupted joystick settings file and only happened on the 5B_GNS variant, because no other variant exhibited the issue, which simply made no sense...so its not a bug I care to see again and so want to be very sure I understand exactly what you're seeing. Your other descriptions of spinning and looping RPMs, I have not seen at all and completely unsure of what you're seeing on your end. Perhaps a screen recording if possible? Also, what kind of hardware are you using? Single paddle no dentent/detent etc?

Thanks so much for the input: Altimeter does goes backwards from 99999; HOWEVER (and I forget to implement this...so thx)...it has a NEG flag on the first 3 digits. Clock will get replaced for sure. its subject to sit below higher priority items, but I don't like it either, which means I'm certainly going to fix it (GTX330 graphics too). Engine RPM....I'll check all the "numbers", both physical and FMOD, which of course drives the sound. It could be the values of FMOD are off a few decimal places. TBM900 throttle is excellent no doubt, but unsure if I can implement just yet, I'm looking into a solution with my current methodology. TBM900 completely overrides X-Plane controls/engine giving ultimate flexiblity between hardware and controls where I do not yet. I still rely on X-Plane's TPE-331 implementation for 60% of the functionality and that means fighting X-plane's default throttle joystick behavior. I do want this behavior in though (and indeed my own engine model) and will be giving it a good look see very soon to assess the options; however, it won't go in before the GTN, that's for sure. GUI: There is absolutely an advanced GUI plan with all sorts of goodies desired.... I just got into imGUI, this is my first go-round and once all the other particulars of the plane operation are stable, then I'll definitely turn my focus to "interaction". LibRadio. Not doubt if I can get it running on my architecture. Bug Saso for sure Final words..I've never been the GUI graphics guy in my other partnerships, always the flight model / 3D / systems guy, BUT I'm just starting to poke around with GUI interfaces....and you can be sure that the better I get, the more toys I'll start throwing in. I still have quite a few ideas I want to get into this product....and this Version 2.0 is the baseline! -TomK

If the beta light comes on, then you're in BETA....how FAR into BETA you are is unknown so far. That depends on your response curve mapping. In the sample below for example, my joystick is set so that it goes into BETA at about 25% of the joystick lever travel...and then as I pull further back below oh...about 0.12 it looks like, it goes into reverse. Note I do not use the "toggle_beta/reverse paddle" method in this example. When you have a response curve set up like this, then you will need to set your "Power lever detent ratio" to match the value on the vertical axis (about 0.34 shown below) so that quadrant animation stays in sync with your hardware lever. What hardware are you using BTW? and with detent? As far as the "two handed move" in the video, he's simply setting the "friction lock" for the condition levers. Pilots will loosen the friction lock, move the condition levers and then retighten the friction lock right after.

Man....I fooled everybody on version 1.x so I wouldn't have to model that complex front gear door!

Gonzalo, please try another variant and see if the problem persists. Was this the 5B_GNS variant by chance?

Thank you for the video, very helpful. This is poor writing and a poorly organized/labled GUI window on my part. I labled the GUI window 'preferences' where not every checkbox gets "preference" status....that is not every checkbox value is saved between runs of X-Plane. For cold and dark starts, I always set the pitot covers, chocks, intake covers, yoke lock in place no matter the checkbox settings (which is why they're grouped together), whereas the other checkboxes in the section below are really the "preferences". The first checkboxes are probably better described as "actions". This was a quick, late decision and easily changed. I am a bit on the fence on this one because some folks like those entites "automatically in place" every time when starting cold and dark and others want pure persistence between their sessions with the MU2. My final thoughts on the matter is that I want to give everybody flexibility in their "start state" and I will probably evolve the system to be a bit more comprehensive and flexible. There are a lot of preferences to think through and provide solutions for. For now though...and I apologize, consider the first five checkboxes "actions" and the rest of the GUI dialog "saved preferences". I'll come up with something a bit smoother soon. Thx!

OK....shame on me for not thinking this one through. Each of those switches (left/right) don't do anything by themselves of course...so the only reason I included the command/animation was so that users could move them individually when inevitably poking around the cockpit, since I want to make all the controls actuable. But I didn't bother to think folks might actually have hardware that have two trim switches and need to move them both. Guess I need deeper pockets for fancier hardware.....wife is gonna love that! I'll defintely make a pass at mapping the trim functionality to the broader range of trim commands by XP and also my custom ones above.

danke, fixed for update!

DOH...too many variants! Thx daemotron! "On the list" though if any are so bold, a little photoshop work on ....VAR_Cockpits_ALB.png.... (paint/clone over the text on the G600 panel variant towards the lower left of the texture) should fix it. XA installer update will overwrite the file of course, but it'll be fixed on the next update anyhow. Fix at your own risk until patch -Tom

I did look into this; however, I have a Apple Mac M1 with ARM architecture and librain isn't built for this processor and I'm not equipped to do so unfortunately. X-Plane 12 will include the effect by default so most folks are looking towards V12 as the future of this kind of thing......though I know this doesn't help on V11, sorry. I don't have plans to integrate it into V11 unless librain magically falls into my lap, compiled for my processor.

would that preference include being able to set the flaps in any position between the limits of your axis? Because that I probably would not do because of the flap pulsing between 5-20 degrees. If however, you're looking for "tolerance zones" in your axis travel that can be mapped to the 4 discrete positions...and that you feel you could "hit by feel" since you don't have detents...that may be doable.

We have to clarify terms Dave. Have you read the docs on Engine and Prop Operation? Unsure what you mean by 'minimum power', i.e. "where are the levers"? There's really no such thing as "reverse" on the TPE-331 per se. Its only "alpha" and "beta" Reverse is just "beta mode with negative thrust due to the prop angle set via the power levers" I present to you this video. Note how fast he's taxiing and his power levers are at the very edge of reverse pitch and still the thing moves quick. When he moves the prop levers forward to increase RPM...he actually applies a bit more beta/revese input to keep from accelerating more...since BETA is essentially a 'fixed-pitch prop' condition and increasing the RPM in BETA will increase thrust. So to answer your question, the setting you can tinker with to get less thrust is the power levers Bring those suckers back into reverse and slow that guy down because putting them at ground idle..(which his levers are below in the video)...can really get you moving! Now for those using a single paddle joystick with no detent and toggling between beta/alpha where you move the joystick paddle forward to get the animated lever to move backwards....its actually normal to taxi in this condition, i.e. move your joystick throttle forward to slow down (animated lever moves back) and vice versa, etc. the

So the mouse wheel is set to change the trim by ".03" units per mouse wheel event...so it should take roughly 67 mouse wheel events....but it gets trickier;...the "number of events" per mouse wheel 'click' is generally set via your scrollwheel settings in your OS. So for example, if I set my scroll wheel settings to 'fast' in my OS, then each scroll wheel 'click' will result in multiple 'scroll events'...more than 1:1....so one click of the scroll wheel may generate 10 events....x 0.03...will cause the trim wheel to move 10x as much. The solution is to change your mousewheel sensitivity....and if you can change it "per application" even better. Changing our "delta" of the mouse wheel just isn't practical because everybody sets their mouse sensitivites to differing values, so I went with a very middle of the road value that's demonstrated to work well across a wide variety of use cases.

Could be...I override the brightness ratios to get the "double flash" on the strobes and generally separate the "target" (which depends on power) from the "animated brightness", (which doesn't depend on power)...and the target should go to zero with any loss of power. I'll try to recreate this one anyhow to see if the code has some hole in it here. Thx. -TomK

Well..each side of the trim switches in the Moo application do not represent A/B 'channels' in the context of dual channel autopilot/trim systems like we have in the IXEG; however, it certainly doesn't hurt to map all of the avail pitch commands to this simple system since there's nothing else to map them too. I'll squeeze this in. Thx.

maybe someone stole it? JK...on the list. thx daemotron...you're a great asset to improving the Moo! -TomK

Glad you had some success Dave, but this one troubles me just the same. I have never seen this issue....but then again, its easy for me to get into the same habits when starting the engines 1000 times. In no case should what you observed have happen. I'm going to try to recreate this one (anybody else also?) by trying differing lever positions during start. I don't like this one at all because it makes no sense to me just yet. (most bugs don't anyhow) Perhaps a quick test though if you have time?? try and repeat it, same way...right engine first. but before starting the left engine (and seeing the problem), try moving the right condition lever foward...either half-way towards full RPM or all the way to full RPM, doesn't matter, just get the right condition lever away from the taxi position.....and see if the left engine starts without killing the right engine then.

the HSI LED display uses "DME" for its distance readout. DME is a terrestrial, radio based transmitter, generally co-located with VORs (but not always) and ILS transmitting systems and hence why you'll only see distance when tuned into those transmitter frequencies. DME is not part of the GPS system at all and so will not display on the HSI. This is simply a classic case of putting a GPS in a 40+ year old panel