daemotron

When playing around with the RXP GNS units, I noticed that there is indeed a distinction with regards to electrical buses. The 530 (primary unit) is hooked to Bus #1, the 430 (secondary unit) to Bus #2. Now the quirk: The GPU powers only Bus #1, while the battery powers both buses: The RXP units allow to be hooked up to one of 8 different buses (the default avionics and battery bus plus one of the 6 custom buses): The MU-2 uses three of X-Plane's buses (not sure what Tom's code does in addition to that, so there might be more): This would (theoretically) leave 3 potential "spare" buses (understood by the RXP units) which could be used to fake a set of dedicated radio buses for the RXP units - I guess that would require some custom plugin-driven logic (to link bus power to the radio switches), so probably a lot of effort for little effect (in the end, it's just RXPs turn on/off with battery vs. RXP units turn on/off with radio switches).

Hi Tom, I know you're fairly busy atm with IXEG stuff, so just leaving this note for once you get bored again When flying at night, the light emitted by the overhead switches is really bright - bright enough to light up the cabin and cockpit. Would it be possible to dim them when the IND LTS DIM switch is active, or alternatively hook them to the OHP lighting rheostat? Or is this a MU-ism and they indeed blind you when active at night?

Oh dear, there you got me into a corner where I never wanted to be in. Back then when the upgrade was announced I said I would buy it once it really brings the fixes I've been waiting for (most notably the FMS). But I'll certainly not pay the full price again, so I can now only chose between biting the bullet and paying for a promise (with not too much confidence it will be delivered this time tbh), or scrapping the 733 for good.

Hi Tom, not sure this really is an issue, or just a "moo-ism", but I noticed the HSI's course display gets blank for 0°/360° - all other digits show up: 1° - shows perfectly 0° - display goes blank 359° - shows perfectly

I'm currently ferrying N279MA (my Moo in FSEconomy) from Europe to Alaska. A few days ago I left Pescara, Italy (LIBP), where I picked up this airframe. Instead of using the well-trodden westbound route via Iceland, I started moving eastwards, heading for Split, Croatia (LDSP), the Abu Suwayr Air Base, Egypt (HE35, close to Ismailia), Abu Dhabi, UAE, Karachi, Pakistan, and on to the Lucknow Air Force Station, India (VIBL). From there, today's leg took me towards Nepal and the Himalaya mountains, to Pokhara. There I landed at the old downtown airport Pokhara (VNPK), not the newer and bigger Pokhara International (VNPR - not in Skyvector for unknown reason). Approaching runway 22 (all VFR, there are no published IAPs for this airport, although there's a VOR on site): After landing, shortly before exiting the runway: The next legs will take me to Kathmandu and probably Paro (can't miss that while being in the area). Not sure what I'll be doing from there on - either taking a "shortcut" through China and Russia up to Anadyr, jumping to Point Barrow from there, or going south, dawdling around Thailand, Indonesia, maybe even Australia and the moving northwards via Japan. Let's see where the FSE assignments take me

I noticed the beacon light on top of the vertical stabilizer is only visible from rear angles, not from the front. I made a short video to demonstrate this, moving the camera past a certain point makes the beacon appear lit: Checking some stock video footage of real Moos, it seems the beacon light should be visible from all angles: I noticed this with the 5 blade GNS version; I didn't check the other variants though.

I wouldn't say the transition from 9 to 10 or 10 to 11 was smoother than the transition from 11 to 12. In all these transitions, the closer an aircraft model was built with Laminar's tools alone (i.e. PlaneMaker), the transition was easier to accomplish than for aircraft with loads of custom stuff - but easier doesn't mean as easy as just saving the acf file in the new planemaker version. With each major release (and many minor releases, too), Austin has modified the flight physics, or the engine model. So even for "barebone" planemaker aircraft models, that meant and means many hours of testing and tweaking parameters, until you have beaten the physics back into submission. If you add more complexity (custom logic coded into plugins, or beautiful 3d and textures), there are these aspects as well that you need to take care of. I have no proof for my theory, but my assumption is that at the end of X-Plane 11, most payware aircraft models were far more complex than they were at the end of X-Plane 10. Towards the end of XP10, plugins were mainly used by highly sophisticated aircraft models and airliners, many small GA aircraft were built without plugins (or using simple, standard stuff like a scroll wheel plugin). Nearly all use custom plugin logic these days, and sophisticated 3d and texturing is a must have as well. For us pilots, this is great, because it means we get better, more realistic aircraft models to fly and study, bringing out their best (and worst). A Piper not only looks differently to a Cessna, it also perceptibly flies differently to one. We have options to get different instrument panels and avionics, we get EFBs and load managers, etc. However there's a price tag on all these great features: developers have not only to re-adjust flight physics and engine behaviour, but also rework their textures (to adapt to the new lighting engine) and rework their custom plugins to adapt to SDK changes. At the end of XP 10's life cycle, the technical challenge was similar - Laminar introduced a new lighting model (PBR), which forced developers to redo all their texture work. The engine model didn't change with 11.00, but (iirc) with 11.10 - suddenly a lot of aircraft using the free shaft turboprop engine model burst into flames when you tried starting the engine(s). Also early in the 11 release cycle Laminar released a new SDK, introducing a bag full of changes. Basically things were similar like now - a lot of changes came with the first release, but quite a few changes didn't make it, and were introduced later in minor releases (anyone remembers the debate about prop wash and taildraggers...?). However, the total available fleet of payware aircraft was significantly smaller back then, and it was again a lot smaller when XP10 saw its first release. My view on all this: X-Plane evolves with every minor and major release, and this is a good thing (much better than a "dead" platform anyway, though I can see that it would be beneficial for third party developers if those changes came in a more predictable and structured fashion). Just look how far X-Plane has evolved in the past 10 years; it's really amazing. In the same time, pay- and freeware aircraft also evolved significantly, becoming more and more complex, offering more and more features. This definitely is a huge challenge for third-party developers though, constantly forcing them to evolve, too. So it's only fair if they use the major release steps as time markers to ask for an upgrade fee - supporting a product throughout an X-Plane major release usually means adapting a couple of times to improvements and shenanigans Austin is coming up with, eating up precious development time that would otherwise never be compensated by corresponding revenues.

The Lycoming IO360 powering most Arrows should be either flown ROP (Power Cruise) or at peak EGT (Economy Cruise). Leaning is done based on EGT, not CHT - but a CHT gauge can help preventing exceeding max CHT. Flying it lean of peak is an "off-label" use. For reference: here's an Arrow POH: http://www.jasonblair.net/wp-content/uploads/2015/11/Piper-Arrow-PA28R-201.pdf and here the IO-360 operating manual: https://www.lycoming.com/sites/default/files/attachments/O-HO-IO-HIO-AIO%20%26%20TIO-360%20Oper%20Manual%2060297-12.pdf

I wish someone made a PC-12 with deep systems and great visuals. I don't necessarily need the NGX with Honeywell's Primus Apex avionics; the older NG with EFIS, EHSI and GNS will do as well. Heck, I even found this cockpit, and we actually do have all the ingredients available: G500, GTNs...

Over the past ~6 years I logged over 10,000 flights there. Does that make me an addict...? It's a cool platform, but it's hard to resist the drag towards buying the next, bigger aircraft to make more money (so you can afford the next, even bigger aircraft...).

The last I saw was a post of the developer on Discord on April 14, showing a screenshot of the Sundowner cockpit equipped with a G500. I'm not sure whether LES plans to release the DC-3 first, and then the update for the C23, or vice versa.

The reason in this case probably really is that the Sundowner hasn't been updated to X-Plane 12 yet.

A lot of airstrips on the gateway are still "2D" from the time when the gateway was created - which means they have a runway roughly placed based on airport meta data, but no taxiway network, markings or buildings. Whether Google maps has this info or not is irrelevant; as long as no human has laid hand on these sceneries, they're really bare-bone. If done right with a recent version of WED, re-exporting the xml file into an XP12 format shouldn't be that big of an issue. Libraries could, if you use some really old stuff (particularly when vegetation or ground polygons such as asphalt or concrete are sourced from libraries). If you only source 3D objects from libraries, they'll mostly be ok (might not have the best textures then). Some wide-spread libraries (e.g. MisterX6) were already updated. The only aspect that might have to be re-done (due to different behaviour between XP11 and XP12) are the airport boundaries. Sceneries made with WED 2.4 and earlier might need a bit more rework, due to the changes in map projection. The WED main developer has summarized all the more or less subtle differences in a nice write-up - and another one worth reading.

On and off commands for the GPU already exist, I have bound then to a switch. Not at my computer right now, but I think it's connect_gpu and disconnect_gpu

I'd second a native re-development which doesn't resort to Garmin's trainers - like the G5 and G500 by RSG. This would solve the issue with outdated nav data and missing cross-platform availability.

The Moo only uses Gizmo (unless you also use the G500, which is a plugin of its own).

So far I only used Gimp and Affinity for livery painting. I'd be interested in learning about the Blender method, particularly if it helps better & easier aligning stuff.

Hey Tom, this is excellent news, thank you very much! I'm so much looking forward to Moo-ing in X-Plane 12!

JustFlight has just updated the Duchess, and the two Archer packages - together with the Robin DR400, C152 and the TB10/TB20 package, that makes a total of 6 packages updated to XP12 on their end. Although nothing official was announced, that only leaves the Warrior and the two Arrow packages for the next batch, before they turn towards the Hawk, Vulcan and finally the Jumbolino.

Ah, that init.lua lives inside the xlua folder within the default C172's plugin folder. Should be the same on all X-Plane installations.

I tend to think the same - it went away by hitting clear & reboot. Cameron, regarding your question - just a one off, coming out of the blue. I hadn't installed anything; I even had X-Plane run a couple of minutes before (I was just fiddling with ordering stuff in scenery.ini). Oh, and I found a way to reproduce it: start X-Plane into the main menu select the default C172 and an airport to spawn into hit "start flight", and when you see "loading Aircraft\Laminar Research\Cessna 172 SP\Cessna_172SP.acf..." pull the network plug Apparently Gizmo in this version doesn't like losing its network connection while executing OnFirstFrame. I have attached another log.txt where I was able to reproduce it with the steps described above; you can see where it lost network connection (Laminar is protesting about it as well). Log.txt

Hm, if you have it completely custom, one option could be to use one of the two avionics switches to also power e.g. the standard avionics bus, without touching the rest of your own bus tie logic code (not sure if I'm too naive there, never tinkered with XP's electric buses).

Never had this before, might be a server-side or network issue: I got this by simply starting X-Plane and loading the default Cessna 172. Log.txt

I think it largely depends on what you started with. Someone who "grep up" on an Airbus-style cockpit will have a hell of a time transitioning to a Boeing. Both follow different philosophies, and if you stick with the one you learned first, the second one will always appear non-intuitive. I daresay it may also play a role if a pilot choses to transition from one type to another, or whether company policy forced them to go through a new type rating. I know a couple of pilots holding type ratings for both sides, but depending on their personal preference, they will tell you "Boeing is better!!!1!11!" or "Airbus is better!!!111!!!1!".

@Coop I noticed the same two settings are also not applied in the G500 Skyhawk. Does it need the same changes as the G5 one? (CDI DTK and Autopilot)