skiselkov

We are looking into that ntdll/kernel32dll crash. Seems to be systemic, so we should be able to get this one addressed reasonably quickly.

What texture settings are you running. If your GeForce 1060 is a 3GB VRAM model, that is our minimum and that requires turning down the texture quality to medium. The aircraft comes packed with very high resolution textures.

Great to hear, thanks for letting us know!

Yes, it's the same reason. The Mac build got accidentally broken so it's not loading any of the custom code. I expect we should have the fix ready in a few hours tops. I'll keep you folks posted and let you know as soon as it's available.

Can you please try to delete "Output/TBM900" from the sim and then trying again? This removes the persistence state and gives you a fresh config of the airplane. Please let us know if it helped.

Can you share your Log file please. Also, temporarily try to disable any extra addons (besides Gizmo) to see if that clears the issue. If yes, add them back in one by one, so we can identify where the conflict lies (if any).

This is an artifact that is due to another bug on Mac. We will be rolling out a fix for this shortly.

Can you please check if you have a Saitek switch panel if - always put the AVIONICS switch to ON. Otherwise it kill the background G1000 systems. Or unplug the panel.

Your problem appears to be something different. According to the Log file, the simulator didn't even get to the first screen. I would suggest you reach out to Laminar with this, as none of our software appears to have been loaded on your system yet.

Can you please verify that you don't have an axis under joysticks assigned to Left Toe Brake or Right Toe Brake? If the aircraft detects a brake axis, that disables key-based brakes.

Fix verified. We'll just package it up and send it out.

I understand the issue here, so we should have this specific problem sorted quickly.

Folks, as promised, below is attached a CSL that's usable for showing other people's TBMs. Includes full animations on all flight controls, landing gear, lights. And it's PBRed to top it all off and highly framerate optimized. TBM900.zip

Yes, the VC yokes rotate approximately 80 degrees left & right for the roll axis.

Yes indeed, come by tonight's Twitch stream, we'll be showing it off.

Yes.

Video from second day:

Here you go:

While it is difficult to make exact estimates on framerates, an i7 4790K should be able to handle the aircraft avionics with ease. Most of the heavy lifting of the avionics rendering is shifted away to background threads, so even my piddly i5 4460 that I develop on was able to do a locked 60 fps while streaming yesterday. Of course, this was in an area with little scenery. I would say your performance will mostly be dictated by the scenery and your GPU horsepower, rather than being limited by the aircraft's systems code and CPU speed.

Yes you can, but if you specify what tweaks need to be made, we can try to build them in (if they don't conflict with anything else).

We can't make any firm date commitments yet, but I can say there's definitely light at the end of this tunnel! We will update all the usual places (including our Discord channel) once we have more info on release date, pricing and overall availability.

I develop on Linux, so yes, it will support Linux, Mac and Windows.

I'm happy to assist others in writing one, but I don't plan on doing it myself. While I would consider shared-cockpit a core feature requirement for an airliner, the TBM is almost never flown multi-crew, so that puts the feature rather low on the priority list from a realism perspective. And a second reason is that the airplane runs tons of randomizing code that gives it the "organic" feel of every flight being different, every system responding a little different to inputs, etc. Replicating that between two nodes would be a major undertaking and I'm not really sure is even practically possible (at least to my requirement of stability & usability) by using smartcopilot's simple dataref syncing approach. I suspect it would take a much more integrated approach that would talk to the internals of the systems simulation directly.

So as you fine folks may already know, in our usual style of going completely overboard on the level of detail, a few weeks back I've implemented a custom VHF radio signal propagation model. This means, NAV radios (VOR, LOC, GS and DME) are all simulating things such as terrain masking, terrain diffraction, tropospheric scattering, etc. The underlying computational model is based on the NTIA Irregular Terrain Model (ITM), an industry-standard model used for things like radio tower planning. The simulation includes a built-in analytics display that allows you to check the terrain profile being used by the radio model (please note, the image below isn't hand-painted, it updates in real time as you fly): What's recently new is that I re-implemented the ADF and standalone DME radios as well. So the entire radio complement in the TBM is as follows: Two VOR/LOC/DME radio. One ADF radio One standalone DME radio That involved re-implementing all course deviation needles and the DME tuning pages on the PFD. All features of the real G1000 are simulated, even some of the more odd ones: ADF, ANT, ADF/BFO and ANT/BFO reception modes. This is reflected in the audio ID portion, including the continuous tone you hear in BFO mode when no ADF signal is being received. All DME tuning modes simulated, so NAV1 slaved, NAV2 slaved and HOLD. Allows for flying the more bizarre approaches, such as NDB/DME. Intercom audio routing from the radios is properly implemented, so NAV1 & NAV2 buttons route the audio ID for the NAV1/2 VOR/LOC portion, the DME button routes the standalone DME radio audio (including 1250 Hz square-wave tone, instead of 1kHz sine wave) and the ADF radio routes the ADF radio audio (including proper tone & background noise behavior depending on reception mode).

So we've been hard at work at implementing a custom icing simulation & rendition. Everything dynamic and done via shaders, of course. Depiction of severe icing encounter. Inboard boot just inflated, so inboard leading edge is flaky as the ice flew off in chunks. Notice the ice isn't just a surface effect, it appreciably increases the thickness of the wing, as there are several inches of packed ice in this image: The jagged leading edge in the following screenshot is due to ice crystal growth. This is what makes the wing stop behaving like a wing and instead gives it the refined aerodynamic qualities of a brick: Any exposed sharp edges and point-like structures are prime ice accumulation space: Including wing leading edges, strakes, exposed antenna housings and flap fairings: While stationary on the ground, ice also tends to accumulate on the fuselage: