URFIR3D

Hey @Xthedarkknight99x did you ever find a way to make it run better, I'm also on a 8700k at 4.7 and having the same problems you were.

Not sure why we have so many people concerned about “fault” in the thread. It’s a relatively minor bug and certainly not game braking that probably happened trying to fix other stuff. I can see how this can be missed in testing. No big deal. Also, it wouldn’t be something ED would fix anyways even if it was their “fault” since it’s in HB module, so guessing cause here wouldn’t really be helping the devs. Just makes it sound like we’re trying to assign blame instead of simply notifying the devs of a bug that was identified. So no worries guys, thanks for addressing it. HB, thanks for owning up to it, but seriously don’t worry about “faults”. Keep up the great work.

When attempting to adjust the console and instrument lights intensity using a keybind to a keyboard or MFD the increase stops at 3 and decrease goes down by 3 at a time. This is a new behavior with this latest patch that's a bug. At this time actuating the console/instrument lights really only works by using the mouse.

How would implementing the digital screen affect the release timeline?

Anyone try to buddy lase? Seems broken to me right now. I arm LTD/R, click TRIG on MFD, and pull trigger, it goings from "L ARM" to "LTD/R ON", so laser should be firing, except it's not actually. Buddy with an AGM 65-E won't see a laser. Funny enough if I drop a GBU-12, and the auto lase comes on, that's when they see it. So seems like you can't manually work the laser anymore, which means no buddy lasing. Please advise if you can replicate or you experience something different. I'm using a TGP and GBU12s, buddy was using Laser Mavericks. They didn't have a TGP so we never tried LSS.

https://forums.eagle.ru/showpost.php?p=4122938&postcount=31

If you find my post you can simply block the device that’s causing the problem via your windows firewall without knowing exactly what that device is, you’ll just know the IP, and just block that. My post is somewhere in this thread.

You can't terminate the process, instead you should find out what IP is communicating on that process, then use your windows firewall to block communication from that IP. Refer to my previous post.

Have you looked into the dashost.exe process mentioned above?

I know this thread is old, but seems there are still recent posts and this was afflicting me too. So I thought I'd share my fix. I used the system resource monitor under the task manager and used it's network tab to monitor for suspicious traffic. Sure enough during the lagspikes it was the app "dashost.exe" that @ryak84 mentioned in this post and his own threat. I checked that box and looked in the network activity section, in the next spike it told me which IP was actually initiating the connection. I used NMAP to identify that it was one of my amazon firestick devices, (for Ryan it was his TV). Ryan simply disabled the smarttv features on his TV, but I didn't want to get rid of my Fire Stick and I can't disable whatever feature was causing it to ping the network. So instead I set it to a static IP and I created a firewall rule in windows to block all traffic from that IP. Boom problem solved. Just wanted to say thank you again to "ryak84" for giving me a good lead on this.

Bump! Can anyone confirm this behavior?

So the bug with the clicking and weaker sidearm noise after firing has been resolved. But now there's another bug. When you first turn on the sidearm you get a standard low pitch tone. As it finds a SAM and begins locking on, it becomes a high pitched tone, then finally locks on and switches to a third tone. After firing, all your remaining sidearms will have that second high pitched tone no matter where you are pointing or if there are SAMs around or not. Switching to the gun, or any other weapon, and back to the sidearm does not fix it. This makes finding new SAM sites much more difficult.