skiselkov

Interesting. I wonder how they're measuring it. Wonder if it's some local magnetic disturbance that's not captured in the world magnetic model database.

Just for completeness, here's the magnetic variation computed for the exact location of the VOR/DME (not that a mile or two would make difference, but just in case there are questions):

I had a look at this and it doesn't appear to be a bug or badly implemented track indicator. What you are seeing is the accurate magnetic ground track donut. The problem appears to be that the database-provided magnetic variation for the Pine Bluff VOR/DME is incorrect. You are quite correct that the databases say it's 4°E. However, and here's a funny one: the Pine Bluff airport near to the VOR/DME is is declared as 2°E: Now, as to how the airplane knows its magnetic heading - the IRSes contain a magnetic variation database, which is valid from 2020 through to 2025. The IRS feeds the current date + position and this database computes the actual magnetic variation expected at that position and that's what you're seeing on your avionics. And here's the kicker: the magnetic variation database says the actual magnetic variation should be around 0.3°WEST: Similar results using the IGRF magnetic model: You can run the computations for select positions yourself here: https://www.ngdc.noaa.gov/geomag/calculators/magcalc.shtml Investigating enroute charts, there's a 3 degree declination change over the span of a mere 65 miles. This seem to suggest that the Pine Bluff VOR/DME is misaligned and needs to be realigned IRL: To summarize: doesn't look like a bug to me. Seems more like either the navaid is misaligned IRL, or the navigational database needs to be updated.

Implemented, will ship in update 1.5

To edit the appearance, you need to load into the airframe. You are currently in non-persistent mode, so the airframe you have showing there isn't currently loaded. Simply select the "FLY" button and then once the airframe is loaded, you will be able to edit the appearance.

Hey Jean-Luc. Please check breaker CBP-1 K1 and make sure it isn't pulled out.

Your anti-virus software is acting up: F:\X-Plane 11/Aircraft/X-Aviation/CL650/plugins/systems/win_x64/systems.xpl : Error Code = 225 : Operation did not complete successfully because the file contains a virus or potentially unwanted software. That's what's causing this. Please filter out the X-Plane folder from the A/V software's scan areas.

That's not an error, that's how a Collins FMS draws a flyover waypoint.

In the Challenger v1.4 we're introducing a new capability for the THRUST LIMIT page - selecting either derated (FLEX) or maximum (MTO) takeoff modes. Please see the attached PDF for a description how to set these up. CL650_FLEX_MTO.pdf

This is just rounding noise from the aux system. During refueling, the forward and aft aux tanks get filled first due to refueling ejectors picking up fuel from the center aux. Then when you remove refueling pressure, the fuel sloshes back to the center aux under gravity. This can manifest as summing noise on the total fuel value in here. Basically, don't worry about it.

I'm not really sure this is one of ours. This appears to be somewhere deep inside FMod, which we don't control. Probably best to report this to Laminar.

Thank you for the excellent report and the FMS file. Made it trivial to figure out why it wasn't working. Fix will be included in V1.3 update.

Please always post a Log.txt with your report.

I've added a new method of random number generation in V1.3.

Fixed.

Left side should be available on battery, not right side though. Fix incoming.

Manual is wrong here, system 3 hydraulic indicators are on the 28VDC battery bus.

Confirmed, the fix for #2508 addresses this as well. However, I've added more hardening against zero-length DF legs causing issues.

Isolating plugins won't be necessary in this case. The issue is somewhere in the FMS code ,just trying to determine if it's been fixed already or it's something new.

UPDATE! Apologies for closing this one apparently prematurely. I got a few more reports of this and started investigating deeper. There was indeed a memory leak that was consuming memory continuously, at a rate of roughly 400 MB/hr. So after 10 hours, it would have consumed 4000 MB. If you were doing a long multi-sector flight on a machine with 16GB or less of memory, or perhaps left the sim open overnight, this was most likely an issue of out-of-memory crashes. Anyway, fixed in update 1.3. Apologies again for prematurely closing this issue.

UPDATE! Apologies for closing this one apparently prematurely. I got a few more reports of this and started investigating deeper. There was indeed a memory leak that was consuming memory continuously, at a rate of roughly 400 MB/hr. So after 10 hours, it would have consumed 4000 MB. If you were doing a long multi-sector flight on a machine with 16GB or less of memory, or perhaps left the sim open overnight, this was most likely an issue of out-of-memory crashes. Anyway, fixed in update 1.3. Apologies again for prematurely closing this issue.

Update to 1.2 and retest. Should be fixed.

The underlying cause - a bad route specification - cannot be fixed. Simbrief simply constructed an invalid route here. It marked the route as going from BJA VOR via A411 to ANB VOR. That is not correct, airway A411 doesn't contain BJA VOR. It contains BJA NDB, which is a close (but not identical) navaid. Consequently, the route parse fails, as the database object referenced is simply the wrong one.

Solved, fix will be in update 2.