EnQ

Unfortunately not yet; I didn't find enough time over the past months. In the meantime some manuals appeared online but I think none included detailed performance data so far.

It's hidden in the "Route Menu": Press the IDX key, enter the Route Menu, select FPLN Wind Update and press Send. Downloading the winds will take a while but eventually you will get a pending flightplan modification which adds all leg winds; confirm via exec and it's in.

TMP© just reminds you that you have temperature compensation applied. If you look at the regular legs page (not the direct-to page) you should also see a © behind every affected altitude. Seems like the direct-to page hides the "compensation character" (copyright, actually ). I'm not sure if that's correct; seems a bit weird that it's shown on one page but not the other?

While on local barometric pressure, the addon conveniently synchronizes left and right side settings using either baro knob. While on standard QNH a local barometric pressure can be pre-selected using the baro knobs, the pre-selected altimeter setting is displayed in white on the PFD. However, inconsistent to the behaviour while on local barometric pressure, the pre-selection is not synced between both sides, both sides can be set independently. When activating the pre-selected value by switching from standard QNH back to local pressure the active setting is synchronized again. I wonder if this is intentional or might be considered a bug. It seems more consistent to also sync the pre-selection between both sides.

Please correct me if I'm wrong but at least a few years back the saying was that you would need an Nvidia GeForce card with the proprietary drivers to have full support on Linux, AMD/ATI Radeon is not fully supported on Linux (and shows weird bugs on Windows as well). Personally, I always bought GeForce cards due to those known issues, so I can't tell if the situation maybe improved (but I don't remember having read any comments about improvements over the past years). I've recently read about other X-Plane addons having issues with 3D rendering on "AMD" as well, even on Windows (not sure if those reports referred to CPU-integrated graphics or dedicated GPUs), so maybe the issues are not even limited to Linux drivers.

That's expected and has been reported for some offline tools as well in other threads already. Actually, both issues (temperature effects/custom altimetry in general and the bug regarding broken synchronization to default datarefs) are not just about online services being incompatible but they are caused by the way the Challenger's altimeter (which is simulated separate from X-Plane) is being presented on X-Plane's datarefs. Those datarefs (basically a huge dictionary of simulation parameters and instrument readings) will currently hold unexpected values which can have an impact on any interfacing software (external tool, plugin or script). I think the emphasis on online services was only made because there it will not only be noticed by yourself but everyone around you as well, especially ATC (and thus affect other people which is always a bad thing and should be avoided). X-Plane 12 will introduce native support for temperature effects (see https://youtu.be/PfkG2osqVrY?t=606). I hope that the Challenger will be able to interface with that new XP12 feature correctly in the future. Once temperature effects have become a widely used standard feature (and do not require hacks any more) I expect all tools interfacing with X-Plane to be updated over time so they will eventually be able to read correct values again. The Challenger really is ahead of its time (not only regarding temperature effects).

I remember having completed building libacfutils and librain in a Docker container but I don't recall if I actually also put an .xpl file into an addon's plugin folder (it probably would have been the Zibo as it looks like librain can easily be swapped out). Arriving at that point already took at least a full afternoon (for the third time...) and while it was compiling I read deeper into the source code and found that the C code probably looks good already. There were at least 2 reports on Github and/or .org forums by other people who were faster and actually tested librain after the latest commits changing anything regarding Vulkan. According to those comments the plugin would successfully load into X-Plane but the effects were not displayed correctly. While the container was still building I looked into the shaders, got surprised about the complexity (as I said I have almost no clue about shaders) and stumbled across several websites trying to explain generic compatibility issues between shaders originally written for OpenGL and Vulkan. Unfortunately I could not find anything like a migration guide and everything just got more confusing the more I read. By the time the code finally finished compilation I just called it a day, the weekend was over and the next week XP12 got announced, so I simply abandoned the idea. As some private beta (developer beta?) appears to have started for XP12 in December (there's a protected release notes page in the knowledgebase) I doubt that it's worth spending any more effort on librain. I wasn't able to use librain for more than a year now so I can as well just wait for XP12.

From what I tested earlier today: Fuel can be injected (and withdrawn) by manipulating individual tanks through CL650/fuel/tank/mass[], it's just the default dataref for fuel that does not have any effect on the Challenger. Fuel will immediately start to distribute/equalize between linked tanks (nice to watch on the study panel). Depending on where FSE writes fuel values to it might be possible to transfer them to the correct datarefs using a script. sim/flightmodel/weight/m_fuel_total appears to give the correct readout, though. Payload weight can be set via sim/flightmodel/weight/m_fixed and CG can be modified via sim/flightmodel/misc/cgz_ref_to_default. Both these datarefs are the default ones, matching the Weight & Balance dialog sliders. I'm not entirely sure if that really affects the Challenger how it is supposed to but at least it did have an observable effect on ground.

Should it do anything else than just tune the frequency alone? I'm not sure if I'm doing something wrong (or if I'm just too impatient) but every time I've tried to fly an ILS approach on LNAV so far, the ILS did not seem to activate by itself although approach mode was armed. The frequency gets auto-tuned but I appear to need to manually switch the Nav Source. The course also always remains pre-selected at 0°, even after the ILS has already been auto-tuned. What I would have expected to happen from similar auto-tune functionality on other aircraft systems if I remember correctly: localizer course for the selected approach gets automatically entered into the localizer pre-selection window ILS identification is being displayed while still on LNAV (maybe I just did not find it on the displays?) localizer & glideslope indicators become visible when in range that sort of appears to happen if I change from LNAV to heading mode (blue bars?) if approach mode is armed, AP should switch automatically from LNAV to LOC & GS Maybe the Challenger's systems just work differently and don't do that? But I think it's more likely that I'm still doing something wrong or maybe I'm just still a bit lost on the displays. Would be good to have a confirmation if any of the points listed above are actually being performed by the Challenger and when/how that happens.

Alternatively, it should be possible to write a Lua script to help conducting test flights and record all needed data (plus a small tool to compute the values needed for PFPX from those data sets). I'm currently checking feasibility in respect to the time I personally have to not only come up with such a script but also perform all required flights (even with some degree of automation that's still quite time consuming). The Challenger isn't alone. It's just one more aircraft addon that has no or only inaccurate performance data in PFPX (my last purchases, iniBuilds A310 and Felis B742 have exactly the same issue), so I feel like (even when HotStart provides us with more detailed performance data) that's a reoccurring and quite annoying issue with most addons, so it would be good if there was some general (although time-consuming) solution. It's also probably best to wait for a few patches before starting such data collection as any tweak or bugfix to engine performance, FMS or autopilot behaviour may to some degree affect the collected data. The initial release probably isn't the best candidate to collect data from. While I have a lot of ideas I am missing the time to implement all of them (even in best case conducting the flights alone would probably take several days to complete). So do not take this as a promise that I will come up with something usable, at least not in the near future. After all, I still want to fly and enjoy the plane. Please let me know if you are aware of any previous (successful?) attempt to collect data from X-Plane this way or have a better idea. Edit: I've checked it and it seems to be feasible, even with the Challenger. It may even be possible to almost completely automate "piloting" the aircraft (although it would be very helpful to be able to trigger IRU realignment via a command as it's easy to knock out the INS by repositioning the aircraft). I still can't promise when (or if at all) I could have something ready, though.

I know that's cheating but maybe "Realignment IRUs Immediately" works? It sounds like that might happen in the real world as well. My wild guess is that one way (in the real world) would be to tow/taxi the plane to an area that's better protected from winds (e.g. into a hangar, maybe a runup area with blast shields would also be sufficient?). I've never tried if X-Plane simulates objects shielding from wind though (and it might just not do it, it's usually not important to simulate that), so maybe the "cheat" is the only option. As an afterthought... If X-Plane does not simulate wind shielding inside hangars etc. we can still control the winds within the simulation. So to simulate shielding from strong winds e.g. inside a hangar it would be possible to temporarily override the winds to be calm in ASXP and restore live weather after the alignment has finished.

If HotStart has such data and can share it, it would be helpful to have that larger dataset shipped with the addon or maybe just available here in the forums. It does not necessarily have to be converted into a ready-to-use PFPX profile by HotStart but unless the community gets access to such data (as a spreadsheet table, PDF, text file, whatever format) it's impossible for anybody to write such a file. I didn't try to feed the very short and limited dataset that currently comes with the documentation into a PFPX profile as (having seen tables from airliner FCOMs where performance data is provided on several pages) I suspect that data is way to limited to end up with some reasonable results in PFPX.

Is that confirmed? There were a few people on Github who managed to compile librain but that alone didn't seem to be enough. The last time I wanted to take a look if I can support in some way I actually managed to finally get it compiled (for some time libacfutils was a bit difficult to get working, that was already my third attempt). While everything was compiling (libacfutils takes a long time to prepare) I dug deeper into the source code and figured that it probably cannot be enough to just recompile everything as the shaders looked incompatible with Vulkan and looked non-trivial to port (which meant I would have to read deeper into 3D programming first). Just one week after that small success, X-Plane 12 had its reveal presentation and showcased weather effects and (if I remember correctly) giving credit to Saso for librain. I'm not sure if that means Saso also actively supported integrating the effects natively to XP12. At least it would have perfectly explained the silence on librain. The improved and native weather effects of XP12 are just around the corner, so I also immediately stopped pursuing any plans for maybe looking into it any further after that announcement (not worth the effort any more; it seemed I'd have to read so much about shader programming that XP12 is public when I might have finally achieved something). For the same reason I wouldn't expect any addon developer (including projects Saso is working on himself) to continue on librain. It's basically the same as for the weather radar (with what Laminar showed so far, my guess is that XP12 might drastically change weather-related APIs). Expecting that most users will switch to XP12 as soon as it is available, any effort put into what already is predictable to become just legacy support for XP11 now is basically a waste of time.

Maybe I am too much a developer myself as I am asking for use cases (and confirmation of my suspicions) as I identify feature requests. If "life is too short", why do you bother at all? I would simply fly at (real) daytime then, using real-time weather. Nothing to mess with, no issues at all. Problem solved with the easiest possible solution.

Care to explain why? I really don't get it but maybe it depends on the location where you want to fly. I may also be just too comfortable here in Central Europe. At least in Central Europe the weather is basically the same during day and night, it doesn't matter (in particular there's no real effect on winds, as far as I know). We also don't have extreme differences in temperatures (usually less than 10°C difference). But I understand that it can be more significant in other parts of the world... it may of course also pose issues to fly in polar climate where day temperatures are already very cold and night temperatures are so cold that they might make flying almost impossible (or at least impractical). But except for such "edge cases" (sorry if I really might have no clue about something here) I don't see how a time difference on weather data poses issues and becomes implausible.