tkyler

If I hadn't messed it up in the first place, we wouldn't be here at all....so I'll take the hit. The power levers are getting a thorough looking over...and the ghost throttle feature is forthcoming, which is also helpful in getting the throttles tuned for the typical use cases. TK

OpenGPWS crashes X-Plane on the mac the majority of times the plane is unloaded. I'll look at these again at some point...probably in V12. TK

can do Jerry.....never ceases to amaze me the combination of uses folks can use. TK

Its VR...look down

movie is standard MP4. Don't know what else to do...possibly a Windows incompatibility? It was encoded on a mac. I'll see if I can re-encode it. Its simply a video of the ghost throttle with 4 options for viewing: NEVER, ALWAYS, Flight idle and below, when misaligned" The wrong CODEC was selected when I exported. See YouTube link below. -tk

ghost_options.mp4

In modern equipment, I believe this is the case. The GLASS version should do that. ...but to my knowledge, the OBS on the old RD-550 HSI is a manual setting and is not slaved to anything. There is a specific option in Planemaker to automatically slew the OBS to the desired track of the OBS...but I have not selected that option for the OEM / GNS variants because of this old unit. (The RSG G500 requires it however). As such, it can be adjusted at any time. If the OBS on this old unit can be servo/clutch driven, then I am unawares of such functionality on it. Also, when the 530 is in GPS mode AND OBS is selected on the 530....then the HSI knob can be used to input an intercept bearing to a waypoint. As far as the HSI OBS not adjusting in GPS mode as Daniel mentioned origninally, that has been fixed for the next update. -TK

That looks more normal "as far as rotate movement"..which is what I keyed on in my previous response. Understood on the "no sound and no lift animation" will look into that. TK

step in the right direction

@Bulva somthing is funny. See below screenshot. On the left is my mapped hardware axis value is 0.08, exactly as shown in your response curve screenshot above and validated by dataref editor output.. For this prop1 hardware axis value of 0.08 (8% of overall prop RPM range), then the resulting prop rotation speed should be between 114-115 rad/sec....and the 3D lever is animated based on the RPM setting (not hardware position) and should just align with the TAXI mark at this (0.08/114.7) value pairing. The 2nd screenshot at the right, shows a non-adjusted response curve, 0-1...and an axis value of 0 (lever fully aft)...and the 3D lever is now below the line as expected in this case..its lowest possible position with a hardware axis. The only way for me to confirm your full setup is for you to send a similar screenshot. In the end, we're matching numbers to animation so without the numbers, I can't tell whats going on. This is straight up linear interpolation and its working perfectly fine on every axis I try this with. Your 2nd video suggest no response curve mapped to 0.08 on the low end.

post reponse curves for the prop axis please Bulva.

Updated docs (bug tracker) to reflect work done towards 2.0.2 update. Should roll through remainder very quickly, within day or two at most. -TomK http://togasim.com/mu2docs/supplements/bug_tracker_201.html

In another post, I gave my own interpretation, I suspect you'll come across it if you haven't already. Your explanation above seems to be very close to my interpretation also so I think I have a good understanding of your operation. My biggest concern is making sure I accomodate your preferences while not messing up other settings I have for other hardware configs. I have most all of the 2.0.2 update items done (docs do not reflect this yet) and I'm quickly getting to this last item, which is accomodating the bravo (with its "button at the detent") which is a bit unique. So hopefully tomorrow I can get this work put it and get the update out asap. Worst case, its not quite there, we work through it and I get another update out -TomK

I'm going to attempt to describe your hardware behavior @Bulva Let me know if I'm on the right track understanding it. As you retard your hardware levers from the ALPHA region towards the BETA region...you approach the Flight Idle position, i.e the "transition zone" (0.47-0.53) in your script. Because of the checkbox "Auto-stop at detent"...if you move your levers further aft of your tolerance zone, then no harm no foul...we're all good, the levers won't follow. BUT...you have to be in your tolerance zone to lift the lever so when you do lift if, you don't get any crazy lever moves. THEN....as you continue to move your levers further aft towards hardware position zero (just above your detent button), you are now controlling the BETA prop pitch directly....BUT...because of your response curve, Bravo hardware position 0 is NOT mapped to 3D lever position 0 (full reverse pitch)...i.e, there is JUST a little bit of negative pitch "still in reserve" So now, with your joystick at hardware zero and JUST AT the command detent....you can pull your hardware levers aft over that detent and the REV commands will command the 3D levers JUST a bit more aft for full reverse? And you can tweak your response curve (left side) and the REV command substractions (currently 0.002) to tailor the transition to reverse to your liking?....and I assume the 'flat spot' in your response curve is simply to give you a bit of wiggle room around the tolerance zone? Is that an accurate description of your operation and preference? -TK

I still can't figure out what it does Mostly because the FlyWithLua API is strange compared to the X-Plane SDK start/hold/end callback paradigm...so I can't tell if there's any "hold" or "one shot" things going on. I really need either a video of both the hardware and 3D quadrant at the same time, or a really really good step by step description of moving the lever from full power to full reverse and whats going on along the way....when buttson are pressed, what happens when the buttons are pressed...are they being held down? or the levers moving WHILE buttons are being held down? etc, etc. -TK

The original intention of "lift both power levers" was for users with single paddle hardware, which use a completely different array index value for THROTTLE. It really wasn't intended to be used with dual lever setups. When you execute that command with the 'TBM style' method, then I look at the raw joystick value to see where the hardware is so I can move the virtual throttle to match its position below the detent. If you have a dual lever setup, then what I do currently is look at the "single lever" array index value (which is zero in your case because a single lever throttle isn't assigned in a dual config) and bam...the levers jump to zero because they think that's where the hardware is. That's why they jump to reverse. Of course that is still a relevant command, even with dual levers....so.. ....what may be needed here is simply a separate set of 'lift' commands, one for single lever and another for dual. That is, by far, the easiest solution, rather than me trying to write a bunch of "guestimate' code on lever assignments.

ah yeah, Ok, I'm seeing what you're seeing now. tk

Default commands now drive the alt preselector Added 3 commands for this switch Those default commands do drive the barometer knob/values for me. Default commands drive the DH knob/display now.

Implemented for 2.0.2

And just got some hard numbers from a Moo owner. FI torque is approx 15% on the ground and leans closer to 20% on descent, but may vary based on engine 'personalities'. also, I met with both Philipp and Austin at Oshkosh AirVenture...and Philipp is going to put in both NTS lockout and overspeed governing for the TPE. Its a lot easier for them to do it in their code base than for me to "hack" around their current implementation -TK

agree, just need to record the right sound. Particularly the latch. Wasn't happy with what I orginally had, but definitely will get those sounds in. -TK

Understand your sentiment Marc and many times, these bugs do seem silly, even to me. I'll keep fixing though and we'll get through this phase soon enough. -TomK

The knob is animated off of the default x-plane dataref, nav1_obs_degm (because the knob is mechanically linked to the compass card). The knob should animate any time the HSI OBS rotates. The GPS/VLOC should have no bearing on the knob animation of course.... Those commands animate the HSI knobs for me no matter what mode (VLOC/GPS) I'm in, so I can't confirm what you're seeing.

All good Jerry, thx for clarifications! -Tom