@Geez Any updates to this?

@Geez, can you please provide some clarity as to the meaning of "scheduled for a fix"?

This is due to desynchronization between client and server side CommandHandlers. Certain actions are blocked (or otherwise informed) by checks which are performed only on client or server, and once the two are desynchronized there's very little that can be done to fix it. There were "hard actions" like surrendering, passing out, etc which helped in the past but it seems like engine changes have prevented that from being effective anymore.

In T166463#2336226, @Geez wrote:

Thank you for the report mdc.
This is a known problem and it will be looked into.
Regards,
Geez

In T165909#2330929, @RedFalcon wrote:

Yup, got that sorted so this particular issue is resolved. Now to get the keybind menu to scroll instead if cutting off excess tabs.

The <sorting> block needs to go into the <inputs> sub-block, not directly into <modded_inputs>.

In T150113#2330495, @Yuki wrote:

Maybe better

In T150113#2330485, @Beavis wrote:

Well look at that, I took MDC's script above and applied it and it works flawlessly.

Update following further testing; it appears that exiting to main menu and rejoining the server fixes the issue, and therefore does not seem to be linked to DirectSound capture and may instead be networking related.

Confirming this; a noise gate should only be applied (if at all) when the voice activation feature is enabled.

In T157566#2176019, @Turkeylova wrote:

Look's like you community admins got your way by harassing Bohemia Interactive, threatening legal action, and sh*tting on official servers.
Congratulations.

In T157566#2172940, @Geez wrote:

Can you please let us know on which server are you experiencing the problem? And if on official, can you please provide us with some kind of video proof? As currently the data we have points towards this possibly being an issue with a mod.

Hmmm, what exactly are you trying to do?

I can confirm that it *does* work; we implemented Push To Talk on Kinship the day 1.10 was released. You need to ensure that you're calling SetSynchDirty() on the transmitter after setting the broadcast states.

In T155184#2132796, @Geez wrote:

Hello everyone and thank you for all your feedback and the information provided.
We have indeed found several issues which could cause the problems with performance as you describe and they are being looked into internally as our top priority and we will attempt to resolve this as soon as possible.
Regards,
Geez

In T155184#2131789, @FutureSixx wrote:

I’ve done a vehicle wipe 2 days after 1.10 release, had about 40 vehicles, and I saw no difference in server FPS. After combing through 1.10, learning everything it’s introduced, I feel this is just the side affect of its new features. hopefully in future updates they can optimize these new features, because this is a very negative side affect we are experiencing.

Further update:

As reported by the OP, a significant contributor to this issue is the Food Decay / Cooling system. This is *not*, however, the only factor. Disabling it will definitely prolong the time it takes for these issues to be felt, but we've had to switch from a 6 hour restart cycle to a 3 hour one - as well as disabling the new systems - in order to maintain a playable environment.

Can also confirm this issue.

Unfortunately I can also confirm this bug.

Containers themselves (pouches, medkits, etc) are only a factor when they're attached to something that inherits from ClothingBase, as the CanReceiveItemIntoCargo checks go up the hierarchy to parent objects, so if - for example - a bag has a Protector Case attached to it, the Protector Case will return false because its parent - a clothing item - returns false.

This has become *extremely* important given the changes to CanReceiveItemIntoCargo and CanPutInCargo with 1.08.