amahran

Appears to be related to a post I submitted years ago: Please submit a ticket per this post here, so it can get dispositioned by the developers accordingly:

Planned fix log? Plans for deferred fixes to come in a future update?

Last I recall, I only got this message if I was trying to enter an invalid temperature (usually something too high for the altitude. It’s been a long while since I last flew it, but I feel I remember something about the units being finicky on the CRJ. Did you try adding “C” at the end? (Eg., “42C” as an entry to the flex temp)

I could contribute to this actually. The Flex function appears to have the following inputs: Field/Runway Elevation Flex temp requested by user. My guess is that the Max allowable entry is 50 degrees Celsius, minus 2 degrees per 1000' elevation. If you're seeing it rejecting the Flex Temp requested, I think it may have something to do with the field elevation. Did you try different airports? Did you make sure that the departure (and arrival) airports and runways are selected? Did you recently change your navigraph data? Perhaps the runway/field elevation data might be borked in the latest AIRAC cycle for the CRJ (I wouldn't know how to verify this).

I can give you that much; it is dissonant that the community spent years ragging on Hans to provide even a morsel of a hint of progress, and now that this morsel is given the same community is ragging on Hans for "an incomplete announcement". I can understand why Hans is apprehensive towards showing any teasers or proof of progress. That being said, I'm still disheartened by the fact that I didn't receive any acknowledgement on any feedback that I provided over the years. I'm still waiting for the formal announcement of the product changes before I rag on anyone.

I’ve provided multiple points of feedback on the CRJ, and the video doesn’t cover them. I can only assume there are far more changes coming than those listed in the video. As most people here have, I’ve been waiting for a long time. Once it comes out and gets pushed to the 2024 marketplace, I’ll give it a swirl. Until then, I’m not holding my breath for any changes.

This has been mentioned in multiple threads here, you can look around. In any case, there’s no way to solve the problem due to the way Hans wrote the CRJ autopilot. The workaround, however, is to reengage the autopilot at a lower speed (such as 200 knots).

The “A330 debacle” is taking 4 years to somehow deliver something that doesn’t meet the MVP of a flight sim addon by today’s standards and expectations. Vocalness or silence wouldn’t have changed the level of outrage the past few days at all If anything, it appears that the consensus in the community is that the CRJ is trending the same way: 2 years of no updates, no statements other than some vague “inshallah”s, and the A330 that came out after those past two years exhibit the same problems as the CRJ, albeit with even further regressions. If you wanna keep hoping, be my guest. I’ve already made my peace with the fact that no progress will ever be made if Hans has no progress to show for it or even any engagement in a snag investigation after over two years.

Short answer: For 2D, Yes it works and is usable on VATSIM, but don't expect consistent behavior. For VR headsets, some dials are unusable, rendering the plane unflyable unless you're handflying the whole way. Long answer: It works under specific conditions (specific types of approaches, specific types of flightplans, specific autopilot modes, etc.). Outside of those, the behavior can be unpredictable. It depends on your comfort level with unknowns (including system nuances that are not representative of the real thing and cause more workload). The control logic for the dials on the FCP and the Baro set knobs are also incredibly inefficient to use, and not usable in VR at all with a mouse. Overall, the biggest gripes are: FMS logic is unpredictable under certain situations Vertical guidance (VNAV/Snowflake) is misleading or erroneous under anything more than the simplest VNAV calculations Autoflight logic and control laws need a lot of reworking: premature turns, snaking, sudden trim jumps on AP reconnects, vertical mode during approaches are unpredictable and cause a lot of workload. FADEC responsiveness is slow and too loose, causing N1 overshoots (inconsequential, but grating). Then there's the "state of the art" issue: when the CRJ came out it was at its peak in terms of quality and features, which set it apart from anything from the FSX days. However, lots of devs have surpassed that benchmark since then with features that are above and beyond (see PMDG, Inibuilds, JustFlight, Carenado, Fenix-even-though-it-works-in-its-own-external-environment), which makes the CRJ in its current form really barebones (you get W&B control and some EFB options, but that's it). The CRJ is really overdue for a makeover that would bring it back in line with the rest of the products on the market. Overall, however, it's useable on VATSIM if you're willing to accept some oddities here and there, and that there's a higher workload associated with dealing with those oddities that you don't see on the real aircraft.

I'm not sure we ran the same test case. In any case, I tried doing the same thing over here, and have the video recording with my narration of what I'm doing step by step (all the way from flight initialization to the demonstration of the problem, no cuts):

That’s a good catch. I always felt there was something weird going on with the altitude capture logic when you change the alt sel and that it was causing more workload than should be necessary, but I couldn’t quite put my finger on what was happening. Nice summary of the problem!

I did an analysis a few years ago in this forum, and found that there will be a sudden jump in trim setting if you disconnect the autopilot at one airspeed, speed up, retrim, and reconnect the autopilot. On all autopilot engagements excluding the first time, the autopilot will instantaneously set the elevator trim to the last setting the autopilot remembers from its last disconnect, and slowly work it back to the correct value. At least that was the case 2 years ago.

Where was that announced? I'm curious to read more

I’m glad to hear my posts are actually appreciated by users here. But I don’t think I’ll ever get an answer from Aerosoft. My question to @Hans Hartmannor @Mathijs Kokstill stands, is my involvement in active bug reporting still even desired, or should I stop trying and contribute to another developer instead? Either tell me you want me here, or tell me you don’t. What the hell are the forums mods here hired to do? Pat themselves on the back for locking a thread every time a user answers their own question?

Wow I really kicked the hornet’s nest with my post… As @CRJaymentioned, we don’t get any acknowledgment on anything we post. At some point, Aerosoft was actively doing so, and @JRBarrettwas actively engaging and letting people know when root causes were found. This behavior disappeared for no reason and we’re back to being left in the dark. May I recommend Aerosoft actively acknowledge and aid their customers (instead of doing that thing when community managers only engage in threads once the OP solves their own issue to tell them that they could have read the manual, which seems very much less like community support and more like community criticism?) And do you actually want bug reports or not? Because I’ve been documenting everything meticulously, but if Aerosoft is signaling that my effort is a waste of time by simply not acknowledging anything I’m reporting, I can go back to lurking and let this forum go back to being as quiet and inactive as the Twin Otter support forum. This crap takes time and makes my simming evenings take twice as long as they normally would be, and if my effort is wasted here, I’d rather do this whole reporting and feedback with a different aircraft, and help a developer that makes me feel like my time is well-spent. Ball’s in your court.