Turret AP and HP ammo causes players to dynsc out of game when shot by turret

Version
2.5
Platform
Windows
when players are shot by turret ap or hp ammo they become dynsc from the game

*ammo type additions through tags seems to be the issue.

as of now internal hotfix by server owners is removing ap and hp ammo from being loaded into a turret untill the tags are corrected.
this mod made by cheese does exactly that.
https://www.nexusmods.com/7daystodie/mods/9401?tab=description

Screenshot 2026-01-16 102925.png
 
Reproduction Steps
easy to replicate set up turrets with ap or hp ammo and have a non ally player get killed by one
he/she will become dysnc from the game...
Link to Logs
https://discord.gg/ZfcsJU9TQC
Link to Screenshot/Video
https://discord.gg/ZfcsJU9TQC
From version 1.4 to 2.5 (+tags) was added to property of turrets "AmmoItem:..
verion 1.4:

Screenshot 2026-02-12 135814.png

version 2.5
Screenshot 2026-02-12 133816.png

the "AmmoItem" +tags i believe is what is causing the bug
 
Last edited:
Hapened to me yesterday players gettint shot by my turrets with standard ammo, getting desync we tried remove and replace ammo it seems to work
 
I got to a base to raid and it had turrets all the way around it I started getting shot for about 5 to 7 min and no damage I was invincible then all of a sudden my body was on the ground and I can see my body in 3rd person but I wasn't dead I belonged because I waited 10 min and nothing I can just see my body no death loop nothing just relogged and happened again same way
 
Technical Note: SMG / Auto Turret PvP Desync

The current issue is with the SMG / auto turret and how its combat behavior appears to synchronize between client and server during PvP.

Based on testing, the turret can appear to function normally from the player’s point of view while still failing to apply reliable damage. The turret may track, rotate, target, and visually fire, but the server/client combat state does not always resolve the hit or damage correctly.

The suspected failure path is:

1. The turret detects or tracks a player target.<br>2. The turret appears to fire at the target.<br>3. Client-side visual behavior and server-side combat validation do not stay fully aligned.<br>4. The turret shot does not consistently resolve as valid damage.<br>5. The player may take reduced, inconsistent, delayed, or no damage.<br>
This makes the turret unreliable as a PvP base-defense block.

This does not appear to be only a stat-balance issue. Changing XML values such as range, damage, ammo type, burst count, fire rate, recipes, loot, or trader entries can change how the turret is configured, but it does not necessarily fix the underlying turret combat behavior.

The important technical concern is that turret damage is not behaving like a simple server-authoritative damage event in all cases. If any part of the turret’s targeting, firing, raycast/projectile handling, animation state, or hit confirmation depends on client-side state, then a desync can cause the visual turret behavior and the actual server damage result to disagree.

Possible technical causes include:

client/server targeting mismatch<br>turret aim direction not matching server-side hit calculation<br>tile entity state not updating cleanly<br>turret fire event appearing client-side but not resolving server-side<br>hit confirmation failing after target movement<br>projectile or raycast validation disagreeing between client and server<br>turret ownership or powered state not matching at the moment of fire<br>loaded ammo state not matching expected turret ammo state<br>
The result is that a player can appear to be inside turret fire while the actual damage application is unreliable.

Testing also showed that directly modifying the autoTurret block definition is risky. Other turret blocks may inherit from or depend on the base auto turret definition. Heavy changes to the base turret block can unintentionally affect other turret types, including visibility, model behavior, ammo behavior, and block interaction.

This means that replacing, air-blocking, or heavily rewriting the base turret block through XML can create side effects beyond the original turret being targeted.

Placed turrets also carry persistent world data. A placed powered turret may include:

owner data<br>lock state<br>power connection data<br>rotation<br>targeting settings<br>loaded ammo<br>tile entity data<br>chunk state<br>
Because of that, forcing placed turret replacement in an active world is technically unsafe through XML alone. XML patches can change definitions, recipes, loot, and trader entries, but they cannot safely migrate every placed turret while preserving all live tile entity state.

A proper forced migration would require code that can scan world chunks, identify placed turret blocks, record their state, remove them, replace them, restore valid data, and log failures. Without that, live replacement can risk missing blocks, lost ammo, broken ownership, broken wiring, invisible blocks, or server errors.

The safest technical conclusion is:

The SMG / auto turret should be treated as unreliable for PvP defense.<br>The issue is likely tied to turret combat synchronization or turret tile entity behavior.<br>XML changes can reduce future exposure but cannot guarantee a true fix to the underlying desync.<br>Live-world forced replacement is risky because placed turrets contain persistent state.<br>Heavy edits to the base auto turret definition can affect other turret blocks.<br>
For long-term stability, the best technical direction is to avoid relying on the desync-prone turret behavior and move future PvP defense away from that turret path entirely.
The suspected failure path is:


1. The turret detects or tracks a player target.<br>2. The turret appears to fire at the target.<br>3. Client-side visual behavior and server-side combat validation do not stay fully aligned.<br>4. The turret shot does not consistently resolve as valid damage.<br>5. The player may take reduced, inconsistent, delayed, or no damage.</span>
 
Back
Top