I am a DayZ console player and, after experiencing several freezes and noticeable performance drops during gameplay, I started monitoring the server RPT files and comparing what was recorded there with what was actually happening in the game.

By doing this, I found several recurring issues involving the Central Economy, entity creation and placement, event processing, and map objects. In several cases, specific events recorded in the RPT repeatedly coincided with periods when noticeable freezes occurred during gameplay.

I do not consider all of the events below to necessarily be the isolated cause of the freezes. What I consider important is that they provide concrete evidence of abnormal, excessively heavy, or potentially problematic operations taking place during the same periods in which performance deteriorated.

1. hard to place, performance drops

One of the most significant problems I found is the recurring message:

hard to place, performance drops

It appears together with the name of the item that the Central Economy is attempting to place, such as AK101, HighCapacityVest_Olive, SmershVest, CoyoteBag_Green, and others.

The wording of the message itself is particularly relevant because the game explicitly states that difficulty placing the object is causing a performance drop.

This problem does not appear only in isolation: on several occasions, messages of this type occurred during periods when freezes or sharp performance drops were also observed during gameplay.

This suggests that the process of searching for valid positions for certain objects deserves specific investigation, particularly when the Central Economy needs to perform repeated attempts to find a suitable position.

2. Heavy processing of StaticMilitaryConvoy

Several moments were identified in which StaticMilitaryConvoy performs a concentrated sequence of operations involving the creation/processing of multiple military vehicles and wrecks.

In some of these cycles, numerous objects associated with the event are processed practically all at once, including Strykers, Urals, UAZs, MTVRs, Offroads, medical vehicles, and other military objects.

This processing appears as an extremely concentrated sequence in the RPT.

The most important point is that one of these cycles directly coincided with one of the most noticeable freeze periods recorded during gameplay. In another occurrence, convoy processing also appeared during the same general period as a hard to place, performance dropsmessage.

Therefore, I consider StaticMilitaryConvoy one of the systems that deserves priority investigation regarding its processing cost when events are created.

3. StaticTrain processing

I also found concentrated StaticTrainprocessing cycles involving multiple railway objects and loot containers.

One of these cycles occurred during a period in which gameplay experienced a significant performance drop.

In addition to the number of objects processed in sequence, a specific inconsistency involving loot containers was identified during the analysis of this event, as described below.

4. Inconsistency between container capacity and event lootmax

An objective inconsistency was found between the definition of certain containers and the values used by the events that contain them.

The Land_Container_1Mo_DE container has a maximum loot capacity of 3 defined in its prototype. However, in two occurrences within train events, the event requested:

lootmax="4"

while the actual capacity defined for that container was 3.

The RPT itself explicitly records:

Land_Container_1Mo_DE :: !!! Sum of container LootMax is lower than event child LootMax (3 < 4)

In other words, the event is requesting up to four loot positions for a container whose definition only allows three.

This inconsistency was specifically found in the Train_Mil_Kamenka and Train_Mil_Myshkino events.

It is important to emphasize that this is not behavior inferred from gameplay: the system itself records the incompatibility in the RPT.

Furthermore, this occurrence appeared in association with StaticTrain processing, which also coincided with a period of noticeable performance degradation.

This type of inconsistency should ideally be handled safely by the system itself, without generating additional processing, invalid attempts, or inconsistent states within the Central Economy.

5. pond — extremely high number of warnings

Another problem that appears very frequently is:

Unknown object class 'pond'

The warnings are repeatedly generated for different lake/water models on the map, sometimes in large sequences.

During several periods analyzed, there was a very high concentration of these messages and, on some occasions, they coincided with periods in which freezes occurred during gameplay.

I recognize that this problem, by itself, does not allow us to conclude that every pondmessage is responsible for a freeze. However, the frequency and repetition of the problem are significant enough to justify investigation at the engine level.

This issue has also been publicly identified in Bohemia's Feedback Tracker, where it was considered likely harmless but acknowledged as something that should be cleaned up in future updates.

What stands out in my testing is that these warnings do not occur only occasionally: there are periods in which they are generated in very large numbers and coincide with noticeable degradation of gameplay performance.

6. building warnings and geometry issues

Numerous messages related to:

Unknown object class 'building'

were also identified, along with several warnings related to the geometry of doors and other map objects.

Some of these occurrences are associated with specific building and map-object models, including objects in military areas.

During certain periods, these warnings occurred together with other Central Economy events and coincided with freezes observed during gameplay.

This indicates that there may be an issue involving the processing, loading, or querying of certain map geometries/objects.

7. thing warnings

In the most recent RPT files, I also found large sequences of:

Unknown object class 'thing'

mainly involving certain map objects, including washing machine models and lightning conductors.

The number of occurrences in some sequences is extremely high.

I was not able to demonstrate a sufficiently strong direct correlation between this specific issue and each freeze observed during gameplay, so I am not claiming that it is responsible for the freezes. However, the frequency and concentration of these messages justify investigation, especially because they occur alongside other anomalies related to the loading and processing of map objects.

8. Animal entities being moved to coordinates outside the world

I also found cases in which animal entities appear at completely abnormal coordinates, far beyond the expected areas of the map.

The RPT records, for example, Animal_SusScrofa and Animal_CapreolusCapreolusF entities being moved to coordinates outside the valid world.

The system then records:

NETWORK (E): Will delete object with !finite or outside world coords

This demonstrates that this is not simply a player's interpretation: the network system itself detects that the entity is outside valid coordinates and has to remove it.

This behavior deserves investigation because it represents an entity being created or moved to a position that should not exist within the game world.

9. Animal entity inheritance error

I also found:

ENTITY (E): Type 'ManType' must be inherited from class 'DayZAnimalType'

This error appeared in association with the processing of an animal entity.

Again, I am not claiming that this error is directly responsible for the freezes. However, it is an explicit inconsistency in the entity system and deserves investigation in the code responsible for creating or managing these entities.

10. Central Economy point removal

Occurrences of:

[CE][Point] Removing ...

were also found, associated with different map objects.

These messages appear during Central Economy activity and, at certain moments, occur close to other heavier processing cycles.

I do not consider the removal of a point, by itself, evidence of a bug. However, it would be important to determine whether these operations are related to cycles of point searching, invalidation, and reconstruction that could be increasing the processing cost of the CE.

11. Processing a large number of Central Economy links

During Central Economy initialization and certain processing cycles, the RPT records operations involving thousands of links between groups.

For example, the following was observed:

1946 total links between groups, of 11679

This type of operation demonstrates that there is a significant internal processing stage within the Central Economy related to groups and their links.

I do not have sufficient evidence to state that this operation, by itself, causes the freezes during gameplay. However, it would be extremely useful if the RPT reported how long each of these stages takes, particularly when they are executed while the server is operating normally.

What I consider most important

After comparing the RPT files with what actually occurred during gameplay, the problems that stood out the most were:

• hard to place, performance drops;

• concentrated processing of StaticMilitaryConvoy;

• concentrated processing of StaticTrain;

• inconsistencies between the actual capacity of loot containers and the lootmax requested by events;

• the very large number of Unknown object class 'pond' warnings;

• geometry issues and Unknown object class 'building'warnings.

Several of these events repeatedly coincided with periods in which noticeable freezes occurred during gameplay.

At the same time, there were some freezes for which the RPT did not show an immediately identifiable event. This is also important: it means that the currently available logging is not sufficient to determine, in every case, which operation caused the hitch.

For this reason, I believe it would be extremely useful to improve RPT instrumentation so that, during a hitch, it would be possible to identify:

• which Central Economy system was executing;

• which event was being processed;

• how many objects were being created/removed;

• how long each operation took;

• how many placement attempts were performed;

• how long the search for a valid position took;

• which entities were being created at that moment;

• and, most importantly, which operation temporally corresponds to the processing spike that produces the freeze perceived by the player.

This would make it possible to move beyond correlation and identify the actual cause.

An additional request regarding the .ADMfile

I would also like to request an important improvement to the combat, hunting, and entity-interaction logging system.

When a player kills an animal, the .ADM file should, whenever possible, record:

• which animal was killed;

• which player performed the kill;

• which weapon was used;

• which type of attack was used, when applicable (shot, melee hit, etc.);

• where the animal was hit, identifying the body region that received the shot or blow;

• when the animal was skinned;

• which player performed the skinning action;

• what the condition/state of the hide obtained from the animal was.

Likewise, I consider it important that the logging system should not be limited to the fact that an infected attacked and damaged a player. It would be very useful for the .ADM file to also explicitly record when a player kills an infected, identifying, whenever possible, which infected was killed, which player performed the kill, and which weapon or type of attack was used.

These records would be extremely useful for administration, incident investigation, combat analysis, and also for diagnosing problems related to the damage, hunting, skinning, AI, and entity-interaction systems.

Finally, I believe it is important to point out a matter of priority: cosmetic improvements are welcome, but stability, performance, diagnostic tools, and sufficiently detailed logging should take priority when there are problems directly affecting gameplay.

For the player, a new visual improvement is secondary when the game experiences freezes lasting several seconds while the RPT does not provide enough information to determine exactly what was happening at that moment.

BUG AND PERFORMANCE ISSUE REPORT — DAYZ 1.29

BUG AND PERFORMANCE ISSUE REPORT — DAYZ 1.29