skiselkov

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:

Are you on our Discord server? We post updates there every few days.

It might just be a bad screenshot. They're the exact same rendering code. See better shot below.

I'm not sure what you mean. The SVS in the G1000 is exactly the same code as is running on the tablet display. This is not an X-Plane stock feature, this is bespoke to our model.

X-Plane 11.20 added an art control that lets me kill the background on the PFD. This has in turn allowed me to design a shader to pull some pixel removal tricks and finally sneak it under there:

Feature update for you good people. We've implemented the G1000 Emergency Descent Mode. That means no more setting up the simulator and walking away to take a nap. A brief demonstration: https://www.twitch.tv/videos/253395611?t=02h40m35s Now the avionics is watching for pilot alertness. The allowable time interval for pilot interaction is altitude dependent, but varies from 20 minutes at 15,000 ft down to around 8 minutes at FL310 (decreasing exponentially, so only about 10 minutes at FL250). If pilot inactivity is detected for the aforementioned period if time (no buttons pushed or knobs actuated on the G1000 avionics), the avionics will start a graduated process of alertness checks: First it issues an advisory CAS caution + one aural chime:"ARE YOU ALERT?". The pilot has one minute to respond by pushing any button or clearing the caution via the attention getters. After 1 minute passes and the pilot hasn't responded, the system issues a non-advisory caution saying "HYPOXIA ALERT". Non-advisory CAS cautions different from advisory ones in that the message stays blinking and the yellow "MASTER CAUTION" button stays illuminated. The pilot again has 1 minute to respond. Final call, the system issues an "AUTO DESCENT" master warning CAS message, illuminates the red MASTER WARNING button and a continuous aural chime is heard. If the pilot doesn't respond for one more minute, the red "EDM" AFCS mode is annunciated on the PFD, the autopilot preselects 15,000 ft altitude, switches to the FLC pitch mode to initiate a descent and selects maximum airspeed. On descent the engine will over-torque without the pilot making power adjustments, but the torque limiter can hold the engine at 108% safely for several hours, so it's a small price to pay for regaining consciousness. During descent, the system ignores pilot input. The only way to disable EDM mode at this point is to disengage the autopilot. Upon leveling off at 15,000 ft, the system resumes monitoring for pilot input for 4 minutes. If during those 4 minutes the pilot touches the avionics, EDM mode is canceled. If not, a second descent to 12,500 ft is initiated after the 4 minute timeout. The system now ignores pilot input and descends down to 12,500 ft remains there. At this point, the only way to disable EDM mode is to disengage the autopilot. That's all for now folks!

Ladies and Gents, our merciful @Goran_M has graced us with another batch of jaw-dropping renders of the work-in-progress fuselage. And I don't know about you, but I have to say I'm completely blown away!

Btw: to clear up the alphabet soup of the terrain awareness system in the G1000, you can read up on it in this manual: https://static.garmincdn.com/pumac/190-00709-04_0A_Web.pdf (although that one is for the TBM850, it's close enough to give you a reasonable idea). The TAWS alerts are described from page 427. We've implemented all of the alerts, although the availability of the Obstacle alerts depends on having a reliable obstacle database on hand (currently we only support this in the US, because the FAA provides a regularly updated, high-quality obstacle database free of charge).

The relative terrain elevation overlay is actually something I've been considering to implement, but since I saw it was being put into XP11.20, I didn't bother. But we do have a completely custom TAWS-B page which does the same relative terrain contouring coloring plus of course all the aural and visual annunciations of the real Garmin TAWS with all modes modeled (PDA, RTC, ITI, NCR, impact point prediction, etc.).

I've had a brief exchange with them over e-mail. The response was "no external integration API is planned at this time".

So I thought I might share some screenshots of a new feature that's being developed for the aircraft: terrain synthetic vision. This was always one of our aspirational goals, but we couldn't get it to show underneath the PFD symbology due to a lack of programming interfaces to the stock X-Plane G1000 to accomplish such a thing. So we've done the next best thing: we've added a tablet to the yoke (which you can hide/show separately) and modeled the synthetic vision system (SVS) modeled loosely on the SVS of ForeFlight: It is still a work in progress, but among the features are of course dynamic terrain display, with automatic mesh detail rescaling for terrain that's far away from the aircraft in order to keep the performance high, background terrain loading from X-Plane DSF files and also neat little things, like dynamic runway number rescaling on approach, so you can more easily identify close parallel runways: Part of the SVS is of course relative terrain height indication by dynamically coloring in any terrain that's close to our height, in this case yellow for terrain that's less than 1000 ft below the aircraft and red for terrain that's less than 100 ft below the aircraft. Terrain more than 1000 ft below the aircraft is colored in using the absolute height scale employed by the Garmin G1000 (basically, the lower to sea level, the greener and the higher the terrain, the browner). In the screenshot below, we're on approach to Aspen, so approximately 7000 ft above sea level. Notice that we have a 200m-scale north-south-east-west grid pattern overlaid on the terrain. This helps terrain shape recognition, make recognizing motion to the terrain easier and also gives the view a sense of scale. When high up, it's useful to know your gliding range in case of an engine out. We have range rings placed at 3, 5, 10, 20, 30 and 40 NM (the dark bands in the screenshots above and below). The range rings dynamically adjust to terrain contouring, helping both in terrain shape recognition as well as knowing how far the aircraft can reliably glide before running out of energy: The SVS includes an auto-declutter display mode, where the compass rose and VS indicator momentarily disappear during extreme bank & pitch angles, to help you recover from abnormal flight attitudes: As I anticipate a question about integrating a web browser, let me preemptively answer that so far we're not looking into this. And that's all for now folks.

Thank you for the links. We have Jason on the beta team and he's being extremely helpful in making sure we got the details correct.

No, this is a different feature. It allows you to synchronize the maintenance state of the aircraft between two computers. The purpose is to enable things like FSE groups to cooperate in the use and maintenance of a single persistent aircraft. Another possibility is if you own multiple computers with X-Plane installed, you will be able to keep all copies of the aircraft synchronized. Ultimately, the idea is to teach users that even if you're not flying the aircraft, somebody else might be, and therefore when you get it into your hands the next time, you need to perform all the proper checks, tests and watch out for faults that you might not have caused, just like you would in the real world. No more of the "I know it's gonna be fine, because it was fine the last time I flew it". Well, you don't know how the previous pilot treated the aircraft, so you better make sure you take that detail into consideration.

The algorithms for wear estimation are based on a mixture of real world performance data, operational procedures and an approach "from first physical principles" where we don't have exact behavioral data available. So for example, the engine's ITT behavior is tuned from real ETM data, as is the behavior of the oil temperature at the main oil pump outlet (what you'd see as "oil temperature" in the cockpit). Other parts of engine heating are based on a bit of physical simulation and a healthy dose of hand-tuning to get it to be have sensibly. The "from first principles" approach was used extensively while designing the ECS logic. We know the overall compressor pressure ratio of the PT6 (~14), which the aircraft simulation then feeds as an input to compute adiabatic compression heating of the compressor discharge air. Then we follow that up with energy computations for air heating/cooling and cabin volume pressurization. These are then fed to the simulated air system controller, which takes these sensor inputs and adjusts the various ECS valve positions. So when you are seeing the valve positions change on the displays, it's not just a simulated bunch of "feel good" animations, it really is the air system controller "fighting" in real time with the physics simulation to try and keep the cabin at a sensible temperature and pressure, much like the controller logic in the real airplane does. However, we make no claims that this is a physics simulation package, nor that all the behaviors are perfectly accurate or that the model is in any way suitable for real world training.

Yes, the plan is for this to be VR compatible on release.

Wish you guys the best of luck porting this over to XP11 and really appreciate you decided to make this upgrade free. This will definitely help bring the 733 to the top in terms of quality. You can really feel the amount of informed hand-tuning and love that went into making it just right. XP11 also has the potential to become the premiere sim platform going forward and as such, the 733 will get prime exposure. We all wish you safety first and foremost. Work can wait.

Yeah, I can confirm that the default aircraft and even other addon aircraft are fine (tested the FJS732 and FF757v2). It's just the IXEG 733 that's broken, which is the bummer for me, because it's my favorite. Was just asking here if people don't have some obvious thought off the top of their heads, so I don't have to wait. I have no doubt you guys (IXEG) are going to fix this on the 733 once XP11 goes final. Thanks again for the response!

Thank you for the response! A few points to illustrate why I would like to disagree: The drift happens even with far lower power settings. The first 20 seconds I have power around 40-60% N1 (that's why I have the dataref readout there) and the drift is clearly visible. In fact, it happens even with the engine at idle (although the drift is quite a bit slower, see below), or pretty much as soon as there is any thrust imbalance and the aircraft is stopped. During this whole thing, the parking brake was APPLIED. Even at full power, the aircraft's engines shouldn't have enough power to overcome the brakes. Moreover, in this case the engine is working both against the brakes on the main gear AND the lateral static friction of the nose wheel. Put simply, this shouldn't be possible. This problem goes away as soon as the aircraft starts moving - a couple of knots of forward speed is enough to stop the drift at idle power. This leads me to the conclusion that it is some sort of bugging out of the new static gear modeling in XP11. This video is from the same testing sequence, just a little earlier while I was setting up the views. I don't think airplanes should behave this way on the ground. This looks a lot more like the physics kraken rearing its ugly head:

Great stuff, thank you very much, the values you mentioned worked perfectly. Now I just need to figure out that strange ground friction bug. It's like the physics are all screwed when the wheels are stopped or near stopped. Applying the parking brake and spooling up just one engine produces this weirdness:

The whole ground friction model on the 733 is screwed. With the parking brake set and one engine at idle, if you floor the other, the aircraft will simply start rotating around the main gear as if the nosewheel had no lateral friction. Bizarre.

Public beta 15 introduced a new suite of problems and I can't figure out how to solve them: When you're moving slowly (<3-4 kts) and deflect the nosewheel above ~30 degrees, the aircraft stops as if brakes had been applied (they haven't). Example video (engines running at a constant 42% N1): The engine idle is very low, below the green arc. N1 idles at 12% and N2 at about 52%. Normally the values should be ~20% and 65%, IIRC. Anybody got any ideas if this can be fixed in Plane Maker? If so, where? I tried reducing the gear flatplate area from 15 to 5, but that didn't help. As-is, the aircraft is pretty unusable in PB15. (I know IXEG will fix this once XP11 goes final, but until then if somebody in the community has an idea, I'd appreciate it!)