skiselkov

Please use sim/autopilot/take_off_go_around (Autopilot take-off go-around).

Yep, this one looks like Gizmo acting up. I'll notify the relevant people of this. Does this happen on every license refresh for you? On the right edge of your screen is a little sidebar window with Gizmo controls. If you click on the lightning bolt (labeled X-Aviation Licensing) and click to update the licenses, does it crash? If so, we could try to trace this down.

Can you please attach a Log for such a flight?

Glad we got this figured out. The red lever is the manual fuel control. If it's raised up and the engine is spinning, it's dumping huge amounts of fuel into the combustion chamber, which then simply pools up and ignites all at once when you turn on ignition. This is referred to as flooding the combustor and there is a supplemental procedure for "fuel vapor clearing" that must be performed any time an engine start is unsuccessful. When the engine is off, ALWAYS keep the throttle in CUT OFF and the red lever all the way back.

Can you verify on the pedestal that the little red lever labeled MAN OVRD is fully back?

I can see in the log that the Combustor and Turbines have failed. Can you please open up the Maintenance Manager (should be a little window on the left side of the screen) and go into Engine > Open Engine and hit "Replace" under both of those? Then please power up the aircraft avionics and take a screenshot of the instrument panel.

It's a bug that you can click it. You should only be able to click that once (when you've had a cabin pressure vessel break) and not any more after that.

Does the issue appear every time X-Life is loaded? So is it permanent, or intermittent, or entirely random?

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.