Yaga

I agree word for word. Hoping the eventual radar white paper outlines the calculations being applied, the rational behind choosing them, and some evidence that the method applied produces results that agree with available data. Bonus points awarded if it goes as far as evaluating areas where there is discrepancy with RL data and potential ways to reduce it as development continues. Great. Thank you!

You're asking for evidence of what exactly? The team needs confirmation that rotorcraft have unique radar signature characteristics compared to fixed wing aircraft? We can definitely find such validation, but we could probably just show them a picture of each type of aircraft and have the same effect. If we do go and confirm that yes, there are unique attributes to Helicopter RCS in the real world, then what? It isn't relevant at all within DCS. That data doesn't exist to drive any simulated outcomes. The functions that would conceivably carry and use this data don't exist either. Just like the RCS characteristics attributable to pylons and stores in the real world, they don't factor in. This has.. some effect on accuracy across all the results it generates. Here's two works proposing methods for modeling helicopter radar signatures accurately, validated against real world measurements. Radar signature characteristics, unique to helicopters, are briefly covered in both: https://www.researchgate.net/publication/350770098_Modelling_the_radar_signature_of_rotorcraft https://www.researchgate.net/publication/336073108_Parametric_modelling_of_the_radar_signature_of_helicopters This aren't usable methods here, I don't think. But it is the requested evidence showing that helicopters are not airplanes. I suppose that's something.

I get that "easy to pick up" is unquantifiable, but this is a pretty simple assertion and it's strange that you'd dismiss it, in its entirety, so quickly. It's also hard to source something proving that the radar "works" or "doesn't work". DCS isn't an EM simulator and no one needs it to be one. I understand the desire to create accurate organic outcomes and I do think conceptually this is a good ideal. However... It has to work well. Simulated outcomes are great since you can't script an outcome for every situation conceivable. But if the system in place doesn't even generate reliable outcomes for situations that are common enough to be scripted, then you really haven't made any improvement at all. In fact, maybe the ecosystem has become so convoluted at this point with its myriad of coefs and formulated relationships that it can't even be adjusted easily anymore. When I use the radar in the F-18 or the F-16, I find it to be an absolute unmitigated nightmare of inconsistent and unreliable results, capabilities, and behaviors. In fact, the topic of detection ability only scratches the surface of the enormity of all the problems with processing logic, the general avionics presentation, workflow and just about every other area one must tediously slog through and overcome in order to use the radar as a radar. So when someone asserts something should be "easy to detect", it's hard to know where to even begin when the entire sum of environmental and systems modeling is working against them in nonsensical and illogical ways. Generally speaking, and almost certainly for our purposes, Fire control radars work. Modern weapons track. If they didn't, we'd develop ones that did. In fact, that's exactly what occurred over the last 60 or so years. If the deep simulation approach is to be continued, then you can't cut corners. Abstracting relationships at any level is ultimately abstraction, and any of that begs the question "after all this, aren't we still just scripting the outcome with so many extra steps?" Here's some citations for some research regarding helicopters and signal processing. The amount of existing material on the subject and related subjects is quite extensive, so there's plenty to read. I trust, given the scope of the project, that you have access to an academic DB that will have these journals: Thank you,

No, there's definitely something weird going on. I also use the FSSB and absolutely know the unstable wobble you're describing. Also seems to happen during AAR on occasion. In the comment above, it's suggested to correct with pitch rate trim. That's a bit odd and seems like a symptom that something else isn't quite right. . Reduction above 10deg AoA might be too aggressive. The opposite might be true under 10deg AoA. This could make your nose feel heavy at 11deg AoA and light at 9deg AoA with extremely unstable response to input as it transitions between. It does feel a lot like a feedback loop. An induced oscillation from a far too negative curve. As far as FSSB settings, I found that reducing the max pitch force helped a bit.

Looking forward to it!

From what I've been able to reproduce, this is the issue exactly. If anyone on the server uses the unavailable range, it interferes with Link 16. Interestingly, it also appears that it effects both teams. If anyone, on either team is using the unavailable range, everyone within line of sight to that player experiences Link 16 interference, even if they are on the other team. This is likely why the original poster reported that during a match, everyone on the server reported the problem after takeoff. We experienced an identical situation during a match recently, and while nobody on our team had set an a2a tacan, the opposing team did have an A2A tacan set in the unavailable range. Edit: to clarify, A/A channels (1-36, 64-99) cause Link 16 and PPLI interference. T/R channels seem to have no effect.

<64>YAGA F-16C

You might be pleased to know that this completely solved my disconnect issue. It even seems like the game runs more smoothly in MP now. :thumbup: Thank you!!!!!!!!!

I own the very same nefarious router! I will set QoS on and give it another run.

As far as I can tell, it's all servers for me. And as stated, like clockwork after a 125 minute connection. I just can't find any evidence to suggest what's happening.

I just disconnected again after ~125 minutes. Both my local and public IP addresses have remained the same before/after the disconnect. No errors in the DHCP events that would correspond to the disconnect time either.

Interesting, I'll call up my ISP. Thanks again for helping me diagnose this issue. Edit: I've also enabled the DHCP logging, and have noted my current public IP. I'll check to see if it changed after my next disconnect.

No luck. Full log attached from 2 hour server disconnect. dcs.log

Power management has already been disabled. I just went ahead and disabled IPv6 and set the autoexec to have DCS create full logs. Testing now.

Most of the servers I fly on don't use these units. There doesn't seem to be any effect not having them. Also, page file increase had no effect. Most recent log attached. First disconnect the timeout issue, second disconnect intentional. Again, right at the 2 hour mark. I recall a autoexec.cfg line that someone said would enable "full logs". Can't find the post now though. Do you know anything about this command? Seems useful to get whatever additional data it might provide. dcs.log

I tried this, and it doesn't seem to have any effect. Good find, though, it sounded promising. I still reliably lose connection after 2 hours, every time, on any server. Recent log attached. First disconnect is connection time out, second disconnect is intentional. I've increased my pagefile size, we'll see if that has any effect. 20201112.log

I don't see anything obvious. The only error that gets thrown is when my jetseat shuts itself down (happens after DCS.exe terminates, so this isn't the disconnect issue). Is there something specific I should be looking for? Seems like in the DCS log, the disconnect from net event always occurs shortly after a "DCS World simulation is taking 100.0% of CPU" event.

Issue seems to have returned, not sure if related to most recent OB patch. After about 2 hours server connection times out reliably. Log attached. dcs.log

That's good to hear.

Me too. Two weeks isn't too long a time to wait for a fix. Since you've rigorously ruled out the interests of MP and competitive DCS as at all suggestive of the larger community, who would you specifically point to for which this mishap is a good outcome? Yes, you would receive an indication representative of how you were engaged. Our Phoenix terminally engages under active guidance. You are correct, if you currently launch an Aim-54 at a spiked target and maintain that spike until impact, your target will only ever receive your spike. But when your missile can complete its intercept with no indication from either you or it whatsoever, I can't imagine why on earth you would.

Are you sure? All other missiles seem to produce active warnings as expected. The Aim-54 reliably doesn't, specifically it seems when fired at ranges where the seeker is not going active off the rail. Could this be another instance of a universal missile 'problem' that is only noticeable when applied to something unique about the Aim-54? I recall back in the day when the desync was terrible, it was technically true that all missiles desynced. But desync increased with time of flight, and since in those times Phoenixes were still lethal at triple the range anyone else was even considering shooting for, it wasn't a problem with other missiles.. It was a Phoenix problem. Seems to me the "stealth phoenix" is a really bad outcome in the course of developing this thing, and I'm sure most people would like to think there's some urgency in solving it. Maybe there's some stop-gap or band-aid that can be used to mitigate the problem while you're waiting for ED.

Not sure how it's not able to be reproduced. Since this bug appeared a few patches ago, I haven't had the tgp slew the target designator correctly once.

As of recently, if you leave a server and rejoin, it will remember your old score but initially show 0 in all columns. The next a2a/a2g kill you get will refresh your a2a/a2g score, and the next death you get will refresh your total deaths. I suspect this update to persistent scores/server session was what inadvertently changed the way kills and deaths were scored.

I don't see anything to suggest this issue. Xcom updated the mission a bit and it seems like my problems went away. As far as I know, the change was just a reduction in unit count. As I said before, BF Syria was the only server I had any issues staying connected to. Not sure why it effected some of us more than others. I guess without really knowing how the dedicated server handles traffic, it's hard to say why it was spontaneously stopping UDP traffic from the server. But some condition exists in which it will do this. I appreciate you spending time troubleshooting this with me. :thumbup:

I noticed the other day that with it enabled, aircraft lods would disappear in my left eye at around 5nm unless I zoomed in. They were still plenty visible in my right eye. I realized that this is why it's felt like aircraft I've visually tracked have been phase-shifting in and out of existence. That's what I mean when I say we have to choose between clouds/contrails in both eyes, and lods in both eyes. Either choice is terrible.