PinkCube

I believe this is a very basic way of simulating losing track from clutter a target moves around (applies regardless of actual clutter). Here is another document that offers more insight into maverick launches on tanks and buildings (in a test environment?). https://apps.dtic.mil/sti/tr/pdf/ADA361645.pdf It's interesting to note that the AGM-65B was fired at slant ranges of up 1.5miles maximum. It does not say what the limitations of why they had to be so close during the tests. I can only speculate and assume there was a technological limitation which would be supported by the illustrations in my previous post.

The real limitations are how they're modeled in DCS. In real life, technology (old TV guided seeker) These are different missiles to the AGM-65A (RB75). They have separate issues. Tracking moving targets: As of now the RB75 - the earliest maverick - is superior to all the later mavericks because it appears to use a different logic in the game to the others. Here are the values I believe that the maximum speeds (in knots?) mavericks can lock targets in-game (mav A & B are recent additions in the latest patch): RB75: 128 Mav A: 28 Mav B: 33 Clearly there is a problem in the game files if essentially the same missile has to different values. Why is the Rb75 capable of locking targets going 100kts faster than its equals? As you said yourself the laser guided missiles also run out of energy before they can hit the target. the RB75 also calculates an intercept trajectory (I'll go on a whim and say this is completely fantasy). Range of targets: From this publicly available document https://media.defense.gov/2010/Sep/29/2001329786/-1/-1/0/AFD-100929-043.pdf there are some notes regarding how the maverick should lock targets based on their size and range. null null According to this document they had to get closer for smaller targets. The image suggests that in real life locking a tank at 5miles is impossible (assuming it's the mav A and not the B), because of size and clutter. Locking a moving helicopter at 7.5miles with the ability to intercept and disregard clutter it is flying over is how it's actually modeled in DCS.

nullThe AGM65A (same as RB75A afaik) has 5 degrees FOV. And I doubt it has the seeker logic to track and hit targets moving 250km/h, 12km away.. I will look for sources and documentation. All I've found so far is a weapons evaluation for the D model which describes the slant ranges it was fired at around~2500meters at tanks.

I have not flown the gazelle since the last update. I will produce a track when I rebind the controls. It's not just me that had that bug, a friend had the same issue which prompted me to start mashing buttons and find the quick fix.

You will have to tap a button on your keyboard to control the camera or bind a button input to slew the camera. This will reset the false axis input it seems to create (caused by pressing recenter while having a camera slew axis input) and allow the re-centering to work again.

Cockpit LOS can be emulated by telling the AI to not fire when deflection angles below the nose are over a certain limit. In theory this is not an advanced concept. If there is new AI in development then this should be taken into consideration while the development is taking place and not after.

If you hit the recenter button while you have axis input to the camera, the recenter button will break and the TV camera will start to drift (create a false input). To make the recenter button work again you need to use a button to control the Vivienne camera movement to eliminate the drift caused by a false axis input. This will fix the recenter button and make it work again.

The super human AI in warbirds Today I would like to talk about the AI, particularly in the spitfire. Those who've play in the war-birds will have at some point decided to fly against one of these monsters and most likely lost a lot of times against them. Now, what is apparent in DCS is that the AI makes shots based on computer calculations (obviously) which makes them extremely accurate. Put this in the spitfire and you've created something obscene. I'm pretty sure all DCS planes in WW2 work like this but combined with the turn rate of the spitfire you created something simply built different. There's no margin of error in accuracy or burst length limitations built into the AI so often you get sniped out of the skies by an AI using single shot mode without the sight of any tracers whizzing past your cockpit. Two factors that can save your life. The AI can use single shot mode by only firing when it believes it has a 100% accurate gun solution. But there's more... The AI pilot can see through the cockpit which means his vision isn't obscured when pulling high deflection shots. See the image below... Now you might say you can do this as a human... But a human will use GUESSWORK to make the shots and not a ballistic computer. A human will lose sight... And a human will spend ammunition and release a stream of tracers which you can "react" to. So, why isn't any of this incorporated into the way the AI behaves? Why can't the AI release a burst rather than a single shot? Why doesn't the AI fire inaccurate shots that will miss (dependent on set difficulty)? Why can the AI accurately shoot while not having visual of what it is shooting at? It either feels like you're fighting a toaster or the terminator and there seems to be nothing in between.

You need to limit framerate with in nvidia control panel AS WELL to stop the terrain stuttering.

It's not the same, I have tested both and each has a different effect. My theory this also helps limit the CPU but I could be wrong on that.

Any variance of the game frame-rate and monitor refresh rate mismatch causes the specific stuttering. The bigger the difference, the more noticeable it becomes. It has been speculated that this is because of CPU & GPU frame timings being off and it is out of our control. My final fix is to limit both the game fps and monitor refresh rate to something that can sustainably be maxed out so they always match. The tearing issue that came with that is solved with vsync=fast in nVidia control panel.

HAGS on or off made no difference for me. I don't use DX12 or frame generation. Not technically versed in any of this stuff. I am only doing my own experimentation and finding out what "solves" the issue for me. After further testing, I have come up with this temporary solution that works for me until ED do something about this. This seems to keep everything in "sync". Monitor refresh and maxfps value in graphics.lua values must match. If you are playing heavier missions in DCS then set the refresh rate and graphics.lua to a minimum baseline which would be somewhere just under your average frame rate. There will be no stutters so long as your in-game framerate does not drop below whatever limits you set. If framerate is limited by nvidia software then I just experience stutters at a high frequency which produces a vibrating effect and therefore does not work and must be application controlled. or limit it using the max framerate setting as well. If frame-rates drop below the numbers you set often and induce stuttering then alter as desired. The refresh rate must be application controlled and vysnc=fast in Nvidia control panel. Changing other settings like low-latency mode and pre-rendered frames may help. I'm done. because now this just makes trackIR stutter. and I probably need trackIR to be in "sync" somehow now as well. null

After experimentation. These two settings provided a half fix for me. Edit: update on "fix" in later post Graphics.lua maxfps=refreshrate & Nvidia settings v-sync fast + app controlled refresh rate

A quick update. It seems that I may have found a fix. I decided I would set my max frame-rate to 165 in graphics.lua match my monitor refresh ratenull This removed the stuttering effect but highlights a almost "STATIC" horizontal strip across my monitor that contains visual tearing and moves the terrain as it passes through. Test #2 maxfps=164, Terrain stutter gone. The tearing horizontal strip scans my screen DOWNWARDS and pulses ~1 second Test#3 maxfps=166, Terrain stutter gone. The tearing horizontal strip scans my screen UPWARDS and pulses ~1 second. The "pulse" effect with lack of better word to describe it is what alters the position of objects. Edit: tearing solved with vsync turned on in nvidia control panel Test#4 maxfps=165 in a heavy multiplayer mission with frame-rates peaking around 100-120 . Things seem slightly smoother, however any stutters could now be linked to an actual frame-time issue. And hard to pin down exactly if my fix worked and if it only works when the game is running at 165hz. null

It seems that this thread has been hi-jacked with users experiencing a different problem. This issue is very specific to the terrain moving badly as viewed from your own cockpit. I experience this while having a constant 180FPS. The following recording is only in 60FPS, and doesn't necessarily show the full detriment of this issue, however it still highlights the issue. Here is a video of the issue that needs to be resolved.

I am not sure if this is linked but it's also an experience I have which may be linked to the vibrating plane issue. The video is 1x speed and 1/64 speed in DCS. I suspect with the plane position updating so infrequently if gives the illusion of stutter and a low framerate. The ground also stuttering / vibrating becomes much more prevalent with the game speed at 1x. 0826(1).mp4

In my experimentation of finding out how to improve the smoothness of TrackIR and make it feel less stuttery I found a file called view.lua. Going by "feeling" changing these values to 0 made trackIR feel much more responsive in DCS. However didn't quite mitigate the stuttering (lower framerate feeling when looking around) I was trying to solve.

My suspicion is that because the periscope view is always "on" and rendering objects it is zoomed in on it seems to cause the stutters, especially in particularly in heavy missions when maneuvering and bringing various objects into its FOV. Model loading and dots seem to be affected in the gazelle. I often need to be zoomed in 50% or more otherwise I will struggle to find other aircraft. I don't know if this is linked.

Any updates or has this now been marked as "fixed"? Edit: Seen a later post and see it seems to be taking time for the fix to be implemented. This bug makes it quite hard to IFF based on silhouettes of planes vibrating and to get a clear picture of what planes (dots) are doing in far distances.

Thank you for posting about this problem. It has been nearly one year since you highlighted this issue and nothing has been done. I believe this is also an issue with other ED modules that carry the 9B such as the F5. With the introduction of the Mirage F1 and its new and more realistic launch characteristics with the 9B, this problem became even more so highlighted with other modules. It is my belief that this is partly what also lead to RAZBAM removing the auto-uncage of the R-3S (historically a very similar missile) on the mig-19 and changing other launch sequences such as the time it takes to leave the rail. I am bumping this topic simply because although here; on the forum, it doesn't "seem" much of an issue and I hope it gets more attention. Among the cold war multiplayer player base, it's very common that "little" issues like this tend to elevate our disdain for the game and gives us the feeling that these modules have been abandoned.

Excellent news

In the video I switch between the gunpods on an unsymetrical loadout and hit the jettison button. The result is that the game crashes. unsymettrical.mp4

Face it, the overwhelming majority disagree with you for a reason (you are wrong). Sorry we don't conform to your societal standards. There's two main reasons people use clear canopy and dots. And, the advantages they give a player are extremely minimal. a) If shadows off, the sun shines through the cockpit and hits the glass and reflects straight into your eyes b) DCS isn't smart enough to provide scaling for players on 2k/4k monitors Now because of this greatly out-of-touch decision to make this change to DCS, all that's happened with this patch is that Enigma's Cold War has disabled IC check entirely so players can keep using these mods. The end result is that the most popular PvP server is NOW MORE VULNERABLE to cheaters.

Not fixed for me. bulletcrater.mp4 FPScraterbugwithmi8.trk craterswithhueys.mp4 FPScraterbugwithhueys.trk I could run this scenario without crashing before. Obviously this is on the "extreme" side. I don't think the game should be crashing anyway. But this is exagerating the pain of gradual bullet impact buildup over time that we have in multiplayer which nullifies any frame rate improvements we got with MT . BIGCRASH.mp4

ED please fix this for cluster bombs too so we can use them also. FPScraterbug.trk FPScraterbugwithF5.trk