skiselkov

@Mark Hsu The TBM uses a completely custom trim implementation that ignores the values set in Plane Maker. It should behave realistically without additional tuning. The airplane sets sim/flightmodel/controls/hstab1_elv1def and sim/flightmodel/controls/hstab2_elv1def to the exact degree deflection value of the elevator given control inputs, trim settings and aerodynamic loading. The min & max of these values is -23 to +23. We currently don't have a dataref showing where the neutral trim point is located. If it helps, I can make one for you and also show you the relative aerodynamic loading. That should help you drive your hardware force feedback.

Can you please retest with X-Life disabled? I suspect an incompatibility with that addon.

Thank you, if it does, please reopen this issue. I'll mark it as "Feedback" for now.

Should be fixed in v1.0.7. The offending bit was that your scenery apparently contains a zero-length runway and that makes the runway rendering code in synthetic vision have a bit of a freak-out. In the next build, any runway sub-100m long will be invisible in the synthetic vision.

Coming in v1.0.7 tonight!

I believe we have this one finally nailed. Expect a fix in 1.0.7.

I believe we have this one finally nailed. Expect a fix in 1.0.7.

I believe this a race condition in a part of the licensing code. In build 1.0.7 this will be fixed.

@RzR and @JetNoise We're working that bug right now. Somehow the activation code got borked. Should have this fixed soon.

Yes, just back up the Aircraft/X-Aviation/TBM-900 folder. Eventually old builds might no longer activate, but at least for a while they should work ok (a couple of weeks at least, by which time we should have everything fixed anyway).

This is an oversight on my part, forgot to implement the hold function. "Toggle brakes regular" should work. We'll get the hold function into the next build.

Hey, sorry to hear it's still giving you trouble. Just out of curiosity, what is your FOV and from what distance are you trying to move the crash bar manipulator? The manipulator logic of X-Plane is sometimes a bit inaccurate if you are VERY close to the object being manipulated, or when your FOV is unusually wide. As a temporary workaround, can you please try binding a pair of joystick buttons or keyboard keys to this set of commands: tbm900/actuators/elec/emerg_handle_up tbm900/actuators/elec/emerg_handle_down These are the commands that the manipulator generates and that the aircraft systems simulation responds to. I hope you don't have any other switches bound to these (especially 2-position switches - not accusing you of being wrong, just some people have seen problems with controls not responding and they forgot they had bound the control to a hardware 2-position switch, so it was keeping the control in the selected position, despite attempts at mouse manipulation). Appreciate your patience and I'm sure we'll work this out.

Currently the only way to adjust volume is to use the interior sound volume. The aircraft is rather quiet inside when just sitting on the ramp. I was surprised when I sat in it with the engine running, having been used to the noise of piston engines. But the sound deadening on the engine is pretty stellar. It gets A LOT louder in flight, but that's mostly not the engine or prop, but the wind noise. I tried to adjust the levels in the cockpit to match what I heard IRL when flying the aircraft. The door sound is rather quiet, but I'll look at enhancing the door shutting "clunk". We might be keeping that too low. As for switches, they were recorded with realistic levels. When the engine is going and especially in flight, there's next to zero chance of you hearing any of those, unless you have the ear of an orchestral conductor. As for headset master caution - they really are very loud. I'll see if we can add a control, like over the intercom, to control headset volume. There is a control there right now, but it controls the interior volume in X-Plane, not just the headset.

Thank you, I have a good idea what went wrong and will fix it!

Thank you for posting. It's not a bug, but a limitation of how the airframe icing effect is drawn. The top surface is actually composed of two separate icing sheets that join where you see that break. Matching them up has been a major pain and I'm not sure we can make them fit any better short of redesigning the upper surface icing model entirely. I'll have a look at this later on, but you just happened to have found the one corner case when it looks off.

I suspect X-Plane does its internal window layout differently at times and that's what's confusing the drawing code. Are any of you running 2nd or 3rd monitors besides the one ultrawide? Even if X-Plane is not being drawn on them, I think X-Plane alters its windowing coordinate layout when it detects multiple monitors.

The next build contains a reworking of the way we scan brake assignment axes for changes and should address this. Please test build v1.0.6 when it's out (should be any moment now).

The next build contains a reworking of the way we scan brake assignment axes for changes and should address this. Please test build v1.0.6 when it's out (should be any moment now).

The next build contains a reworking of the way we scan brake assignment axes for changes and should address this. Please test build v1.0.6 when it's out (should be any moment now).

Do you happen to have a log file from that run? This looks like the failure datarefs were modified by something randomly, but it's hard to be sure without the log.

We will have a build in the near future that significantly enhances VR usability. That will take care of the knob rotation problems.

I had a test of this last night with my crusty old Saitek rudder pedals. Takeoff is perfectly controllable, it just takes practice. Key points to keep in mind: Bring the power in smoothly. Don't just jam it forward. Keep the inputs small. All it takes is a bit of light pressure. No need to go stomping on the rudder. Predict, don't react. When you've applied a correction and you see it taking effect, neutralize your inputs BEFORE you reach where you want the nose to be. The aircraft has yawing momentum, so if you wait until you are through the centerline again, you will zig-zag around on the runway. Be quick about your inputs. Quick but small inputs are better than slow and large ones.

Can you please try without additional plugins loaded? I suspect some of them are messing with the electrical datarefs and are shutting part of the avionics off.

For your problem regarding the rings not being centered on the aircraft, that's a stock G1000 bug that we have no way to fix. Recommend you file that one with Laminar. Best reproduce it on one of their planes (e.g. stock C172 /w G1000), so they can't claim it's something we broke.