Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by amahran

  1. Haven’t even seen a real plane without bugs 😉
  2. Now in MSFS, the turboprop simulation on the default aircraft is a bit iffy at times (leaving some things to be desired). Things that come to mind include: Jumpiness of the prop RPM when spooling up for take-off (prop RPM overshooting target before coming back to nominal max RPM) No prop drag Engine parameter "jumps" during startup Specifically for the King Air, the inability to fine-tune the condition lever can be annoying (especially when trying to use it for taxiing). So my question to Aerosoft is: does the Twin Otter improve on the basic flight sim turboprop simulation, or does it take the basic turboprop (I think a PT6) and "reflavor it" to get the performance characteristics desired?
  3. Yeah, the audio control for com 1/2/3 are broken right now. I hope Aerosoft addresses it eventually, because having all your radios handy is good. Especially when you’re flying a CRJ by yourself on VATSIM and have to stage radio frequencies on various Coms to make everything handy and accessible with minimal head-down time during the transition (e.g, on final approach with tower in Com1, having Ground on COM2 active if you land successfully, and Approach on Com1 standby in case you need to overshoot)
  4. I’m hoping some artists will make generic private owner liveries; I like pretending I own these planes and flying myself around Probably some generic mostly-white paint job with one or two stripes, nothing excessively luxurious looking
  5. Does this run entirely natively within MSFS? I know MSFS doesn't like programs that don't run internally in the sim, which limits what is allowed on the marketplace... Basically, will these VDGS systems be part of the airport as sold on the Marketplace?
  6. Even if the "correct" SOP method is to engage heading, make the changes to the flightplan, and then re-engage heading, I would be extremely surprised if this feature (be able to change runway assignment during arrival procedure without having to fix the flightplan manually every time) isn't a function of the FMS. If it wasn't, there would be lots of blowback from operators to Bombardier for not making this a function: lots of real-world US operators operate a CRJ into and out of airports with multiple runways in use (e.g., Atlanta, Detroit, Chicago, Seattle), and if this wasn't a function, there would be an unacceptably dangerous amount of head-down time during a flight-critical phase. It's so easy to make a mistake if it's not automated, and it should be fairly easy to automate.
  7. +1. I know working title got it working on their NXi, though their gauges are JavaScript based. If nothing similar exists for WASM/C++ (which I think the CRJ is built on), it would be neat if Aerosoft could somehow convince Asobo to make it work, save us from getting Carpal Tunnel from writing long routes out…
  8. The actual IAS and Mach number disagree. If you convert them using the pressure altitude and OAT, you’ll find there’s an inconsistency between them. @JRBarretthad said earlier that this has been fixed in the latest dev build, and the next update should include this fix.
  9. There was a page 2 this whole time??? 🤦‍♂️
  10. Yeah, fixing the radio stack would be great. It already initializes in a weird state with all the knobs on, but even then it’s impossible to make COM2 do anything useful. I usually use COM2 for staging departure or ground frequencies to alleviate workload during high-pressure situations, or to get the ATIS, but that’s just not a possibility today. Depending on where you take the CRJ today, you’ll also hear a ghost ATIS you can’t get rid of (for example, near SFO). I think there’s a COM3 that hasn’t been disabled in the CRJ that’s constantly receiving. All in all, the radio units need a significant overhaul.
  11. I take that as a personal challenge to steer my Twotter without using the rudder 🤔
  12. In the attached video, you can see the letters constantly twitching around the compass rose. It's moderately weird looking. Of course, when you're in a turn, it twitches fast enough to make it look like a strobe: Microsoft Flight Simulator - 2021-09-19 16-03-27.mp4
  13. Thanks, @JRBarrett! I was constantly peeved that the CRJ was taking these weird turns, thinking I was screwing up somewhere. But this post was actually insightful in helping me feel I'm not alone!
  14. Don't know why you got downvoted, but that's an excellent observation. There are indeed lots of bug reports and issue reports for the CRJ. Some are wildly outdated, some are recent developments, all are in the forums. So when I encounter a new bug, I ask myself the following questions: What exactly is this bug I'm experiencing? Is it truly a bug or a system failure, or am I using the product in a unintentional manner? What exactly is causing this bug? Bug reports are great, but if there's no reproducability, it's useless to the developer. What are some key words that could be used to search for this bug in the forums? The last one is particularly important. Some obvious keywords can be "TCAS" which every simmer knows, or "Seatbelt Sign". Those are easy enough to look up and see if you can find a relevant forum topic title. However, some aren't so clear: The Audio Control Panel (Left seat, Right seat, and Observer) initializes with all the knobs in the on position except the Com1 knob, which is selected by the mic knob. Naturally, this screams to me that the boolean for the volume knobs in the ACP is reversed in the aircraft initialization. So now the question: What do I SEARCH for? Do I believe simmers will know the correct term for this panel? ACP? (too short to search) Audio Control Panel? Volume Knobs? Com2? Radio? (This one pulls up too many results) Once I ascertain that no one has already posted that topic, I then go through the effort of documenting the conditions that causes it: have I tried recycling the default state? Have I tried different default states? Have I tried quickloading states? Have I tried loading on a runway? In the air? At the gate? Then of course there's the issue of tangentially related posts: maybe they're related enough that the developer notices the issue, but maybe they haven't noticed: I found that if I move my joystick fully forward, all the screens in the CRJ hang entirely. I found a forum post which was about screen freezes, but the joystick wasn't mentioned. Should I post in that topic or make a new one? And then after all that, I have to document all my observations: what the issue is, what's supposed to happen, what happens instead, what's causing it, what I recommend as a potential fix (if possible), all with pictures. This is time consuming, and it can be disheartening to hear silence afterwards and see it not go anywhere. Eventually, it has gotten to the point where I see a bug nowadays and go "eh....screw it I'm just gonna fly, they probably know about it". So hopefully Mathijs' proposed solution this week can help resolve that and bring the enthusiasm back!
  15. Looking forward to it! Anything helps that makes me remember I’m not just screaming into a void!
  16. I don’t know if anyone else is experiencing this, but at the initial release of the CRJ I was enthusiastic about reporting bugs and issues, and as time went on I felt some kind of reporting “fatigue”. To describe it adequately: - I’m not sure if my reports are contributing to any effort - I’m not sure if a bug I experience has already been mentioned - I’m not sure if devs are aware of the bugs and issues I’m observing (at least I’d hope I’m not the only one seeing them). - I’m not even sure if the bugs I’m reporting are going on a back burner or if they’re scheduled to be addressed after another bug, or if they’re to be addressed in a coming update, or what - I’m not even sure that the devs who see my bug reports are acknowledging them as items to be addressed or if they’re being accepted as “it is what it is”. I realize the devs have a lot on their mind, and are dealing with an ever-changing SDK, so I can’t blame them for not communicating every individual detail. However, I feel like I lost some enthusiasm in bug reporting; it’s exhausting and feels like my bug reports are going into a black hole. And I’m honestly burnt out. Does anyone else feel this in any way, either with the CRJ or with MSFS in general? Aerosoft, do you guys still want us bug reporting at this point for persistent bugs, or is everything already “known” by now? I love to help but at some point it feels like I’m being a nuisance…
  17. When flying an instrument approach, I'm accustomed to doing the following check. That's just how I'm trained: T - Tune the frequency you want to navigate with respect to I - Identify the frequency by means of listening to the "code" or checking on a nav display T - Test the navigational capability of your equipment using this nav source S - Set the course and navigation configuration you want to utilize. With the CRJ, the testing isn't applicable because the system is capable of self testing, and tuning for ILS frequencies is done automatically (and conveniently). However, I do occasionally want to actually conduct the Identification; sometimes on approaches I find myself second guessing whether I'm picking up the correct signal, even though I know I have the correct frequency set. I have two options: 1. Check the morse code by listening to the Nav audio. Unfortunately, these switch behaviors are wrong and non-functional: 2. Check the nav ident on the PFD or Nav Display. This is my preferred method because it saves time and the CRJ should be capable of doing so. However, the Aerosoft CRJ doesn't show nav idents on the PFD or ND! In the screenshot below, I know I'm tuned to a VOR that's 22 miles away, but what's the nav ID? What VOR is this? In contrast, here's a screenshot from a P3D/FSX user, who gets a nav ID display when they're in the NAV mode: So my question to the devs and all CRJ pilots are there: How is the nav ID supposed to be displayed and confirmed to the pilot, through the PFD and ND, or is the pilot supposed to listen to the audio in the real plane?
  18. I'd be curious to see what the answer is; I utilize Coms 1 and 2 to stage frequencies when I fly IRL. I do it in the sim too, but with the CRJ I have to disrupt this habit because Com2 doesn't work normally.
  19. When flying at a Pressure altitude of FL390 in MSFS (geometric altitude of 40,630') , I crossed a plane flying at a pressure altitude of FL380 in P3D (geometric altitude of 38,005'). The ABS selection in the TCAS had their indication show "380", as it should. The REL selection in the TCAS had their indication show "026" when it should have showed "-10" The problem: The REL altitude calculation doesn't use the user's own aircraft's pressure altitude; it uses its geometric altitude. Ideal system: ABS altitude calculations should utilize the AI aircraft's Pressure Altitude simvar and correct it using the user aircraft's altimeter setting. REL altitude calculations should utilize the AI aircraft's Pressure-Altitude simvar, and subtract the user aircraft's Pressure-Altitude simvar I wrote some pseudocode below, hopefully this makes some sense to the person who's actually responsible for the TCAS code on the MFD: var TCASAltitudeTag; var TCASUserAircraftAlt = simvar(user.PressureAltitude); var TCASAITrafficAlt = simvar(AI.PressureAltitude); if (TCASAbsRelSelection = ABS){ TCASAITrafficAlt = TCASAITrafficAlt-1000*(altimeterSetting-29.92); if (TCASAITrafficAlt < 0){ TCASAltitudeTag = concatenate("-",roundToInteger(-1*TCASAITrafficAlt/100)); } else { TCASAltitudeTag = roundToInteger(TCASAITrafficAlt/100); } } else { var AltDif = TCASUserAircraftAlt-TCASAITrafficAlt; if (AltDif <= -50){ TCASAltitudeTag = concatenate("-",roundToInteger(-1*AltDif/100)); } else if(AltDif >= 50) { TCASAltitudeTag = concatenate("+",roundToInteger(AltDif/100)); } else { TCASAltitudeTag = "000"; } }
  20. On the topic of propellers, I like the way the Hype Performance Group guys did their H145 rotor blades; they slowly transition and there's no "step"-iness to it. Mathijs, I hope you can see what I was referring to a few weeks ago when I was talking about eliminating the 1-2-3 blur steps during the engine start: Yes I know there's the wagonwheel effect, but this one is much easier to swallow without the discreet blur steps which kills immersion. EDIT: Attached is the same thing, but from a different view: Microsoft Flight Simulator - 2021-09-04 21-46-38.mp4
  21. This was an issue with the CRJ since it was released, well before SU5. SU5 made it more prominent, but the speed tape was always off.
  22. Okay, go cruising at 35000’ pressure altitude with live weather. Using your TAS, OAT, and Pressure Altitude, calculate what your IAS should be. Now compare that to the actual IAS value shown on the airspeed indicator. You’ll find that there is a significant difference between the two values. I’m familiar with the topic of IAS and that it decreases with altitude due to the thinning of the air; I’m an aerospace engineer and licensed pilot. That’s not what this topic is about, however; this topic is about the fact that the speed tape will show you above a certain Mach number and simultaneously show that your Mach number is higher (or vice versa).
  23. I’ve written about this over Here. The issue isn’t with the Mach Number or the position of the Mach bug on the speed tape; it seems that the IAS indication is incorrect. If you compare your TAS against your Mach number for a given pressure Altitude and temperature, they agree. However, the IAS will disagree. EDIT: I actually wonder how this was programmed the more I think about it. The IAS, Pressure Altitude, OAT, and Groundspeed are the only things that are measured by the aircraft, so Mach Number and TAS should be “inferred” or calculated variables. I find it a bit weird that the IAS indication is the one that’s wrong, but the values calculated from it (TAS and Mach Number) are correct…
  24. Don't think this was addressed with; the IAS tape and Mach number is still a little funky...
  • Create New...