amahran

Which one, the wheels or amphibious? What altitude and temps? Either way, max cruise is technically 50PSI torque and 92% Np (at least for the -300). Anything below that is acceptable and flyable; you just get more documented performance results at those specific torque and prop settings in the manual. Things that may drop you out of the sky: - Temps too high in cruise (like +30 or something ridiculous) - Ice accumulation - Forgot to retract flaps - Waaaay overweight

I did. Strange that I'm not seeing the behavior that was posted in the video above; I'll try to duplicate it again when I have the time.

That's actually a pretty good catch; I never realized how slow the N1 was to set until I watched those videos. Come to think of it, since the CRJ turbofans are really small, they should generally be able to approach steady state much faster than larger turbofans (e.g., those on an A340 or 747)

But if you press the Chime button...you still hear a "ding", right? Even if it's not part of the SOP? Or are airlines disconnecting that button from providing any signal?

Correct; if you use the FLX TEMP selection in the VNAV page, confirm the magenta Flex TO rating on the left CAS screen (where the N1s are), and proceed to take off, you will observe that the actual thrust achieved by the engines exceeds the magenta target (usually by ~5% N1). I'm not sure if it's the FADEC causing an overshoot in an attempt to stabilize at that N1 targe, or if the FADEC is actually intentionally trying to achieve a higher N1 target.

The steering tiller for the nosewheel moves when you use the foot-rudder. It does not respond when you use the nosewheel steering axis. The aircraft steers normally, nonetheless. My uneducated guess is that the 3D model of the animation of the steering tiller is linked to the wrong axis. EDIT: This is the latest CRJ Version on the Marketplace, on SU10 Beta.

It's impractical in VR; you have to right click with a head position, wait for your head to reset, and then hope that your mouse highlights the middle button. If it doesn't, adjust head position and try again. This is a nuisance in VR; the inability to click on the middle button for the concentric button-type controls (e.g., Baro set, MCP buttons, etc.) makes it really difficult to fly this aircraft in VR, especially on VATSIM.

Bro they never made an A330 for FSX

A few months ago, I had posted something to air my disappointment with the lack of communication from Aerosoft on what’s going on with the CRJ. This post is definitely a step in the right direction. I appreciate the openness and honesty, and I’m certain many people in the community can breathe a sigh of relief knowing that their spent money isn’t wasted. Looking forward to the update when it’s ready. Remember, quality >>> hitting the target date on the nose

I'll have to say likewise; I got the Twin Otter almost instantly on release without giving it time to hear about the sounds. And yeah, I've shelved it; it's a painful airplane to fly until those sounds come in.

Seeing what the changelog being pushed to the testers now is nice, so at least we get a bit of a sense of movement. However, would it be possible for Aerosoft/Digital Aviation/Hans to at least show us a list of “Known Issues”, and their associated state (e.g., logged, investigating, root cause identified, etc.)? I think that would be much more valuable than seeing only the things that Aerosoft/DA are certainly acting on. To me, for example, knowing that Aerosoft knows about the TCAS draw distance issue and has logged it in a table is comforting, even if there’s no guarantee the fix will be provided in the next update. Just seeing acknowledgment of the issues I need and knowing that Aerosoft certainly knows they exist is what I’m hoping for. (And no, not saying “we’ll look at it” in response to a forum post; that’s not adequate communication imho)

Should fade with increase in Mach number, shouldn't it? Because the cockpit is ahead of the engines, at Mach 0.8, the sound of the engines has to travel 5 times the distance to make it to the cockpit. At that point, the ambient air travelling over the cockpit structure becomes the more dominant sound...which is generally much quieter because the air is less dense?

Agreed, please stop attacking each other; I want the devs to actually respond to this constructively and for a firm resolution to be reached on the product's level, not for this thread to turn into another shit-flinging contest that gets padlocked and the discussion gets disregarded and thrown away for god-knows-how-long before another thread gets opened up again. I'm not sure why some people report this issue and others don't. I personally have never seen the back-and-forth threading of the route except in most exceptional circumstances (e.g., waypoints too closely located), so clearly it varies from user to user (which may explain how this got past Aerosoft's QA into the retail version). I have friends who have adamantly complained and shown it to be 100% repeatable. Possible causes may be: Airspeed: I fly at Mach 0.78, maybe the PID is tuned well for that, and not for lower airspeeds? Leg type: This is less likely, but maybe the flight direction doesn't know how to track certain leg types (e.g., DF, CF, etc.). Not sure how the nav data is coded, but maybe the wrong leg type is put in accidentally in the route in some use cases? Perhaps the FMS/FMS/MCDU/whateveritscalled experiences a bug in a very specific use case that causes every leg to be a TF (Track-To-Fix) with a value of 000 degrees, I have no idea I'm not a software developer. Groundspeed: I notice in one of the videos posted that the user had a quartering-left tailwind of approx. 125 knots. That's a pretty high value, which makes me wonder if the autopilot script Aerosoft is using can even accommodate that strength of wind. Overall, this doesn't seem to be an isolated case. If I could have a vote, I would vote that Aerosoft work with at least one affected customer who can reproduce it and try to debug the issue with them.

Microsoft Flight Simulator - 1.23.12.0 2022-03-15 10-13-22.mp4 Same phenomena demonstrated on the Cessna 208 Caravan: applying pitch down nose command causes the trim to want to pitch up in response. If you disengage the autopilot, retrim, and re-engage the autopilot, the trim will jump to its last known value.

There are two possible solutions here: Ask Asobo to make trim control more realistic on their aircraft. Of course, Asobo's philosophy is one autopilot for all, which can be a bit of a stretch to connect a two-axis C172 Autopilot to an Boeing 747's (I won't touch on the A320 since it's not even in the same ballpark). Nonetheless, whatever changes they make will have to be thoroughly researched since you have to apply the appropriate reactivity to each aircraft, after which Aerosoft will have to make the appropriate changes to the autopilot anyways. Ask Aerosoft to split their own autopilot off and design it to meet their requirements. This is more burdensome on Aerosoft, but doesn't require Asobo to revisit every single one of their aircraft. The decision at the beginning of the CRJ project seemed to be to rely on Asobo's implementation of the autopilot. My post simply makes the case against that, and recommends that Aerosoft pursue developing and integrating their own autopilot system. Nonetheless, I will make a Zendesk report, since the undulation is barely perceptible on default aircraft, and it just looks sloppy (not as bad as the CRJ gaining a few thousand feet, though). EDIT: I should say, two problematic things with the default autopilot that seem to cancel each other out: The trim jumps immediately to its last setting upon re-engagement of the autopilot The trim on default aircraft is lightning-speed, and can go from one end of the range to the other. I think Asobo has opted to use the trim as the primary pitch mechanic for the autopilot and made it far too aggressive. EDIT 2: I have created Zendesk Request #152158 for this subject, pertaining exclusively to the default aircraft.