Here's a way to reproduce it fairly reliably:

OnStoreSave can be used as an indicator when a player is saved.

Land_Mil_AircraftShelter

It seems the underlying issue might be some sort of memory corruption. I'm attaching a crashlog + minidump in case it's helpful.

In 1.25, the problem seems to have gotten worse. It's now enough to look at the lighthouse for CTD to occur.

Maybe it's the if (handle == 0) check that makes it fail? Could a valid (non-NULL) FindFileHandle be implicitly cast to a zero int by this comparison, thus making it fail?

The way I understood FindFileFlags is that it tells FindFile where to find files, not what type of thing (i.e. directory/file) it should find. I'm basing this off the code comments in ensystem.c, so not sure if those are correct w/ regards to intent (it also mentions .pak files which are not a thing in DayZ, probably a leftover from Arma. I haven't checked if FindFileMode.ARCHIVES does attempt to find files in PBOs).

The flickering has been back for the last few DayZ updates (currently on 1.25 and it still flickers).

Some more (Storozh aka Prison Island), coordinates are shown on screen (I suspect Infected can walk through any of the bars in the prison buildings, but I haven't tested all of them):

@aldworth33 that's a different situation, for dynamic objects navmesh takes a while to update (up to a few minutes). The objects in this ticket are baked map objects though.

Ignore, issue was Summer Chernarus which isn't updated yet for 1.25

Nope, it affects all fonts, see screenshot, that's SDF_MetronLight

The issue isn't writing, the issue is reading.

What type of data the serializer will covert to binary representation? CChild object or CParent?

The old behavior (requiring -doactionlog parameter) was fine. It still hasn't the right format for admin log though, as the info provided is mostly useful for debugging, not administering a server. To make the log useful, it would need to include the name + ID of the player instead of the survivor classname (+ the position).

Oh they are evaluated, they just can't be OR'ed together. Using a single constant or enum works absolutely fine as default argument.

This ticket seems to be based on a misunderstanding of how the serializers work in DayZ. For the serializer to know how to read something, it needs to know the structure of what it is reading, since written serialized data is just a binary blob with no structural information whatsoever. Class obviously lacks any structural info that the serializer could use to make sense of the binary data it is reading.

I've created a new ticket for the freecam freeze & CTD as I'm not sure if related. https://feedback.bistudio.com/T179875

I've created a new ticket for the freecam freeze & CTD as I'm not sure if related. https://feedback.bistudio.com/T179875

A similar client CTD can be provoked by entering freecam and moving freecam close to or below ground while a nearby player is shooting, and I'm assuming it's due to the muzzle flash.

Minidump
Mods: @CF;@Community-Online-Tools

To add to this, this also affects mods that want to support eastern languages. It is currently very cumbersome to support eastern languages with the same layout files as used for western languages and is mostly due to eastern fonts rendering much larger in DayZ (about 1.5x to 2x visually) than western fonts. It would be great if the eastern fonts in the game would render about the same size (given a respective point size in layouts) as western fonts, thus eliminating the need to have separate layout files.

That doesn't seem to be the case. I see emote logs even without that parameter. Or do you mean it has to be added so emote logs no longer happen? The call to the log doesn't seem to depend on anything else than -adminlog (I can see that versions prior to 1.24 indeed depended on LogManager.IsActionLogEnable, but that's no longer the case with 1.24)

This needs to be revisited. It is impossible to anticipate which other mods add actions, so you can very easily run into a situation where mod A adds an action and mod B adds an action that both work fine in isolation, but when loaded together, only one of the mod's (A or B) action will be selectable. Due to the exponential amount of possible combinations of mods loaded, it is impossible for any individual mod author to circumvent this situation.

Not the behavior in C or C++, which is what I'm going off of. But I guess in C or C++ the compiler actually recognizes the initial value as an uint, so non-negative.

Thanks for the detailed answer (and resolution of course) :-)

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.