Jump to content

aurel42

Members
  • Content Count

    27
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

1 Neutral

Profile Information

  • Gender
    Male

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No
  1. Perhaps I didn't make clear enough that this happens on every turn, under any wind condition, and in all my GA aircraft. There is nothing random to it. And at no point does it feel anything like a real turbulence (which obviously should have some random element). So I never even considered AS16 as the cause of the problem. For me, this is clearly unexpected behaviour, aka a bug. But, to be fair, the explanation for the feature in AS16 states that it can affect aircraft handling. And there's always the possibility that a combination of factors lead to this broken behaviour, and I just got rid of it by changing one of the factors, so this feature might work as expected under other circumstances.
  2. Solved by disabling AS16's "Enhanced turbulence"
  3. Hey Mick, Correct, I don't have any duplicate assignments (controllers are turned off completely, and I also removed all the axis and button assignments to be sure, I only left the keyboard assignments untouched). Also I did intentionally not touch any controls, neither the yoke nor the rudder, while recording the video. If I had shown "manual" turns, it would have been hard to tell whether I just was too clumsy on the rudder.
  4. Yes, I'm running AS16. There's a small, yellow pointer at the top of the map on the left (provided by Little Navmap) that shows the current wind conditions. While recording the video, the wind was at a mere 3 knots.
  5. That's totally not what I expected you to say. I guess I'd have to reinstall P3D to show that this aircraft doesn't behave that way on a "fresh" sim. I've been there before and what I consider an "issue" was gone after the reinstallation until it reappeared recently.
  6. First, I have to correct wrong and confusing info I have given before, sorry for that: being carried to the right during a take-off with the Twin Otter was unrelated to the issue discussed here; it probably was just a strong wind, as I assumed initially; P-factor and torque don't appear to be part of the problem, especially during take-off and slow flight, the behaviour is as expected (slight left-turning tendency); add-ons, especially FsPassengers, don't seem to have anything to do with the issue: I could reproduce the problem after disabling all non-essential addons (using SIMstarter NG, I disabled everything except gauges, FSUIPC and the GoFlight input bridge in exe.xml and dll.xml) the behaviour is not asymmetrical, that was a total brain fart; the behaviour is identical during left and right hand turns; the behaviour is identical when hand-flying the turns; Here's the video showing the issue, please ignore the audio track (I like to listen to podcasts while flying and didn't turn it off when I recorded the video): https://youtu.be/NJbwKYGQL9A?t=1m27s at 1m27s: AP in HDG and ALT hold modes; close-up of instruments during 90° right-hand turn; at 1m40s: ball in turn coordinator swings right, then left at 1m50s: ball in turn coordinator swings right, then left at 2m20s: similar turn, now with YD "cheat", aircraft behaves as expected at 3m20s: one more turn without YD, now in AP's NAV mode, aircraft behaviour back to weirdness If you have any idea what could be going on here, please help! Cheers, Marc
  7. I've set my Realism settings according to the user guides for the RealAir aircraft, which recommends setting the P-factor and Torque sliders to about 50%. My current working theory is that "something" (possibly an addon like FsPassengers) modifies these values without my intervention, perhaps increasing one or both to more than what a slider at 100% would represent. By now, I'm quite positive that, when I have the problem we're talking about, I need more left rudder than usual to stay on the center line during take-off, and I need more right rudder than usual to keep the aircraft from going into a slip (and swinging back to the left) during right-hand turns (no matter whether it's an AP-initiated turn or whether I'm in control of the aircraft). If this is the opposite of what's to be expected with "normal" values for P-factor and/or Torque, perhaps that could imply that one of the settings is – by mistake – set to a negative value? I'll try to check tonight whether the behaviour is actually caused by one of my addons (by disabling them all). If I can't figure it out, I'll make a short video demonstrating the issue, perhaps it's easier to identify what's going wrong if you can actually see it yourself. Thanks to you all, I really, really appreciate your help!
  8. Hey Gregg, I appreciate your response, but, no, calibration is not an issue. I use FSUIPC for all axes, which makes it easy to verify that there are no spurious inputs, and I verified that the rudder actually rests nicely in its small dead zone when it's not used. Thanks for pointing out that P-factor is much more noticeable when the aircraft is slow, I was aware of that, but it didn't "click" until you mentioned it: When I took off last night in a Twin Otter, I got almost carried off the runway and needed rudder at full left deflection to get myself back to the center line. I attributed it to a strong gust of wind, but looking back now, it could well have been another piece of evidence pointing to a ridiculously strong P-factor setting. I'll verify that by testing in calm wind conditions. I need to find out whether there's a way to get the current numerical value for the P-factor setting (instead of just looking at the slider in the Realism Settings dialog), perhaps there's an FSUIPC offset or something. Or maybe the changed value is visible in prepar3d.cfg.
  9. Hey Bill, thanks for your input and advice. I guess that means I've got something else going on that affects the behaviour of aircraft during turns and seems to make a lot more rudder action necessary — I'm seeing the same extreme yaw tendencies when the aircraft is mine, and it feels like I need quite a bit more rudder than before to do coordinated turns. But, yeah, using the YD definitely helps, although I never had to use it before in the aircraft I listed. And I didn't touch the aircraft.cfg files for those aircraft before the issue started. I shall try to identify whether it's some addon that interferes. I recently started using "FsPassengers" which does seem to change some sim settings (especially realism settings) when activated, so I guess that would make it a possible culprit. I believe the problem is much more pronounced on right hand turns — if it is in fact an asymmetric effect, perhaps it's something crazy like P-factor being set to more than 100% (if that's even possible).
  10. Hi there, I have an obscure problem that hits me from time to time, I have no idea what causes it and would be grateful for any advice. In my experience, the normal behaviour of autopilots in FSX/P3D is that they do clean, coordinated turns. In my current P3D installation (and I've experienced this before on a separate installation), the autopilot forgot how to coordinate turns, so it starts banking, the ball goes out the center, after a few seconds the ball (and the aircraft) swings violently in the other direction (is that a "dutch roll"?). In effect, I have to assist the AP during every turn by coordinating with the rudder pedals. So here are my two (groups of) questions: How do Autopilots in GA aircraft work in the real world? Do they have rudder authority even when they don't have a Yaw Damper feature? Are they limited to bank ankles that don't cause that slipping behaviour? Any idea what "overall" settings (ie. non-aircraft specific settings, I did not touch any aircraft config files) could modify the AP turning behaviour in P3D, what I could've messed up to make P3D act this way, and perhaps even how to fix it? Additional info: I don't use "auto rudder" as I have rudder pedals. Since the behaviour changed, I've observed it, for example, in the Milviz C310R, RealAir Legacy and Turbine Duke. Am I just being stupid somehow? Cheers, Marc PS: If my explanation is unclear, I can provide video of the behaviour.
  11. Uh, I checked out this "Maintenance and Income Tool". I might be running a lot of confused code on my machine and never know it, because it's hidden behind a polished GUI, but in this case the confusion is so obvious that I'd rather not try. Instead, I picked up the A2A Comanche. Thanks again for your advice, Don! (The Katana isn't available for P3D. It seems updating the installers of their legacy products isn't among the highest of priorities for Aerosoft.)
  12. Thank you very much, I will look into all of them. I did have A2A on my list of publishers to try, but I wasn't aware their aircraft came with maintenance and failure stuff -- is that what they call "Accu-Sim"?
  13. Turns out, if I had done more than just the most superficial research, I wouldn't have had to ask that question. I learned two things: 1) P3D truncates my large numbers already when entering them. The "to" value is capped at 600 minutes. That's not enough for what I tried to do. 2) P3D doesn't seem to save individual failure configuration at all. No matter what I enter, when I quit and reload P3D, all the failure configuration is reset. So there's probably no way to circumvent the cap in the GUI. There goes my dream. I guess I have to find a GA plane that simulates damage "externally", like the mentioned airliners do.
  14. Oh, we've come full circle quickly. That's not my understanding. Example: I set a minimum time of 0 and a maximum time of 100 minutes for the failure of a component, then I do a 50 minute session. As I understand it, I end up not with the certainty of having a failure, or the certainty of not having a failure, but a 50% chance (or risk) of having a failure. My original question was about this and about approximating (not simulating!) realistic failure rates by using much higher numbers than 100 minutes, ie. numbers like real-world MTBFs, in the thousands or tens of thousands of hours. I'm grateful for your explanations about my "bonus question" from the original post, about failure data being persistent when saving sessions. I know now what I can't do. I can't use an aircraft without a "virtual overhaul" between each of my sessions, since P3D's failure "prediction" will be reset whenever I start a new session. I have to check and see what I can do. I still don't know, for example, if P3D actually handles a maximum failure time of 600,000 minutes correctly, or if it caps that number internally, and if it does, whether it caps the times before or after creating its set of failures for a session. If it doesn't save that failure information anywhere, I have no idea how to check this.
×
×
  • Create New...