Yaga

What I see in wireshark is that the server simply stops sending my client UDP traffic. After 2 minutes it sends a command to terminate the connection and I get the ping timeout message.

Previously I've tried increasing the page file manually without any luck fixing this issue. I will try again, but I'm not too optimistic. Is there any way to access more detailed logs on DCS network activity? I see the pinned post: "DCS uses outgoing connections to HTTP http://www.digitalcombatsimulator.com:80 HTTPS http://www.digitalcombatsimulator.com:443 XMPP master.eagle.ru:5222 For multiplayer game traffic DCS uses both TCP and UDP on port 10308 For Voice TCP and UDP on port 10309 webgui_port = 8088" Curious if one or more of these connections is closing. In the DCS alt+pause monitor, sent/received data simply stops, packet loss builds over a few minutes, and eventually I'm kicked to the server menu. There's nothing in Windows that should be causing this. Nothing in my router logs that indicate the router intentionally closed the connections, and nothing in events manager that seems to correlate. This issue only occurs on the Blue Flag Syria mission (probably an important bit of info), and seems to occur most when I'm interacting with the server through rapid chat commands or placing user marks in F10. Other times however, it will occur while just sitting in the first jet I slot into after joining. I feel like i can identify a few patterns between my client behavior and when the server communication ends, but without knowing a bit more about how DCS is handling network connections it's hard to do much more than speculate. There are a few people on the server that also have this as a recurring problem. All any of us can determine is that sometimes network traffic between our client and the server simply stops, despite the server running normally and other clients experiencing no issues. Can exports effect DCS network traffic? I export a jetseat, SRS, scratchpad, and tacview. I also viewport my RWR in the F-16.

Log attached. Multiple sessions, and the last 'disconnect from net' was due to a ping timeout. If you need a clean run without the shaders mod, I can create one. However, the issue does not seem tied at all to Mustang's haze shader pack. I'm curious about DCS switching between "forestDistanceFactor has been changed to 0.400000. Update lod buffers" and "forestDistanceFactor has been changed to 1.000000. Update lod buffers". I am not doing this in settings. In settings, DCS was set to 40% for trees rendering the entire duration of this log. dcs.log

It's sort of surprising that this is even a point of discussion. i don't recall exactly when it changed, but here's how scoring worked prior to 2.5.6-ish: If you were on the ground at a friendly airfield and returned to spectators (unslotting), you did not receive a death. Even if you had taken damage, no kill was awarded to whoever damaged you. This makes sense, you made it home after all. If you unslotted in flight (or somewhere other than a friendly airfield), you were scored a loss. This makes sense, you left your airplane and didn't make it home. If you unslotted in flight after taking damage from another player, you were scored a loss and they were scored a kill. This makes sense, they damaged you, and you left your airplane. If your pilot was killed or if your pilot ejected, you were scored a loss. If your pilot was killed by another player (or if you ejected after taking damage), they were scored a kill. This makes sense for obvious reasons. Currently, it has been changed so that unslotting never results in a death. Only your pilot being killed or ejecting results in a scored death/scored kill. I'm not even sure it was intentional to change it. The old conditional logic is solid and worked well.

Nope. New PC since then and I'm using the network adapter on my z390 MB now.

Sure. But it used to work just fine, and fixing it seems quite simple and straightforward. Unless there's an obvious reason not to that I'm missing.

Reinstalled Windows and did a fresh download of DCS. Fixed the stutter. I seem to still have the timeout issues. Are there any conditions in which either DCS or Windows would voluntarily terminate a network connection? One thing I've noticed is that before the "server ping timeout" disconnect, and while DCS is reporting increasing packet loss with the server, only certain connections are failing to communicate. For instance, I see all units on the server as stationary, yet MP chat still works as normal. As though a specific connection is voluntarily terminating and causing the disconnect. Doesn't happen all the time. Seems potentially connected to high unit counts, but I'm not 100% sure since the same server will be fine sometimes and not fine other times. I also added an additional 32gb of ram bringing me up to 64gb total. This doesn't seem to have any effect on timing out.

Leaving slot anytime you weren't stationary on the ground at a friendly airfield used to count a loss. Unless there's a good reason, I don't see any reason not to revert back to this system.

Has there been any update on getting this issue fixed? I haven't seen it officially addressed, but perhaps I missed something... All I can find is ED communicating not to use shared parsers, which doesn't seem to really address the issue. Regardless of having shared parsers enabled or disabled, all we're changing is the type of rendered objects/effects that display in one eye only. In either setting, there are specific things that only render in one eye. Having to choose between rendering the game so that I see clouds/contrails in both eyes, or rendering the game so that I see the same object lod in both eyes is an aggravating choice.

The new menu stutters for me as well. Quite annoying. The old menu didn't stutter. I miss the old menu.

Done. I don't think there was stutter.. but I'm not sure it's a good indication without VR. The stutter occurs mostly while quickly looking around outside the pit, especially when transitioning from looking down into the pit to looking up at the world. Other VR apps do not show the same stutter, nor does the DCS main menu stutter. However, while refreshing the server list, I do get stutter.

Thanks for the response. Disabling IPv6 seems to have fixed the network issues. As far as the stuttering, I do not run Malwarebytes, so something else is the culprit.

Along with intermittent stuttering, I have recently started suffering from crashes to server menu after being connected to a MP server for a short period of time. In the client stats, this is always accompanied by a period of growing packet loss. I can't explain this packet loss on my network, and only DCS seems to be reporting it. Separate issue (maybe): constant stuttering. Began a few weeks ago after migrating DCS to a new SSD. Before this I never suffered from stutters. Attached log from a recent ping timeout occurring on Blue Flag Syria. Thanks. dcs.log

I found that setting an FPS limit in an autoexec.cfg or direct edit of the grpahics.lua greatly reduced the consistent freezes I was experiencing. Same symptoms: decent FPS being interrupted by sudden drops.

I think the big underlying issue here is that in-game chaff effects radar guided missiles the way flares effect IR seeking missiles. A fox 1 lost to chaff against a target that never broke your track often flies through a specific chaff bundle the same way an IR missile would a flare. Your radar track never even looked degraded, but after that Fox-1 picks a chaff, you're never going to get it back. Clearly that doesn't add up for semi-active radar guided missiles. In several different regards. Interestingly, you see this the other direction as well, when an IR missile that had good tone fails in the last moment to track a low slow flanking target. As if IR tracking were somehow degraded by a slow notch. Hard to say for sure. What's clear is the logical inconsistencies in the way many missiles behave. We shan't get into the guidance updates an unsupported Fox-3 receives before the active seeker turns on. But in all fairness, there have been some major improvements made recently.

You see the same behavior with A2A IR missiles in MP against low and slow targets. Mostly against helicopters exactly as it is shown in these examples. You'll get a "good" tone, and yet often it will inexplicably veer away in the last moment before impact. I say a "good" tone because who really knows. There's clearly some IR detection/tracking calculations/coefs that don't seem to represent themselves well through the seeker warbling at you. Feels much more yes/no in terms of seeing the target, where 'yes' isn't a strong indication of ability to track the entire way, despite sounding very solid. Again, specifically problematic against helicopters and others flying similar profiles. I've found I often have better luck just shooting the missile without a lock tone and letting it find them after launch. Perhaps this bypasses the mechanic that causes the strange behavior, but I really can't say for sure. Just my two cents. Perspective here is from only MP only, can't say if SP sees similar. I'd guess this issue is predominately occurring in medium-high unit count MP missions with at least several clients, and effecting more IR missiles shot, from both clients and ai, than just the stinger.

I have noticed the same, and also cannot quantify it. Objects above or below the horizon feel as though they just fade into the background.

You are seeing the Link16 ID of the PPLI entity that is tracking that trackfile donation. It is beside the point that it is also a PPLI track. A PPLI networked friendly is tracking another PPLI networked friendly. You'd see the same ID on a non-PPLI trackfile if a PPLI networked friendly was donating it to you.

It has always felt to me that blackout onset used airspeed twice in its calculation. The onset rate to total G load with account to duration is the only thing that matters, yet it has always appeared that the same onset rate to the same G load produces blackouts faster when the airframe is moving more quickly. This shouldn't matter since you're already calculating the G load and onset rate. I could be wrong, but this is my observation and experience. More broadly, ultimately, blackout onset is tricky since we can't control it as virtual pilots and in reality it is very much pilot dependent. If I could get an edge by training my own G tolerance, then you can bet every day would be leg day.

<64>YAGA Mig15

Given the current bugs, the Phoenix would behave much closer to reality as a Fox 1. Other Fox 3s share the problem, but only the Phoenix has the energy to make it truly problematic.

I know you guys are working hard. If a test on the 54 is done, it needs to be done in an advanced environment with quite a few players where air supremacy is the objective and not necessarily getting down low, involved and merged. It's the 25nm-60nm ranges where you should be able to keep your speed and alt against a Tomcat and "fly around the fight" by breaking lock, disappearing by lowering closure, while flying a new heading. Effectively "sidestepping" the missile. As it currently stands, you cannot do this, as once the Tomcat loses lock or TWS tracking, the missile still flies out to you via pure pursuit, meaning its energy is good against your alt and potentially dangerous regardless of heading changes. There's no getting around it even if you haven't seen 14 on the RWR for quite some time (often up to a minute later) and have taken a drastically new heading. In practice, this means once you're launched on, you will at some point have to defend hard or go completely cold. Suddenly pitbull'd Phoenixes without prior recent nails are also hard to assign a shooter. It could, logically, be any Tomcat within Phoenix range that's looked at you in the last minute. Not being able to determine the shooter aircraft means you can't determine the energy the missile is reaching you with. For safety, you must assume it is the closest Tomcat and defend accordingly. To act as though every Tomcat that has looked at you, however briefly, has shot means surrendering your posture and initiative needlessly a lot of the time. In contrast, if no nails, no pitbull, meant no missile support, this wouldn't be an issue. In this case, it would only be Tomcats who are still looking at you that have shot a missile. A much lower number. Inside 15nm, a Phoenix launch behaves the way I'd expect. I understand why 15nm was chosen for the active range and I largely agree with this. Fox 3 INS bugs don't exist once the missile is active.

Mike, I think there are many implications you're not considering. While all Fox 3s suffer this problem, the Phoenix is especially problematic on the shape of the fight at medium range. If you have time, I'd be more than happy to go up on BFPG in Hornets and compare/contrast in real time the calculated aggression we should be able to safely wield against the Tomcats vs the amount of aggression we can safely wield. You will hopefully see that there is a huge difference and that it is entirely due to the INS bug and pre-pitbull launches when applied to the insane energy and range potential of the Phoenix.

The effect of the current implementation is that by notching pre-pitbull, or otherwise breaking the Tomcat's track and attempting to trash the missile early, you're actually making it track better by inducing the INS bug. So either he's able to keep tracking you, or he's not, but you're going to have to notch eventually or die. The only real solution is denying him detection of you in the first place and preventing any shots at all. The missile is far from where it should be, and the effect on MP combat is miserable. At this point it should just be set as a Fox 1 until HB can model it correctly.

Great matches this weekend!