Leaderboard

that was poorly worded, sorry. "I have already put it in place in my development work, so as to be part of a future update for V12" It is not in place in the currently available version. With X-Plane's RC4, released today, I think X-Plane is in a good place to resume Moo tweaks. I'll probably release updates in two stages. 1) Visual changes, i.e. the rain effects and tweaked lighting...which just looks nicer. 2) Flight model refinement. I separate out the flight model refinement because it performs reasonably well in XP12 and most users, (me included) enjoy the more visual and sensory aspects of simming rather than 'by the numbers', i.e "we put in gas....we fly....make sure no needled go red, and enjoy the ride" Chasing numbers always involves more in depth tweaks, longer testing period, and frustrations fighting X-Plane's default models and I don't want to withold some of the cooler XP12 visual features while flight testing/refinement takes place. -tkyler

Its already in place. you can see it in THIS VIDEO. (if the link is working...seems to be down atm)....anyhow, the effect is a bit exaggerated for testing purposes. I may put in a preference that lets you set how "much" rain you want on the windshield...its pretty subjective on how much rain one expect to see on the glass for a given level of rain. -tkyler

Got this brand new puppy (Elgato Stream Deck +) based on the notion that I could use the rotating knobs for HDG, SPEED, ALT SEL and BARO, as well as range. Just like in the real airplane, the knobs rotate with a ratcheting feel. It's no problem at all mapping the rotaries to the appropriate keypresses. First assign key sequences to the relevant CL650 FCP 'commands', then assign the same key sequences to the clockwise and counterclockwise actions for a knob in the StreamDeck software. With the mapping I did, every notch of clockwise or counterclockwise rotation of a knob corresponds to a 'HDG knob up' or 'HDG knob down' keypress. I did same for ASEL, SPEED and other knobs. There is an issue, and it's either on the Xplane side of things or with the Stream Deck software. When I turn the knob at a "normal" rate, i.e. same as I would turn it in the real aircraft, there is a noticeable lag in movement of the heading bug. It appears to me that the keypresses are sent repeatedly at a fixed rate, which is too slow. As a consequence, the heading bug keeps moving even when I stop rotating the knob, until all the "rotary knob" keypresses have been absorbed by XPlane. A further side effect is that reaction to any presses of the actual keyboard is delayed, again until all the "rotary knob" keypresses have been absorbed by XPlane. I looked around the StreamDeck SDK documentation, and these made me think that the StreamDeck software, out-of-the-box, sends not only a key-down but also a key-up command for every notch of wheel rotation, which further increases XPlane's workload. The solution most likely lies in writing a plugin for the StreamDeck software or or for XPlane - both of which are possible, but beyond my abilities - . But just on a hunch, I am posting this here as well, perhaps the HotStart folks have an idea on how else this could be done? (Note: as of this writing, the folks at Elgato have not yet updated the SDK API for the rotary knobs, so a solution might be forthcoming from their side.) As is, what I have done is still usable, but you mustn't be in too much of a rush when turning the knobs. The StreamDeck+ seems almost born for fsim use. The knobs are also have a momentary push function, just like the FCP knobs. So if you push the HDG knob, I have mapped it to sync the heading bug to the current heading - exactly like the real knob. And it gets even better: You can map 2 different actions to a knob push. In the picture, you can see that my leftmost knob is mapped to change the DCP1 range. But if I give it one push, then the mapping changes to PITCH/VS wheel up/down. Another neat thing is that the StreamDeck + has a touchscreen just above the rotaries, and can detect left and right swipes, allowing me to swipe to a second page of mappings. On my second page, I have a rotary set up for setting the BARO QNH/altimeter setting, with a knob push mapped to toggle between STD and preselected QNH. It's just great!! And on my third page I have the 10th stage bleed buttons mapped, so it is totally easy to transition from APU to engine bleed source and back. I'll also setup anti-ice controls when I have a chance, and then figure out how to post the mapping profile here - that is also possible. I don't know how many pages of mappings you can have, but I'm at 4 pages so far and it is still offering me the option of adding more. Final detail: you can download the StreamDeck software even if you don't have the hardware, which allows you to see how easy it is to configure. I am totally impressed with what Elgato have come up with here. And full disclosure, I have no connection to them whatsoever. Cheers LC

Licensing is done per physical machine, so no special action is required to use X-Aviation products with X-Plane 11 and 12 on the same PC. Just sign into Gizmo for each sim as normal.

So just an FYI update. I've been working on IXEG stuffs while Laminar tweaks the Release Candidates. I've held off updating the Moo further yet because 1)....I've worked for Laminar...and I know the kinds of changes that can be made in the early RC runs and 2)...it actually runs tolerably in V12. Once Laminar and most devs are suitably confident the lighting settings are stabilized or close to final, I'll turn some focus back to the Moo to see where things stand and what needs attention. The lack of liveries isn't lost on me, I know its a tough UV layout. That will get addressed in some fashion also. -tkyler

Early work-in-progress...but eh....why not...could be fun. Just don't answer the phone if it rings after watching this video. exhaust_opt2.mp4

Hi Javelin, Excellent research. The August 2019 Jeppesen Briefing Bulletin is attached below for the benefit of others. Pardon the extensive highlighting. Bad habit of mine. Here's my take on it. Referring to the following document: Annex to ED Decision 2012/018/R: AMC4 CAT.OP.MPA.110 Aerodrome operating minima CRITERIA FOR ESTABLISHING RVR/CMV (a) Aeroplanes The following criteria for establishing RVR/CMV should apply: (1) In order to qualify for the lowest allowable values of RVR/CMV specified in Table 6.A the instrument approach should meet at least the following facility specifications and associated conditions: (i) Instrument approaches with designated vertical profile up to and including 4.5° for category A and B aeroplanes, or 3.77° for category C and D aeroplanes where the facilities are: (A) ILS / microwave landing system (MLS) / GBAS landing system (GLS) / precision approach radar (PAR); or (B) APV; and where the final approach track is offset by not more than 15° for category A and B aeroplanes or by not more than 5° for category C and D aeroplanes. (ii) Instrument approach operations flown using the CDFA technique with a nominal vertical profile, up to and including 4.5° for category A and B aeroplanes, or 3.77° for category C and D aeroplanes, where the facilities are NDB, NDB/DME, VOR, VOR/DME, LOC, LOC/DME, VDF, SRA or GNSS/LNAV, with a final approach segment of at least 3 NM, which also fulfil the following criteria: (A) the final approach track is offset by not more than 15° for category A and B aeroplanes or by not more than 5° for category C and D aeroplanes; (B) the final approach fix (FAF) or another appropriate fix where descent is initiated is available, or distance to threshold (THR) is available by flight management system / GNSS (FMS/GNSS) or DME; and (C) if the missed approach point (MAPt) is determined by timing, the distance from FAF or another appropriate fix to THR is ≤ 8 NM. (iii) Instrument approaches where the facilities are NDB, NDB/DME, VOR, VOR/DME, LOC, LOC/DME, VDF, SRA or GNSS/LNAV, not fulfilling the criteria in (a)(1)(ii), or with an MDH ≥ 1 200 ft To use Table 6A, for a NPA approach CDFA techniques must be used. Table 6A is attached below. From Table 6A at the bottom: For NDB, NDB/DME, VOR, VOR/DME, LOC, LOC/DME, VDF, SRA, GNSS/LNAV: - not fulfilling the criteria in in AMC4 CAT.OP.MPA.110, (a)(1)(ii), or - with a DH or MDH ≥1 200 ft Min 1 000 1 000 1 200 1 200 Max According to Table 5 if flown using the CDFA technique, otherwise an add-on of 200 m for Category A and B aeroplanes and 400 m for Category C and D aeroplanes applies to the values in Table 5 but not to result in a value exceeding 5 000 m. Since paragraph (a)(1)(ii) states "Instrument approach operations flown using the CDFA technique", if you do not use CDFA technique even on these approaches where the vertical path falls within the maximum values specified, there is a 200 m (CAT A & B ) or 400 m (CAT C & D) applied. I can see where it might be interpreted the other way as well. That's what makes this so dang confusing. When I see CDFA on the approach, I interpret that to mean that I need to use CDFA on that approach. As US based operator, we do not use the State charts or the AIP. We rely on Jeppesen to figure this out for us, which is the value added service of using a provider like Jeppesen or LIDO. They provide standardized format regardless of where you fly in the world. To be honest, the who concept of AOM has been confusing as hell to US operators. We don't have to worry about this in the US because US TERPS defines the visibility minimums for every approach based on runway/approach lighting, obstructions in the visual segment, the published MDA or DA, etc. They apply to all operators. That said, back in 2010 or so, there was a change in US TERPS to allow the promulgation of visibility minima in 1/8 SM increments specifically to support the ICAO SARPS and EASA rules supporting CDFA. A European operator flying a US non-precision approach to a MDA and not using CDRA would have to increase the published landing minima for the approach by 1/8 SM for CAT A and CAT B aircraft, and by 1/4 SM for CAT C and CAT D aircraft. That's why we see approaches in the US with strange visibility minima like 7/8 SM or 1 3/8 SM. We never used to do that. Because US operators had to apply CDFA in Europe and other ICAO States that adopted the Annex 6 SARP, the FAA published AC 120-108 providing operator guidance on the application of CDFA. CDFA can be used voluntarily in the US. It's not required. You've piqued my curiosity. I may need to do further research. It's been a while since I have looked at the EASA operating rules. Thanks, Rich Briefing-Bulletin-JEP-15-A-Announcement-AOM-Concept-23-AUG-19 (002).pdf AC 120-108 Continuous Descent Final Approach.pdf 1065467017_AnnextoEDDecision2012-018-R.pdf