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.

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.