Interim solution

modded class ActionStartEngine
{
	override void OnStartClient(ActionData action_data)
	{
		super.OnStartClient(action_data);

In T177400#2535739, @markkoky44 wrote:

Adding on to what @lava76 mentioned.

* Order of Events firing:
* When player respawns                            : ClientPrepareEventTypeID ► ClientNewEventTypeID ► ClientNewReadyEventTypeID

The reason for this seems to be that the player list is sent to all clients whenever a player respawns - at this point that is wasteful though, because the playerlist hasn't changed. The underlying issue is that ClientNewEventTypeID fires for new players (where sending the playerlist makes sense since it has actually changed) as well as respawning players (here, the playerlist hasn't changed).

It seems the gun was already deleted on server when DayZPlayerCommandDeathCallback::OnSimulationEnd is reached so it cannot be dropped, what remains visible on client is just a "ghost". This also explains why cutting up the body doesn't help.

Even easier way to repro, just dig a gardenplot and drop the item on there.

Video showing item teleportation issue:

Seems to be fixed with today's Experimental update

One problem might be that the variables (according to docs) set updates to be sent per server frame, not per time interval. So with networkObjectBatchSend set to 3, that might still amount to hundreds of updates per client, per client frame, depending how fast the server runs at any given point in time.

I don't see how one is related to the other. The clothing changes would have been "nice to have" certainly, but not having them doesn't break anything. The "FIX-ME" warnings on the other hand point to actual problems (that modders should address if they are affected).

No mods needed, it's enough to spawn one of the SurvivorM_* or SurvivorF_* characters (e.g. using CreateObject) and give them a full set of clothing (head/shirt/pants/boots/backpack/belt) via GetInventory().CreateInInventory(), there should be at least one of the clothing items that will not render in unless you get closer. I think players may also be affected as long as they don't move but have no way to confirm this currently.

+1 for keeping the change.

This is fixed in vanilla since 1.19 for anyone reading this.

Awesome!

Bummer, because when mods do add their actions, it's impossible to anticipate what other mods add what type of actions. It's only possible to really anticipate this when staying within the same mod.

Can definitely reproduce and confirm freeze/desync/teleport issue when player changes stance while attached to vehicle (using LinkToLocalSpaceOf). I noticed that jumping/falling onto a vehicle while already crouched/prone does not cause the issue, it's only caused by changing stance.

Looks like it's fixed in 1.19 Experimental.

@Geez sorry for the ping, any update on this?

Work-around for comparison:

The problem is not infinite recursion.
The problem is that 1 < -2147483647 should NOT evaluate to true, ever (or any other positive non-zero number that's in-range for a 32-bit int).

Follow-up: Because all vanilla inherited cars call super in EOnPostSimulate, this also means they have double the fuel leakage than intended.

I've attached a minimal example modding a non-existent class. If this PBO is loaded with at least one other mod (this seems to be the important part), then the filename in the error message points to last line/EOF of some unrelated script.

I was half wrong actually, literally. There is only one NULL pointer key needed in the map for it to be not removable with map.Remove(NULL), as that would try to remove literal NULL from the map, not the key that originally pointed to an instance, but now points to NULL. Effect stays the same though.

And the underlying issue is this: https://feedback.bistudio.com/T166724

A temporary workaround until this is fixed properly is to override MissionServer::UpdateLogoutPlayers:

This bug can be fixed by removing ignorepointer=1 from alternative_bind and alternative_clear in gui\layouts\new_ui\options\keybindings_selectors\keybinding_option.layout, essentially reverting it to the (correctly functioning) 1.17 version.

IsInVehicle() started checking for parent transport in 1.16.

In T154093#2144684, @Helkhiana wrote:

With 1.10 update it was made actually again worse because I cannot override just a couple scripts, I have to override the whole ItemBase folder. This means any updates from DayZ in that folder I must update mine as well...

This should be enough for 1.10 and is what I'm currently using:

@Geez any ETA on when the current fix in Experimental will appear in stable?

No issue for me with the mods I run in Experimental. I would be very happy (well not only me I'm sure) if the current fix in Experimental would appear in stable soon.

@ukulelekid713 it's not related to VPP or any other single mod.

Latest Experimental looks like it did the trick. That's a huge relief. It allowed me to add the three mods back in that I previously had to deactivate, plus some more.

Thank you @Geez.

No change with latest Experimental for me unfortunately.

Moving code from 4_World into 3_Game definitely helps mitigate the problem, as does getting rid of any JsonFileLoader usage. What I also found helps is grouping all mods that use JsonFileLoader and load them last, after other mods. Hopefully the cause(s) for these freezes can be found and a proper fix be implemented.

You are wrong. Also, like I said, there's no mods making containers nestable to begin with.

Some mod objects was allowing someting like this: Container inside container attached to container inside container attched to container ...

The recursive weight calculation doesn't seem to work as intended. Fixable by modding: