Jump to content

Yaga

Members
  • Content Count

    108
  • Joined

  • Last visited

About Yaga

  • Rank
    Member

Recent Profile Visitors

2740 profile views
  1. 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!!!!!!!!!
  2. I own the very same nefarious router! I will set QoS on and give it another run.
  3. 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.
  4. 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.
  5. 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.
  6. No luck. Full log attached from 2 hour server disconnect. dcs.log
  7. 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.
  8. 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
  9. 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
  10. 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.
  11. 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
  12. 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 int
  13. 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 s
  14. 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.
×
×
  • Create New...