User Details
- User Since
- Jul 7 2020, 12:14 PM (230 w, 2 d)
Tue, Dec 3
Sun, Nov 24
Here's a way to reproduce it fairly reliably:
Nov 5 2024
Oct 31 2024
OnStoreSave can be used as an indicator when a player is saved.
Oct 13 2024
Land_Mil_AircraftShelter
Sep 28 2024
Sep 5 2024
Aug 22 2024
Aug 9 2024
It seems the underlying issue might be some sort of memory corruption. I'm attaching a crashlog + minidump in case it's helpful.
Aug 8 2024
Aug 4 2024
In 1.25, the problem seems to have gotten worse. It's now enough to look at the lighthouse for CTD to occur.
Aug 3 2024
Jul 29 2024
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).
Jul 27 2024
The flickering has been back for the last few DayZ updates (currently on 1.25 and it still flickers).
Jul 25 2024
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):
Jun 12 2024
@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.
Jun 3 2024
Apr 27 2024
Apr 24 2024
Ignore, issue was Summer Chernarus which isn't updated yet for 1.25
Apr 23 2024
Apr 3 2024
Nope, it affects all fonts, see screenshot, that's SDF_MetronLight
Mar 23 2024
The issue isn't writing, the issue is reading.
Mar 22 2024
What type of data the serializer will covert to binary representation? CChild object or CParent?
Mar 17 2024
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.
Mar 16 2024
Mar 13 2024
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
Mar 2 2024
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.
Feb 28 2024
Minidump
Mods: @CF;@Community-Online-Tools
Feb 26 2024
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.
Feb 23 2024
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)
Jan 30 2024
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.
Jan 25 2024
Jan 18 2024
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.
Jan 16 2024
Thanks for the detailed answer (and resolution of course) :-)
Jan 15 2024
Jan 13 2024
Jan 9 2024
Jan 8 2024
Dec 5 2023
Interim solution
modded class ActionStartEngine { override void OnStartClient(ActionData action_data) { super.OnStartClient(action_data);
Dec 4 2023
Nov 29 2023
Nov 22 2023
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).
Nov 13 2023
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.
Nov 8 2023
Even easier way to repro, just dig a gardenplot and drop the item on there.
Video showing item teleportation issue:
Oct 12 2023
Seems to be fixed with today's Experimental update
Sep 26 2023
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.
Aug 19 2023
Jun 21 2023
Jun 15 2023
May 20 2023
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).
May 15 2023
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.
May 14 2023
May 13 2023
+1 for keeping the change.
May 6 2023
Apr 12 2023
This is fixed in vanilla since 1.19 for anyone reading this.
Mar 17 2023
Awesome!
Mar 14 2023
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.