daemotron

The current stable SDK is v3.0.3, which fits with 11.5x. There is also a beta version of the v4.0 SDK available (cf. https://developer.x-plane.com/sdk/plugin-sdk-downloads/), which is the one fitting for 12.0. The API documentation is however not yet updated to incorporate all the XPLM400 changes. So in short, if a plugin builds without issues against the XPLM400 API, there's a good chance it will simply work without problems. If it fails to build and the reasons aren't obvious, it'll depend on the developer's patience digging into the header files and resorting to try & error troubleshooting. In both cases though chances are that SDK changes down the road entail further changes to the plugin code.

All custom commands are documented here: https://www.togasim.com/mu2docs/setup/mu2_commands.html

I don't know anything about those FAA parts (I'm EASA regulated ), and "study level" can really mean anything and nothing. I mean, as an example, is it important to simulate fuel sampling and oil quantity checks on a small piston aircraft, 'cause that's what pilots have to do in reality? Or is your focus on flight dynamics and avionics? Where to draw the line? I went with a selection of aircraft that I consider "study level" because they require studying how the real thing works, and are also built in a somewhat instructive way. I would never consider a model "study level" if it doesn't come with documentation (or documentation is otherwise publicly available) - how should I study if I can't find the required documents (POH, FCOM, FCTM, ...)? I'm trying to match your set of categories with my favorites: Small aircraft for private pilots and flight schools: The AirFoilLabs Cessna 172 NG makes an excellent model for flight students - though I'm still waiting for the analog panel they announced The Torquesim Cirrus SR22 is IMO the best high power piston aircraft model out there - particularly the version with Entegra avionics is superb. Personally, I prefer the TN over the normally aspirated engine, since managing a TN engine correctly (which TS models pretty accurately) IMO is a great experience and additional stuff to learn. Light twins (multi-engine trainers and hobbyists): IMO not covered. There's a load of excellent models out there (Aerobask's DA62, Torquesim's Islander), but I wouldn't categorize them as study level. Medium sized aircraft for charter ops or corporate transport: The TOGA Mitsubishi Mu-2B Marquise (v2) is my favorite turboprop - it's a quirky beast, so IMO a lot more interesting than the "boring" TBM (though that's an excellent aircraft model as well, just not as exciting as the Moo). You can learn a bunch about roll control and roll trim flying this aircraft, and it will savagely punish pilots flying uncoordinated turns. Light business jets IMO not covered yet by something deserving the term "study level". I suppose TS will change that with their Citation II, but it's not available yet Heavy business jets HotStart Challenger 650, no doubt. It might get a strong contender with the upcoming Aerobask Falcon 8x, but absolutely not sure there. Airliners IMO none atm. Many models out there get certain aspects right, but I don't see a model that actually integrates all aspects properly. As a compromise, I'll list my favorite airliners which I consider close to study level: Regional: FlyJSim Dash-8 Q400 Domestic: ToLISS Airbus A321 Twin Aisle: iniSimulations Airbus A300 Intercontinental: Felis Boeing 747-200

It was included up to v10 - in 11, Laminar had it removed already. P. S. for anyone starting to dip their toes into creating aircraft, before going with the big bazookas (Gizmo, SASL) why not do your first steps with xLua (or xtLua)? Sure it's less powerful, but also simpler and easier to get into the absolute basics.

Laminar based their new windscreen effects on the pioneering work Saso has done with librain. In one of the interviews Austin (or Ben?) gave a few details, and it sounded to me like they used his open-source implementation, adapted it to Vulkan, and embedded it within their rendering chain. One of the improvements pointed out in that interview was that now it was embedded, it could make use of all physics data, including prop wash etc. to natively couple effects with XP's physics calculations.

When flying the OEM version (or any other aircraft with radio navigation and without GPS), I use a simple pencil/paper route plan. Usually I use Skyvector (and Navigraph charts for departure and arrival) to establish the route. Then I simply note down all segments of the route on a piece of paper, using my own shortcuts. In flight, I just follow the instructions I wrote down. Here's an example of a route plan for the route EGLC/EGGD: route: EGLC/09 CPT6U CPT CPT1B EGGD/BRI.I09 transcript: dep RWY 09 92° clb 520+ until ILST 111.15 D+1 int BPK 117.5 329° in int BPK 117.5 272° out D+26 trk HEN 433.5 int CPT 114.35 225° in int CPT 114.35 274° out D+32.4 trk BRI 414 @ FL070 hdg 278° IBON 110.15 D+8 trn left 107° int IBON 110.15 87° intc @ 2,500' dep = depart int = intercept trk = track hdg = fly heading trn = turn This way I can break down a flight plan with SID, STAR and IAP into 10 lines with simple instructions. I find it easier to have all frequencies and courses noted down and ready at hand. Theoretically a fully fledged LIDO format plan would deliver the same information (plus a lot more), but for me it's harder to extract those bits from a bunch of paper sheets.

I'm aware this would break with how the aircraft is in reality, but for simmers not using VR it's impossible to quickly glance down at the roll trim indicator without losing situational awareness. The time it takes to pan the camera down, adjust trim and look back, is usually sufficient to have gone off course when hand-flying, and/or even banking to 45° and more. Having the little wing position indicator replicated somewhere in the pilot's FOV on the instrument panel would immensely help trimming the aircraft. I have no problems with rudder and elevator trim, but a wrong (even a neutral) roll trim setting can nearly flip you over at low speeds and high power setting. That being said, if someone has a technique how to deal with that in sim (with a non-force-feedback yoke), I'd love to hear how it could be done without referring to the indicator.

Do you have a hardware switch bound to avionics on/off? If so, this hardware switch cuts the avionics bus, leaving those devices unpowered. The Honeycomb Alpha is prone for this (avionics bus 1 switch is bound to this by default). Solution: unbind this switch and reload the aircraft.

For me it doesn't freeze entirely, but drops to ~1 FPS when trying to cruise in the flight levels (flying at lower altitude in the same area didn't cause any issue). Seems though that only XP's main thread gets clogged, the displays still update. I can reproduce it by loading at Nantucket (using the iBlueYonder scenery that was sold at X-A for a while, but seems to have gone from the store), climbing out and heading for the LGA VOR at FL340. Flying the other way from the main land towards Nantucket Island at 17,000' doesn't create any problem. This makes me wonder if it is perhaps triggered when a scenery with custom mesh is unloaded when leaving the area. I also looked at the performance view in the plugin admin. When the issue starts, it's first X-Plane itself that goes up to ridiculously high frame times (~500,000us). Slowly the other plugins start following suit, until the Challenger reaches ~250,000us - I'm assuming this is rather a consequence of the first rather than the root cause. I have tried with both, unlimited worker threads, and a limit of 24 (my sim rig has 16 physical / 32 virtual cores). On the ground I get between 50 and 60 FPS with the Challenger (using pretty high rendering settings). When the problem occurs, FPS drop to 1.1 - 1.3 FPS, driven by CPU time. Only one CPU core then is running under full load (and with boosted clock rate), the others are (pretty) idle and run with throttled clock rate. I let the system sitting for half an hour to see if it recovers by itself, but no luck, so I had to close X-Plane (I could initiate a normal shutdown through the menu, but its very tough to navigate the menu at 1 FPS). I don't have the AlpilotX mesh, but of course a lot of airport sceneries bring their own tile nowadays. The only things I can try is the SAM integration for Traffic Global - must test that tomorrow (not sure what it was set to), and a worker limit below 16. Log.txt

I found that I can cover (nearly) all Linux users by providing one build for the Ubuntu and one for the Arch Linux distribution family. Unfortunately I haven't found a way yet to create a build catering to both, Ubuntu and Arch based distributions (experience gathered with the FSEconomy client). With the M1 architecture, Mac also adds an additional required build, bringing the total up to 5 builds (Win, Intel Mac, M1 Mac, Ubuntu, Arch).

Do you by chance have a hardware switch bound to the default avionics on/off command? I ran into this on my first attempt...

Some impressions from this morning's flight (EGLC - EGGD) - this time in the 4 blade OEM version:

The video above was recorded in the 4B_OEM. For the test, I had assigned xscenery/mu2b60/pilot_right_trim_switch_up xscenery/mu2b60/pilot_right_trim_switch_down xscenery/mu2b60/pilot_left_trim_switch_up xscenery/mu2b60/pilot_left_trim_switch_down to the left & right rocker switch on my yoke. With these I could trigger the animation of the switches, but could not trim the aircraft in flight. The separate A+B commands listed by Pils were ineffective (following your explanation that's correct) - they're indeed Laminar's default mapping for the rocker switches on the Honeycomb yoke, so if you could map them this would be really helpful (I'm fine with setting up those four commands). sim/flight_controls/pitch_trim_up sim/flight_controls/pitch_trim_down worked in a ground test, but did not change the data ref. I need to test in flight if they trim the aircraft for me (but that has to wait until tomorrow, it's getting dark on this side of the Atlantic )

Now I got it again, but I had to switch between the glass and oem version several times (6 or 7 times). If the crash occurs, it happens after 2022-07-16 19:40:36 G500[g500.cpp:113]: Disable PFD 2022-07-16 19:40:36 G500[g500.cpp:115]: Disable MFD and before this part appears: 2022-07-16 19:40:36 G500[g500.cpp:117]: Disable NavDraw 2022-07-16 19:40:36 G500[g500.cpp:119]: Disable Popup CB 2022-07-16 19:40:36 G500[g500.cpp:122]: Fini Airport List 2022-07-16 19:40:36 G500[g500.cpp:124]: Fini Nav Drawer 2022-07-16 19:40:36 G500[g500.cpp:129]: Fini MTU 2022-07-16 19:40:36 G500[g500.cpp:133]: Disable G500 Complete 2022-07-16 19:40:36 G500[Main.cpp:135]: Unregistering FLC - EF 2022-07-16 19:40:36 G500[config.cpp:282]: Destroying g500.cfg 2022-07-16 19:40:36 G500[config.cpp:282]: Destroying settings.cfg 2022-07-16 19:40:36 G500[config.cpp:282]: Destroying popups.cfg 2022-07-16 19:40:36 G500[Main.cpp:141]: XPluginDisable Complete 2022-07-16 19:40:36 OpenGPWS[xplane.c:279]: OpenGPWS stopped 2022-07-16 19:40:36 G500[Main.cpp:121]: XPluginStop 2022-07-16 19:40:36 G500[g500.cpp:89]: Stopping G500 2022-07-16 19:40:36 G500[Main.cpp:126]: XPluginStop Complete I got again the XP crash report, but no SegFault message from Windows this time. I don't think loading/unloading an aircraft multiple times in the same sim session is a valid use case, so I just leave the logs here in case Coop is bored enough to dig into this... Log.txt crash_report_07_16_2022_17_43_51.rpt telemetry_0.tlm

The panel mount object is visible in the 4 blade OEM version, but not the 5 blade glass version:

Quick update: I found the root cause - it only happens when the chocks are deployed. As soon as the chocks are removed, there's no issue with the data ref. Since flight reporting in FSE usually happens before chocks are applied, this is a non-issue and can be ignored.

I used a hardware switch on the Honeycomb Alpha, bound to xscenery/mu2b60/strobe_lts_on resp. xscenery/mu2b60/strobe_lts_off for the strobe lights. The switch on the OHP moves when I actuate the switch, so that seems to work. I shut down by using a rocker switch bound to xscenery/mu2b60/both_engines_RCS_stop. I tried to reproduce with the 4 blade OEM version, but was not lucky. My suspicion: maybe I switched them off exactly during a flash, in the moment the strobes were lit, deactivating the sequence, but not switching them back off after issuing their flash.

I'm used to using both switches simultaneously (I have a Honeycomb Alpha with dual rocker switch and several aircraft models with that same behavior), but in the case of the MU-2 the switch animation moves, but something is definitely wrong with the interaction between the switches and the trim system. holding both switches to the "down" position (i.e. mechanically up) animates both, the switches to move up and the the trim wheel to turn, but the data ref xscenery/mu2b60/manips/pitch_trim_tab_ratio remains unchanged holding both switches to the "up" position (i.e. mechanically down) animates the switches to move down, but has no other effect whatsoever (trim wheel doesn't move, data ref doesn't change). after having moved the trim wheel downwards with the rocker switch, touching it with the mouse makes it jump back to the position corresponding to what the data ref reads moving the trim wheel with the mouse to +1 or -1 activates the trim "up" light moving the trim wheel via mouse correctly manipulates the data ref (and consequently also pitches the nose up/down) reassigning the switches to XP's default A+B up/down animates the trim wheel correctly in both directions, but doesn't animate the rocker switches, and also doesn't change the data ref. the same happens when assigning only one hardware switch to the generic pitch trim up/down commands (though in this case the rocker switches are animated, as well as the trim wheel). Here's a video clip of the 4 blade OEM version showing this behavior:

Can't reproduce it. When moving out other plugins I noticed I still had 1.0.2 of the G500 installed. I upgraded to 1.1.0, and could not reproduce the CTD I had earlier. I can switch to a different aircraft (tested with the default C172), and I can shut down the sim without crash. Maybe this was due to *looks-up-excuse-in-bofh-calendar*

Observed in the 5 blade glass version. Not sure how to phrase this best - I switched off the strobe lights, and when I shut down the aircraft I noticed the strobe lights were not off, but constantly lit:

Observed with the 5 blade glass version: The animation of the trim rocker switches on the yoke is inverted (the up command lets them go down and vice versa). This is debatable, since mechanically they move "up" (into the down position), respectively "down" into the up position). The rocker switches are animated, but seem to have no functionality - trim can only be manipulated using the trim wheel. Does the MU-2 not have electric pitch trim, or is it just not wired up? Not sure there...

As the title says, when retracted, the MLG wheels clip through the fairings and the MLG doors (detected on 5 blade GLASS version):

Thank you Tom for bringing us this awesome new version of the Marquise. I'm toying around with it now for a couple of hours, and I simply love it. Had to leave this statement here so you don't think I'm just poking for bugs

The data ref sim/cockpit2/controls/parking_brake_ratio is used by FSEconomy (and probably other VA / ACARS clients) to determine whether a flight can be reported. Unfortunately, the MU-2's plugin seems to overwrite the data ref with every cycle, making it's value oscillate heavily between 0 and 1 (cf. video below): Also setting / releasing the parking brake seems to have no impact on the status of this data ref. To provide better compatibility with FSE and probably other flight tracking plugins, it would be nice to have this data ref reflecting the state of the MU's parking brake. Current behavior: after initialization of the aircraft, the data ref oscillates between 0 and 1 actuating the parking brake doesn't change it after tapping the wheel brakes with the parking brake released, the data ref stops oscillating and reads 0 while the parking brake lever moves, the data ref increases / decreases correctly with the parking brake set, the oscillation starts again with the parking brake released, the oscillation stops and the data ref reads 0 Behavior I hope for: data ref reads 1 if parking brake is set, and 0 if not set data ref increases / decreases while parking brake lever is in transition

The command xscenery/mu2b60/both_engines_RCS_stop is labelled as "shutdown right engine", while xscenery/mu2b60/right_engine_RCS_stop is labelled as "shutdown both engines". The commands work correctly, it's just the labels which are swapped between right and both (left is fine):