skiselkov

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.

The rain sound is the X-Plane default sound that we have no control over. We'll see if we can override environmental rain sounds in update 1.1, but currently this isn't a bug. That is not a bug. The Master caution sound is played into the headset as well as into the cockpit speaker. When setting the parking brake, you need to depress toe brakes first. That's how the real aircraft works. Without it, the parking brake has no pressure to lock into the braking system. Recommend you have a look at the "Operating the Throttle" interactive tutorial in the aircraft (tutorials can be accessed via Plugins > TBM900 > Tutorials).

Some plugins remove the TBM's crash handler, which prevents us from getting good crash logs and diagnostics to be able to debug problems. Please remove all plugins except for Gizmo and retest if you can get it to crash again. Since you said it happens during preflight, it should be a simple matter of a few minutes to get it to crash. If the crash doesn't occur anymore, try putting some plugins back and tracing down which one is causing it. Any info you can provide us on plugin incompatibility is valuable, as we can then try and address that incompatibility.

This is an artifact of how the refraction simulation works (it refracts in "screen space", i.e. it simply shifts local pixel lookup to another part of the rendered image). This is a performance saving measure, as realistic refraction would require ray tracing, which no production hardware (aside from the latest Nvidia stuff) can do in real time.

Yes, we simulate random ingestion of FOD if the INERT SEP isn't on. The chance is low, but increases based on surface type (lowest on pavement, higher on gravel, highest on grass).