Jump to content

amahran

Members
  • Posts

    440
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by amahran

  1. 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 - 1.19.9.0 2021-09-19 16-03-27.mp4
  2. 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!
  3. 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!
  4. Looking forward to it! Anything helps that makes me remember I’m not just screaming into a void!
  5. 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…
  6. 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?
  7. 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.
  8. 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"; } }
  9. 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 - 1.18.15.0 2021-09-04 21-46-38.mp4
  10. 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.
  11. 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).
  12. 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…
  13. Don't think this was addressed with 1.0.6.0; the IAS tape and Mach number is still a little funky...
  14. It has been that way since Sim Update 5. Every controller on VATSIM has been calling out MSFS users relentlessly lol
  15. The Packs buttons and External Power Buttons are push-to-toggle buttons, and in is "on" and out is "off". In the case of the Turnaround State, the aircraft loads with those buttons in the "out" position and the "on" state, which is contradictory. To correct it, one needs to cycle the buttons off and on, so their positions are representative of their actual state. EDIT: Just to clarify, this does not impact function at all, just the appearance. Not sure if the same issue exists for other states. For example, I just loaded into the CRJ and I'm looking at the Packs buttons. Those show Fault, which I understand means they're in the "on" state, but they're also in the "out" position: Clicking the LEFT pack to turn it off, position hasn't changed, just the indication: Clicking LEFT pack again, it's now showing the same indication as the RIGHT pack, but it's in the "in" position. State and Position are now in sync: Same exercise can be done with the external power AC button, but I won't demonstrate it because the IRS alignment is an ordeal:
  16. This is a commonly reported thing on many aircraft in MSFS, it's not just the CRJ. Fly the CJ4 or A320 and you'll experience the same thing. MSFS now utilizes ISA deviation in order to calculate pressure altitude, just like in real life, if it's cold outside, your aircraft will be lower than it indicates, and vice versa. Although the calculation method Asobo uses can be significantly improved, this is normal and expected behavior.
  17. Am I the only one not seeing flex temp being applied when the thrust levers are moved to TOGA? I input the flex temp in the VNAV page and see the reduced thrust being applied on the EICAS, but during the takeoff roll the power exceeds the pink targets. It's almost as though it's entirely ignoring the FLEX setting. In the example below, the FLX target is 85 during taxi, but after advancing the throttle to TOGA, the thrust reaches 89.9% by the time I'm through 100 knots.
  18. Will the uncollimated behavior of the HUD be addressed in the future, or will the SDK limitation be addressed with Asobo to allow for this to exist? Right now, the HUD image is stuck to the glass of the HUD display, and doesn't exist "at infinity". Unfortunately, this means that some of the usefulness of the HUD is taken away, especially when it comes to the FPV; a minor change in position of the pilot's viewpoint changes the location of the FPV considerably. Also psychologically, it's a bit disconcerting since the image is supposed to be at infinity, so it feels like I'm looking at a piece of paper in front of me.
  19. Look at the bright side, you at least know for certain the community is very enthusiastic and eager 🙂 Always look at the bright side!
  20. I noticed this wasn't in the patch notes, but this happened to the fuel panel since SU5: I presume this switch has been addressed too?
  21. After SU5, the issue is still ever-present. I tried to diagnose it and calculate it based on my inputs. Speed bug is at Mach 0.74, its position on the IAS scale agrees with the Pressure Altitude and the SAT. Current Mach (0.766 in white above the speed scale) and TAS agree given the Pressure Altitude and SAT. TAS and IAS disagree given Pressure Altitude and SAT It's the position of the IAS value on the scale (where the arrow is) that's incorrect, not the speed bug.
  22. Seconded, the zigzagging at high altitudes (i.e., the description below) still happens as of the latest version on the marketplace (as of Jul 24).
  23. Seconded this issue, although I have seen this issue even when the switching from IAS to MACH is done automatically at 31.5k, not just when manually switching
  24. I have a minor comment on a bit of a gripe, since I work all day with helicopters with giant rotor disks. The prop animation seems particularly "step"-y, transitioning from one phase to another to a third abruptly with no smooth transition. It's a bit jarring, especially when that effect is connected to FSX's turbofan animation (slowly spinning or spinning at speed, no in-between). It takes me out of the moment, unlike in reality where there's no visual change that registers in your brain as a "step"; real rotor disks get faster and faster and slowly get blurrier and blurrier to the naked eye until, well, they're at speed. I'm not sure if there is a solution yet to better blend this animation, but if it's possible, it would make prop planes far friendlier on immersion.
×
×
  • Create New...