Jump to content

EnQ

Members
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

2 Neutral

About EnQ

  • Rank
    Member
  1. 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 interfa
  2. 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 late
  3. 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
  4. 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: l
  5. 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 exa
  6. 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 wi
  7. 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
  8. 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 (w
  9. 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.
  10. 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 alread
  11. I was also wondering how differences between sim weather injection and real-time weather affect the addon - I saw that a GFS download occurs and Saso also mentioned on last week's streams that the addon would know/figure out if it was parked in icy conditions over night (which is a very neat feature). It also raises some general questions about what happens if external data sources change, are being relocated or become unavailable (maybe after support for the addon ends) - it would be nice to have some kind of locally injecting/replacing the possibly missing or inaccurate data from outside the
  12. Unless bugs are involved, I actually like that the wheels behave this way if it's realistic. Maybe it would be a good idea to add "cheats" to the Challenger menu to quickly recover from common user mistakes that aren't as easy to figure out. For example there could be some "Realign Nose Gear (fix STEERING INOP)" item in a "Quick Help/Fix" submenu. Maintaining the educative style of this addon, this could be followed by a popup that explains the most probable cause why the situation occurred and how it should usually be fixed (plain text popup or maybe similar to the F/O checklist referenc
  13. Plugins which require keyboard input (such as FlightFactor's Airport Visual System AVS to enter airport ICAO codes) are blocked from receiving WASD key inputs while "Use WASD keys" option is enabled. Temporarily disabling that option makes the other plugins usable again. I looked through all commands and datarefs but the option does not seem to be controllable from outside the dialog. Use cases: If there was a command to toggle that function, it could be quickly enabled/disabled by a key/button press. If there was a dataref (readable and writable) it could also be control
  14. I had to fly a missed approach and pushed TO/GA on the throttle but did not advance the F/O Go-Around checklist. I repositioned for another approach and let the F/O start with the Before Landing checklist using the "check" command. The F/O started working and reading items from both checklists simultaneously, resulting in speed increase above flap limits. I "aborted" using the "restart all checklists" function from the menu and did not continue to use the F/O checklist function on that session. My expectation as a user would be that the F/O function is protected against simultaneous
  15. I'm not sure if it's really an issue with the Challenger itself but it's the first time I noticed that Windows 10 did an OOM kill. I tried to fly EDDF-LOWS yesterday, route: CINDY2L CINDY Z74 HAREM T104 WLD T702 OLETU DCT EBEDA L173 TITIG TITIG1R At a reproducible point on that route (between AMDID and TITIG, roughly 30 minutes enroute, during descend) Windows killed X-Plane as could be seen in the Windows Event Log (Windows Logs/System, source "Resource-Exhaustion-Detector", just after crash messages). It seems that Windows does not like to overcommit memory and exhausted the sum of
×
×
  • Create New...