skiselkov

Can you please post your simulator's log file and a screenshot of the problem? Seems like there's some kind of system startup problem. Normally the aircraft loads up with engine shut down.

Thank you for the test! This data was the critical bit I've been missing these past few days. An incredibly stupid mistake of mine. Expect a fix in the next build. Apologies it took so long, been chasing my tail around on this and looking in unrelated pieces of code.

The aircraft position restore code should be detecting elevation changes. No idea why it doesn't. Will need to look into it.

Next build will contain the following datarefs: tbm900/fctl/ail/relative = -1 .. +1 tbm900/fctl/ail/neutral = -1 .. +1 tbm900/fctl/ail/load = 0 .. +1.0 tbm900/fctl/elev/relative = -1 .. +1 tbm900/fctl/elev/neutral = -1 .. +1 tbm900/fctl/elev/load = 0 .. +1.0 tbm900/fctl/rud/relative = -1 .. +1 tbm900/fctl/rud/neutral = -1 .. +1 tbm900/fctl/rud/load = 0 .. +1.0 _relative: represents where along its travel the flight control sits (0 being center). This changes according to trim input and user flight control forces applied. _neutral: represents where along its travel the flight control would be if zero user force is supplied. This is your centering force target. _load: represents the relative aerodynamic loads on the flight control. Use this to calibrate your centering force amplitude. With these datarefs in hand, you should be able to calibrate your force feedback algorithm to want to return the controls back to the neutral force point and also the magnitude of the return force.

X-Plane models fuel flow in kg/sec, irrespective of the fuel type. It's up to the addon maker to fine-tune it so it behaves sensibly.

Thank you for the suggestion. We're aware it's a chore to redownload on each update. In the near future we plan on turning down the frequency of updates, so it shouldn't be such an issue anymore.

Thank you for the information! Really helpful. We'll keep an eye out for users with 8GB of RAM and be sure to pass your recommendation along.

@borrrden Thank you for getting back to us with that info, really helpful!

Have to agree @Yetteh , this one smells like an X-Plane problem. If the crash occurred right after you controlled map zoom and the log is not showing any TBM code running at the time of the crash, then it's really hard to pin this on the TBM.

This crash was caused by a divide-by-zero inside of xEnviro. Doesn't appear to be a bug in the TBM.

The manufacturer calibrated the aircraft only in USG, so we can't go around changing indications in unrealistic ways.

This is a limitation of the Laminar G1000. Sadly not much we can do about that at this time.

You're simply hitting the GPU door clickspot from inside the cockpit. We'll look at adding a no-up underlayer underneath the clickspots so they can't be actuated from the cockpit.

@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.