No, it's very much related. The muzzle index being wrong on load is just an effect of the bug.

It looks like FileMode.APPEND does not work under Linux, the file is seemingly overwritten if opened in that mode. Note that I'm basing this off logs and files that people have sent me, as I currently don't have a Linux testing setup. If you want to test this theory, put this code into your init.c (e.g. at the bottom of the main function):

To share the information I have up to this point, the issue seems to be related to FileSerializers. It looks like they cannot reliably be written, and maybe also not reliably be read, under Linux. The failures seem to be silent during the actual write/read, i.e. the game doesn't print or otherwise hint at anything being wrong, which is why the effects of these failures crop up later when the read data is attempted to be used.

There is no such thing as an uninitialized variable in EnforceScript. All variables are initialized to a default on declaration if there is no direct assignment (bool false, float 0.0, int 0 , string "", vector "0 0 0", anything other NULL), and this is a core language feature. Think Java/C#, not C/C++. The above example is valid code and completely fine. If that indeed crashes under Linux(?), that's a bug that needs to be fixed on that platform.

Now let's get an overview of how many of these servers that are having problems are running under Linux like the OP.

Nope, it was never fixed

Vanilla PlayerBase::CommandHandler, line 2990 (1.27):

This is not my code, that is vanilla code. The vanilla PlayerBase::CommandHandler uses the stale pCurrentCommandID.

Turns out the health config was a red herring. I've updated the ticket. Here is a PBO to easily repro the issue:

@Geez any update on this now that we have steps to repro?

The log files won't help. To figure out which item(s) have the problem, pack the following code into a small servermod. It should then print the type of the item to crash.log:

This has nothing to do with Expansion. The failure in this case happens in vanilla Liquid::GetBoilThreshold, and the reason is that another mod's item has an invalid varLiquidTypeInit value (i.e. a value with no matching entry in CfgLiquidDefinitions). There's no NULL check in the vanilla Liquid methods, which then leads to the failure.

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.