av8r172

Wonderful lol

Just to clarify, can we expect to get an update for 5.2 HF1 because it's not December 31st yet?

I'm looking at 2 monitors. One is G-Sync compatible (48-165hz), the other has AMD Freesync premium. I have a pretty modest system, and with my settings I do dip below 30fps at heavier airports. I understand ideally, I would want a full G-sync monitor that can sync from 1-144+hz, but these are very expensive. AMD freesync premium and G-Sync compatible monitors have something called a LFC: Low Framerate Compensation, which doubles frames below the minimum refresh rate of the monitor to avoid judder/tear. Can anybody shed light on this? Or will I not minimize frame rate fluctuation stutters unless I go for a full G-Sync chipped panel? I would like to run at 30hz, it's just almost impossible to figure out before you buy a monitor whether it will allow you to set a static 30hz refresh rate. Currently, my monitor can only refresh at 60hz. Using adaptive half refresh rate in NCP looks great and smooth, except when panning or resetting my view, which judders horribly. Trying to eliminate this.

Usually the taxi flow is triggered if both engines are running and the PF completes the flight control check. For some reason, it is not being triggered until I go below the line on the before takeoff checklist, so you have to wait for the PM to check his controls before taking off. I made the mistake of taking off yesterday and the controls started going full scale left right up and down.\ UPDATE: I have figured out what this is related to. Due to the recently changed logic of the tiller disconnect button, this has broken the flight control check, and therefore the taxi flow. As it stands in this new version of FS2Crew and the new 151, the PM flight control check will not complete with the tiller button depressed, as was possible before. As soon as it's released (as in before takeoff), the PM completes the flight control check. I always do the flight control check on the roll as to not spend too much time sitting pushed off the gate.

I'm having the same issue.

Broke for me too

I'm a real crj pilot and I think it's the same exact thing. Which is not to say bad, but room for improvement.

Since v5, I have been able to take advantage of the wonderful Nvidia control panel feature of Adaptive 1/2 refresh rate Vsync (my monitor is locked to 60hz only). Doing so effectively locks the fps at 30, and motion outside the aircraft is smooth as butter. Panning using the middle mouse button in chaseplane is butter. However, using the hat switch on my joystick, pressing the view reset button/key, or the keys assigned on my numpad, panning is very jittery/ghosty. I can make a video of this if this is unclear. Let me put it this way. If I don't move the camera at all and I'm looking at the markings on the ground surfaces as I move along, smooth as glass--no tearing/jitter/ghosting. If I pan holding the middle mouse button, also smooth as glass. But using any other method to pan/reset my view ghosts and tears very badly. I've been told that this might have to do with how chaseplane handles panning with joysticks/keys. As you know, instead of a pan axis, it behaves more like a "control to be repeated while held" keypress. If this isn't sending inputs at a high enough rate to the sim, as the view sweeps across, it will appear as if it start/stops panning hundreds of times per second, instead one fluid motion. Is this something that can be fixed with chaseplane, is it just my monitor model, or something else? PS: If I lock my frame rate to any value (30,60, etc), in P3D or Nvidia, then everything is jittery. Motion outside and mouse panning included.

A couple of us figured this out a while back. I've talked extensively with TFDi about it. Yes, VSync does have an effect on it, but the fact remains that I cannot initiate a DXGI device hung if TrueGlass is disabled with any settings. This is true for everybody I've talked to. I've spend countless hours of my life on this but there is only one common denominator--disabling TrueGlass works. And the fact that TFDi cannot fathom how it is related doesn't bode well for it being fixed anytime soon. Which is a shame, because it used to work so well in v4. TFDi said they would talk to Lockheed about it. Obviously they didn't, or Lockheed didn't do anything about it. BTW--if disabling Vsync truly worked for you, I'm happy for you. I found that I was able to complete some flights like this--I thought I had my solution. But then on other flights, I would get it again as long as TrueGlass was active. Very disheartening several hours into a long haul. I understand that they don't understand the issue, but the way they vehemently deny their product has anything to do with it is frustrating when disabling it solves the problem. Recently, somebody asked on their forum when TrueGlass will become compatible with v5. They said something to the effect of, 'It is already compatible, but not as stable as we'd like. Hopefully Lockheed can work on this with 5.1'. 5.1 is here, and this DXGI crash is here to stay...

I've been speaking with a certain TFDI developer about this for almost 2 weeks. He's convinced it can't be TrueGlass but P3D itself. Turning Vsync off in P3D helps for a little, but just delays the crash. The only way for no crash is to disable the TrueGlass.dll in the gauges folder. This issue has driven me crazy. I've tried just about everything I can think of. The way I'm able to trigger it the fastest is at ORBX ESKS at the gate with the Maddog. Here's the real bizarre part. It doesn't crash at dusk or at night, even when the dynamic lights are taking my gpu down to it's knees at 15 FPS. No, the crash only happens in the day when I'm running 60+ FPS. Another strange thing I noticed is that turning ON Enhanced Atmospherics helped. I don't usually use this feature, but when it's on, I don't get the crash. Very very strange phenomenon and absolutely frustrating.

I will have much much more testing to do, but I believe I may have run into a solution. The problem file was indeed the model.IAE of the FAIB A320 included with FLAI. I downloaded the standalone FAIB A320 from their website, and simply replaced the FLAI FAIB A320 model.IAE folder with the one from FAIB directly. Before, i was able to get a 100% reproducible CTD (ntdll.dll) by pressing Cntl-Shift-T at EGLL (or surrounding London airports). Now, no crash. Hopefully this can help some people.

I'm so happy to have found this thread, if not to find a solution, but to see that I'm not crazy or alone. Last summer, I spent hours on trying to figure out why I could not make a successful flight into or out of EGLL without P3D crashing due to NTDLL.dll. In my testing, I indeed narrowed it down to AI2UTL injecting FLAI traffic and using UTL. If I've read carefully, that makes 3 of us in this thread that have crashes at EGLL using AI2UTL to inject FLAI into UTL. Perhaps this suggests it's a corrupt model OR a specific livery/flight plan of a specific model that consistently generates at Heathrow.

With this option selected, instead of both A pumps being shut off before pushback, Engine 1 A and Electric 1 B are shutoff.

Make that 5 Maybe something in these links can help people. This latest thread seems to narrow in on FTX Vector; some people have had success disabling it.

EGLL-KBOS crashed today at 4x speed approaching Labrador with the new GSX 😞 I appreciate the efforts though It's so strange that nobody has been able to pinpoint it yet. There are 4+ decent sized threads besides this one describing exactly this: westbound trans-atlantic flights crashing near the east coast. https://www.avsim.com/forums/topic/521091-ntdll-error-in-p3d-v4-near-canada/ https://www.avsim.com/forums/topic/477563-memory-leak-over-canada/ https://www.avsim.com/forums/topic/531004-p3d-crashing-over-northern-canada/ http://www.fsdreamteam.com/forum/index.php?topic=16936.0