Yeah not had any issues following 2.12.

Thanks to @JonBons2020 think we've figured this out.

Checked on stable, works as expected (doesn't fire the EH on glass break)

I personally have a scripted solution that fixes floating bits after building destruction so it doesn't impact me, however just because your usecase wants this by default, others might not. As KZK said, it's not getting implemented so it's a mute point.

If an object was placed floating, I'd rather it was kept floating. Admins/mission makers can script the rest, deleting stuff is undesired.

Ideally I'd like the ability to this on a per unit/vehicle basis. Some scenarios perhaps where players and AI are intermixed, you don't want them to get in to a vehicle and suddenly have a logo appear on the side etc.

Found memory issues, hardware related. Closing.

Issue persists in 1.74

Issue persists in 1.66

Removed -serverMod=@ASM to ensure it wasn't invalidating the test, no change.

Tests carried out on a Windows Server 2008 R2 machine.

Adjusted the HC launch options and tried other combinations to see if it was based around the -nosound flag but no changes.

Still occurring in 1.64

Still on-going in 1.64

Close this, no longer happening.

Linking back to corresponding forum thread

Still on-going issue in 1.62, @Killzone_Kid are you able to help @Adam reproduce this to get it resolved?

Tested in 1.56 stable, working as expected!

Oukej, what server/client version were you using for the tests?

That happens when they are fleeing

Is that expected behavior? Seems counter to the actual act of fleeing, standing still is the polar opposite?

Honestly it's been a while since I was on dev branch but I didn't think there was a proper dedicated server build available (this only occurs in dedicated environments).

Is there an appID I can use in steamcmd to build a test box?

Edit: Did some more reading and got it working, seems to work fine on dev branch, no issues at all. Guess we wait for 1.56 tomorrow in stable and see how it works out there.

Just to clarify, this happens regardless of how the waypoints are created.

Scripted / Editor placed both have the same issue, assume it's a engine problem somewhere.

Ok but the point is that we don't need that level of debugging in the general RPT because anything that cleans up on a large scale will generate way more entries than this test with just a single client connected.

With this example can you trace it's origin and remove the unwanted diag_log/logFormat calls?

This is a needed fix!

Thanks for the info F2k Sel :)

Restested in current stable version (1.54), still an issue.

Attached a file.

Red + indicates my viewpoint and where I started firing from, this was three 100 round mags, never un-deployed or went in to iron sights.

Any chance of stable getting a hotfix for this on stable or are we waiting for 1.42?

Interesting, this seems correct, if I check the values via script from the server it has the same values as the editor...

Edit: Removed additional fluff, seems that this is working server-side only just not propagating to clients as written by Wolfenswan, however his bug is muuuuch more game impacting than this!

Restarting dedicated servers on a regular basis mid-session isn't really acceptable to just switch terrains. Seeing same errors as above.

Still happening with most recent stable (1.36)

Nearly a year, can we get an update on this please.

This has been open for over a year now, how about an update on the progress.

Thanks ChuWie, that's a nice temporary solution, will be using it for now!

Bump on this issue as we really shouldn't need 3rd party software to do this.

This is reaching new levels of annoyance once combined with ACE's interaction system where as the medic I managed to minimise the game by accident a staggering 18 times last night.

Also Mousenitor doesn't work under Windows 10 so my bandaid fix doesn't work anymore. Can anyone seriously have a look at this? Wasn't a bunch of UI scripting commands put in recently to do with cursor/UI implementation, is there anything in there than can help?

Agreed, it would be nice to see this fixed as currently every time I press inventory in a rush I accidentally click off the screen and minimize my game.

Can we not just set the maximum area of mouse travel to match the game resolution?

Tested this in full screen windowed mode to see if it would lock the application. It still doesn't keep focus.

Who knows?! Angry person, give us your reasons!