tkyler

Maybe its time to expand my explanation of how this works a bit...in case there's some hardware bug with Laminar when swapping a bunch of assignments dynamically we don't know about. I'll even drop my pants and risk embarassment to show my comittment to fixing this Reference my code for handling THROTTLE 4 (right side) When you assign an axis to anything in that pull down list...throttle...throttle 1, prop 2..whatever. Us developers then access a specific dataref corresponsing to that axis mapping. Laminar gives us this mapping. The dataref is even called, "joy_mapped_axis_avail[n]" where n is an index corresponding to the assignment type(throttle/prop, etc). So if you, for example, assign a lever to "throttle 4", then that means index[24] (24 in Lua, 23 in X-Plane). So the code above says If a user moves axis [23] (remember Lua is +1...so 24 here means 23 in X-Plane).......which is the THROTTLE 4 axis, THEN.....has the user checked the 'auto stop at detent" preference. If they have, then run the auto-stop at detent code and ignore the detent ratio. ELSE.....if the 'auto stop at detent' is UNCHECKED, then the user either wants LEGACY behavior, or they have a physical (or desire a virtual) detent. ...so lets now check a few more things. IF the user sets a power detent ratio of 0, then they want LEGACY behavior, BUT if the power detent ratio is non-zero, then they want to simualte a detent. ..and the final step is I simply read the joystick value between 0 and 1...and then write to the manip value (verify by mouse usage) that same value, between 0 and 1...and that's it. I simply read the joystick and drive the mouse manip. This is why I ask folks if it works with the mouse. If it does, then we have either a hardware mapping issue, or some kind of bug in Laminar code we don't know about. The way I would debug this is use the free Dataref Editor plugin and look at the THROTTLE 4 dataref...and if, when you move it...it goes to 1 AND the value it gives me is non-zero and also moves with the axis....then I expect the code above to work....and it always does for me, not matter how many times I test it....BUT a caveat. When I dev, I may change hardware assignments 50 times a day...set a lever to throttle 3, then 4, then brakes, then yaw....just to make sure it always works no matter which hardware lever is assign to whatever...I totally randomize my lever assignments when testing....AND I do so without rebooting X-Plane....and there are times when something won't work at some point and it simply does not pass any sniff test and I finally have to chalk it up to some corruption of data and end up rebooting X-Plane and a LOT of times, things go back to normal. I don't ask why in these cases...as I know switching hardware assignments so agressively could easily expose some weakness in X-Plane code that they never expected users to do, etc. So...hopefully we're not seeing something more sinister. God forbid your THROTTLE 4 uses some index that is NOT [23]....as that defeats the entire purpose of the mapping Laminar gives us to handle hardware. Without verifying (via Dataref Editor Plugin) what values your joystick is changing when assigned to THROTTLE 4, I'm a bit at a loss. I apply this exact same paradigm to all the other axes possibilities...the code is very similar between all the assignments, not just this THROTTLE 4 example. -TomK

Sorry about this gents. I'm in agreement. As soon as I get back home next week, I'll tweak this back to something reasonable. -TomK

are you referring to the Altimeter preselect? (scrolling digits for the ALT capture)? -Tom

Unsure the integration of the Avitab itself with regards to interaction, but will look into it soon. The MU2 release is far, far from 'set in stone' and is simple the new 3D/fmod baseline upon which I'll build more accuracy and more convenience/GUI functionality. -TomK

Welcome jas. Will do even more VR testing in the very near future. -TomK

Bulva.....I might be agreeing with you that its not a hardware problem....but neither am I admitting its an MU-2 problem just yet as I've seen this one myself. The only code I have that disables nose-wheel steering is ONLY when the chocks are in place. There is a dataref: "override_wheel_steer" that I set to 1 when chocks are in place. When chocks are removed, this goes back to zero and X-Plane is supposed to then control nose steer based on any hardware axis assignments that affect steering. I do no 'writing' to the steering at all, never have. If no hardware assignments, then the nosewheel is supposed to be coupled to the yoke/yaw steering. That's all their is to it (or supposed to be). I will do a bit more due diligence in my configuration testing to see if I can see some kind of repeatable pattern and if so, will then take that to Laminar. It is my current theory based on observations to date that when making hardware assignment changes, X-Plane is not 'restoring' some type of control at the time of axis reassignment and hence why a restart ends up fixing it for most folks eventually. The difficult part is I have not found that theory to consistently bear out. There seems to be some type of relationship of X-Plane's code between the steering and hardware toe-brakes axis assignments that may come into play, but I have yet to establish any hard relationship. Of course once it works, its easy to forget until you end up playing with it again. All in all, looking for that silver lining....I'm glad that this one part has gotten going for you. -TomK

I can't speak to all of these atm Bulva, with my being away from my development computer this week. I'm sorry you're seeing the issues you're seeing atm. And for the record, what is "go crazy"? spinning round and round forever is one form of crazy....moving and stopping somewhere you didn't expect is another form of crazy etc, but an accurate description of each helps us a bit further down the road. Is anyone else seeing improper prop-lock behavior after a cold and dark start? (not overspeed governing, that is a known bug for 2.01) -TomK

So i'm just now starting to dabble with OpenGL overlays. Its always been somone else's job on my teams. I'll start with the ghost Throttle graphic similar to IXEG/TBM...and then can progress to more helpful indicators also. Such graphics will always prove helpful in the development of the GUIs...allowing that to evolve as well. -TomK

yea, this one had me saying some undesirable words at my screen too. X-Plane still throws a curve ball every now and then. When it comes to hardware, the "bindings" between x-plane and the hardware itself are most 'clean" at sim launch. When testing...changing hardware settings "mid simulation" can cause weird issues in my experience, and only repeatable behavior with two successive starts of x-plane confirms repeatable behavior for my development purposes. -TomK

A bit of words I hope may be encouraging. The fact that I'm at Oshkosh isn't helpful atm I know. Once back though, I will be taking all these inputs and quickly implementing them. If it takes a few rounds to iron out the bugs, it still should not take too long. There are many differing preferences with regards to users hardware and getting them all accomodating without breaking each others preference and still fighting with X-Plane is a challenge and requires careful approach. But I will get there and it will be swiftly and quickly. I can't help but notice that a good 85% of users issues here with Version 2.0.1 is related to harware....no surprise considering the magnitude of the change. The MU2 quadrant operation is critical to a smooth simulation and until that's right for everybody, I agree the operation will feel clunky. -TomK

That behavior assumes the correct hardware setup, so we'll start there and hopefully the prop locks will fall into line after. For dual lever "auto-stop at detent" behavior ..and I know you've set some of this up already from above...but just to make sure we're on the same page..... 1) Assign power levers to throttles 3/4, not 1/2. Makes sure you have no response curves assigned to the power levers. Delete them if you had them previously. 2) Assign the prop levers to Props 1/2, not 3/4. Set a response curve for the prop levers to the values shown here (in the CONDITION LEVER section) 3) Check the box "auto stop power levers at detent". (FYI, the "detent ratio" value is ignored if this box is checked, so does not matter whats in it) 4) Use the "lift power levers" command to lift the power levers. 5) Use the new "EMER" commands to move the prop levers to EMER. Note that the prop/condition leveres must be near the TAXI position for this command to do its job and move the levers to EMER STOP. The behavior is as intended (assuming youre power lever is in the BETA region at the time you hit the command. There IS a bit of a paradigm question here as to what kind of behavior is desired. For example, one option is to "lift power levers" and if your hardware lever is in the BETA region, then you have to move your hardware to go "recapture" at flight idle before you can move the levers into reverse...and thd other option (which I implemented) says, "if you move your lever into reverse...and then use the "lift power levers" command, then the power levers move to where your hardware is..which is in reverse, so they do animate down to meet your hardware position. I can see how this may have some fans on one side, but not the other. Puting yet ANOTHER hardware option in....I'll have to think on how my trouble that would be without breaking someone elses' preference. -TomK

FWIW, I've seen some issues with the nosewheel steering when changing hardware config settings and not restarting x-plane, especially with regards to the toe brakes. In other words, I'd assign axes to toe brakes..test..then change back to another axis..and the nosewheel would not steer anymore, even though the "override_nose_steering" dataref was zero (which means X-Plane is supposed to control the nosewheel with yoke)...and restarting the sim fixed the issue. Assuming folks don't normally change their axes after initial setting/saving of the profile, I didn't bother to figure out why this anomaly happened and chalked it up to some internal X-Plane weirdness with conflicting assignments "pedals vs. no pedals" in the same sim session. The only common denominator I found was there was some axis set to be a "toe brake" at some point in my testing. Just a potential data point.

Do you have any pedal hardware? Are you expecting the nosewheel to steer with the yoke?

Because there was a configuration designed for it to work with throttles 1,2 and 3. BUT other, highly desired preferences were not accomodated for a lot of users. In 2.01, I have accomodated this other functionality and in doing so, had to change the way the hardware is setup. HOWEVER.....with the new hardware assignments, The paradigms used in 2.0.0 can still be applied in 2.01 so the levers operate exactly the same as they did in 2.0.0 -TomK

Agree. will look into this. I did test it in several regimes and it worked at the time...but clearly borked it with subsequent code probably. Thanks -TomK

FYI, this is typical...many times, all I have to go on. Notice it doesn't say what happens when you move from RET to OFF? So the behavior is unknown unless you test it on a real MU2...which is not as easy as it seems sometimes. Many owners don't respond to requests for you to "go play with all their switches" and so you have to do the best you can. In this case, I surmized the behavior and programmed it in. Maybe it'll be different when this owner lets me play with his switches tomorrow.

When using the hardware power detent ratio, then the bullet item below, given in the instructions given in my docs. Your screenshot clearly shows that yours IS checked....which supercedes / ignores the Power lever detent ratio. Previously I had "hid" certain options based on what users selected to try and avoid this confusion, but a "dynamically changing GUI screen" really put off some people as confusing so I kept it in. Its always a compromise between customer prefs. In the GUI prefs, make sure the option Auto-stop power levers at detent is UNCHECKED. The MU2 throttle behavior is very unique and requires a careful set of configuration options to be set, in order to accomodate all the hardware configurations people may want to use. As I just mentioned, above, you're configurations are not correct for the way you want to operate your hardware and when this happens, the levers get conflicting signals and input and yes, could probably go haywire. No clue. Not enough information from just that screenshot on how you ended up there.... they work great on my end. You flip both to EXT, then one back to RET, then both to OFF...that will result in what your screenshot shows...and is correct. I have NO clue what you're doing leading up to that screenshot. But that config IS possible depending on how you manipulate your switches. I will continue to refine the docs as much as is required to be more clear and folks understand the setup options

The torque does seem a bit high. I tweaked the prop blade angles slightly to yield a bit more thrust accuracy in the 'taxi regime', but this seems to have affected the torque adversely at flight idle. Becuase we don't get detailed "prop geometry" information, tweaking the prop / angles is a bit of a empircal process. Captain Crash has begun tweaking the prop with some flight testing and I expect to keep tweaking these till we converge on well rounded behavior. As far as the 150/160%, I can't say I've observed / measures the needle over 120, so unsure the exact representation of the needle position....but the engine is capable of 140% at sea level and does not have any kind of automatic limiting. It is up to the pilot to keep the power under 100% on takeoff. I should probably put a virtual stop on the torque gauge at 120. I don't know if the real one does this because I've never found an MU2 owner willing to push his engine past 100%. ....and the shops I've talked with who work on TPE-331s haven't really ever tried to "see what the gauge does" over 120. -TomK

X-Plane's "engine start" system is a bit simplified relative to real engine dynamics....it never really took into the account the dynamics of an air start and the differing forces at play relative to a starter. The procedure above will work, but I've found its best to hold the unfeather button almost till idle....and even when you let the button go, you'll probably see a quick drop in RPMs before the engine "kicks back in". -TomK

Updated Docs http://togasim.com/mu2docs/supplements/bug_tracker.html http://togasim.com/mu2docs/setup/hardware_setup.htm Update work is closed for Version 2.01. I believe I got just about 95%+ of everything. I'll be at Oshkosh Air Venture for next 10 days and not working, but will eyeball the forums. The updated docs reflects the changes made that should be pushed out in an update very soon. The docs changes are mostly the bug tracker and also the hardware config page, which highlights the new hardware configurations to get the TBM-style throttle and "condition lever commands to emergency". -TomK

Thx for those N67CX. Do you have HDR enabled? You describe a lot of "non-3D" lighting that indicates this is the case. The cockpit flood is a bit different from the other 3D lights however and not an indication that the other 3D lights should be working if HDR is turned off in your graphics settings. I'll cull through this list and put the relevant items on my todo list. I apologize for the short delay while I'm enjoying Oshkosh, but will be setting up my VR machine right after -TomK

Thx Crash. good catch, fixed -TK

I haven't made any VR improvements for the next patch...due to the majority of users with both toe brakes and desiring the TBM-style throttle. I will be addressing VR after return from Oshkosh though. Sorry about the 'vacation' delay, but we will get you accomodated for sure. Work doesn't stop ...well..except for Oshkosh week....doesn't stop with the initial release. I'll keep on moving. -TK

Thank you and fully agree!

Though I am "out for Oshkosh Air Venture" for the next two weeks. I am trying to squeeze the first update out rather quickly though...not including GTN of course.