V3.0.0 b259 EXP Update

nocube said:
The bear below the construction site was way too iconic imo, real shame it's removed now. I hope you reconsider and bring it back. For balance, you could simply increase the POI difficulty by 1–2 red skulls. Otherwise, all these changes & options in the 3.0+ updates feel amazing! The game is finally becoming the true sandbox everyone wanted.

More sandbox toggles I'd personally love to see next:
  • Wandering Horde Size
  • Wandering Horde Frequency
  • Wandering Horde Lootbag Drop Chance
  • Bloodmoon Vulture Attacks - Disabled / Target Vehicles Only (Default) / Target Always
  • Special Biome Zombie Spawn Rate - Reduce or increase amount of chucks / plaguespitters / mutants in the wild.

  • Schematic Abundance
  • Mod Abundance
  • Salvage Yield - similar to ore yield, but for cars/pipes/electronics.
  • Wood Yield - same for trees and bushes.
  • Honey Yield - a lot of players would like to change the drop percentages of honey from stumps.
  • Bee Spawn Chance
  • Crop Auto Replant - Enabled / Disabled. Harvesting mature crops make a new seed spawn automatically.
  • Crop Pickup - If enabled, you can collect mature crops by pressing E. Will make farming super comfortable when combined with Crop Replant setting.

  • Trap Player Damage - when set to 0% traps are safe for players.
  • Trap Zombie Damage
  • Trap Pickup - If enabled, you can collect traps with full durability by pressing E.
  • Storm Damage - 100% is default, you can lower or disable it.
  • Temperature Damage - If set above 0%(default), players can freeze/overheat to death.
  • Player Injuries Chance - Configure how often injuries occur. Affects mostly zombie-inflicted injuries.
Some more fun / challenge settings, most are disabled by default:
  • Air Drop Horde Spawn Chance - when looting an air drop determines chance to summon a wandering horde
  • Minefield - Random landmines can spawn throughout the world in any biome, replacing small grass, rocks, or plants.
  • Radiated Water – You receive damage and the Radiation effect while swimming or standing in water, or while exposed to rain.
  • Solar Apocalypse – You burn in direct sunlight during the daytime. Desert-only challenges will feel so much different with this setting.
  • Exploding Zombies. Yep, when they die, they have chance to explode.
Most of these settings would be relatively easy to add to the game, yet they would massively increase its replayability. They would also lead to even more game Presets that would genuinely feel distinct from one another. Speaking of presets, please replace the current half-AI slop icons. They don't fit the game's style at all. Even simple screenshots of in-game locations or zombie models would look much better and feel far more fitting tbf.
Click to expand...

Wonderful list! we share many of these wishes.

Many of them should be relatively easy to add; this mod was created in just a few days and already adds them, even from the new 3.0 menu:

Set-it-up V3.0 - Interior Lighting - Wandering Hordes- Spawn filters and more...
 

Official Request to TFP: Fix the Current Sandbox System Before Adding More Options​

As a long-time server owner with more than 30,000 hours in 7 Days to Die, I am formally asking The Fun Pimps to stop adding new sandbox settings until the existing V3.0 sandbox system is stable and its current bugs are resolved.

Server owners are already dealing with too many issues involving sandbox codes, settings that do not apply correctly, values that conflict with server configuration files, unexpected resets, and options that behave differently from what the menu describes. Every additional sandbox option increases the number of possible conflicts and makes diagnosing server problems more difficult.

Players continue requesting more sandbox codes and additional configuration choices, but adding more options to an unstable system is not the answer. The priority should be:
  1. Fix the existing sandbox settings.
  2. Make sure every option applies consistently.
  3. Ensure sandbox codes reproduce the exact intended configuration.
  4. Eliminate conflicts between sandbox settings, server configuration files, and saved game data.
  5. Document which setting takes priority when multiple systems control the same value.
  6. Add proper validation and logging when a sandbox setting fails or is overridden.
This is not a request for fewer customization options permanently. Customization is important, especially for dedicated and heavily modified servers. However, new options should not be added until the current system can be trusted.

My official position as a server owner is simple:

Please do not add any more sandbox options until the existing V3.0 sandbox bugs are fixed, verified, and documented.
Click to expand...
Server owners need stability before expansion. We need the settings already provided to work correctly before more settings are introduced.
 
Grandpa Minion said:

Official Request to TFP: Fix the Current Sandbox System Before Adding More Options​

As a long-time server owner with more than 30,000 hours in 7 Days to Die, I am formally asking The Fun Pimps to stop adding new sandbox settings until the existing V3.0 sandbox system is stable and its current bugs are resolved.

Server owners are already dealing with too many issues involving sandbox codes, settings that do not apply correctly, values that conflict with server configuration files, unexpected resets, and options that behave differently from what the menu describes. Every additional sandbox option increases the number of possible conflicts and makes diagnosing server problems more difficult.

Players continue requesting more sandbox codes and additional configuration choices, but adding more options to an unstable system is not the answer. The priority should be:
  1. Fix the existing sandbox settings.
  2. Make sure every option applies consistently.
  3. Ensure sandbox codes reproduce the exact intended configuration.
  4. Eliminate conflicts between sandbox settings, server configuration files, and saved game data.
  5. Document which setting takes priority when multiple systems control the same value.
  6. Add proper validation and logging when a sandbox setting fails or is overridden.
This is not a request for fewer customization options permanently. Customization is important, especially for dedicated and heavily modified servers. However, new options should not be added until the current system can be trusted.

My official position as a server owner is simple:


Server owners need stability before expansion. We need the settings already provided to work correctly before more settings are introduced.
Click to expand...
Perhaps you should give specific examples of what isn't working and why you think it needs changed or fixed rather than making a generic post? This post is basically useless as it is written (I assume with AI).
 
IMHO If you want stability, don't use experimental. If your users want stability, they should not ask for experimental either. If they still ask for experimental then they obviously value the new stuff more than potential bugs and have to accept the downsides.
 
Riamus said:
Perhaps you should give specific examples of what isn't working and why you think it needs changed or fixed rather than making a generic post? This post is basically useless as it is written (I assume with AI).
Click to expand...
Forget it; the guy can't even express himself anymore, needs AI for everything now.
He should make a bug report with a specific problem that could then be looked at.
 
Hated said:
Siphoning Strikes and Bar Brawling Vol 5 will no longer work without food or water
Click to expand...

Exactly what does "without" food or water mean here?
When you're critically starving and/or thirsty?

...or is this perk now just a digestion-burst like the Regeneration perk (for quite some time) is just a quicker digestion healing on top of the regular digestion healing?
 
Riamus said:
Perhaps you should give specific examples of what isn't working and why you think it needs changed or fixed rather than making a generic post? This post is basically useless as it is written (I assume with AI).
Click to expand...
since you asked
Specific examples:

This is not a generic complaint, and it is not a request for fewer features. These are major V3.0 problems that server administrators have had to diagnose, patch, work around, or build recovery systems for:

1. Turret death-state desync
Powered turrets can kill a player on the server while the client remains lying on the ground without receiving the death or respawn screen. We found that offline turret ownership makes the problem more likely. Fixing this required tracing the damage network packages, identifying stale owner data, writing a server-side watchdog, sanitizing the recovery packet, adding a second recovery stage, and performing repeated live tests.

2. Stuck use/action state
Players can become trapped in a broken use or countdown state. We had to add a /fixuse recovery command instead of having a reliable vanilla recovery path.

3. Stale lock states
Locks can remain in an invalid or stale state and require a dedicated server-side guard.

4. Sign-data problems
Sign data can become invalid or fail to synchronize correctly, requiring a separate sign-data repair patch.

5. Vending-machine restocking
Vending reset and restock ticks have required server-side patches so restocking continues to function correctly.

6. Backpack diagnostic spam
EntityBackpack repeatedly generates useless diagnostic log spam. We had to suppress it so actual server problems remain visible in the logs.

7. Trader chunk-entry problems
Entering trader chunks has required a dedicated corrective patch to prevent broken trader-area behavior.

8. Quest logout exploit
Quest state can be abused or mishandled through disconnecting, requiring a separate logout-exploit fix.

9. Drone recovery
Drones can become lost, inaccessible, or stuck in bad saved states, requiring administrator recovery commands and server-side repair tools.

10. Static-water failures
Water behavior has required an emergency corrective mod rather than functioning reliably through the normal game systems.

11. Death and respawn handling
We have had to maintain custom respawn handling and carefully test coexistence with the vanilla death system because death-state synchronization is not consistently reliable.

12. Scoreboard and gamestage updating
We have had to use safe caching and throttling to prevent unnecessary or unsafe scoreboard and gamestage updates.

These are not content additions, balance changes, or players demanding more sandbox toys. They are reliability fixes for basic dedicated-server systems: death, respawning, locks, signs, vending machines, backpacks, traders, quests, drones, water, and player interaction states.

The turret issue alone required decompiling the current server assemblies, tracing the client/server damage flow, writing multiple versions of a Harmony patch, conducting forensic audits, and arranging live testing with players. A player should not have to relog because a normal powered turret killed them, and a server administrator should not have to reverse-engineer the game’s network damage system to fix it.

I understand that experimental versions can contain bugs. That does not mean every bug should be dismissed with “do not use experimental.” Experimental builds still need useful bug reports, reproducible testing, validation, and fixes. Administrators reporting these problems are doing unpaid testing and engineering work that directly improves the game.

My request remains the same: stabilize the systems already present, document which setting has authority when values conflict, add useful validation and logging, and resolve the existing dedicated-server defects before continuously expanding the sandbox system.
 
Last edited:
Grandpa Minion said:
since you asked
Specific examples:

This is not a generic complaint, and it is not a request for fewer features. These are major V3.0 problems that server administrators have had to diagnose, patch, work around, or build recovery systems for:

1. Turret death-state desync
Powered turrets can kill a player on the server while the client remains lying on the ground without receiving the death or respawn screen. We found that offline turret ownership makes the problem more likely. Fixing this required tracing the damage network packages, identifying stale owner data, writing a server-side watchdog, sanitizing the recovery packet, adding a second recovery stage, and performing repeated live tests.

2. Stuck use/action state
Players can become trapped in a broken use or countdown state. We had to add a /fixuse recovery command instead of having a reliable vanilla recovery path.

3. Stale lock states
Locks can remain in an invalid or stale state and require a dedicated server-side guard.

4. Sign-data problems
Sign data can become invalid or fail to synchronize correctly, requiring a separate sign-data repair patch.

5. Vending-machine restocking
Vending reset and restock ticks have required server-side patches so restocking continues to function correctly.

6. Backpack diagnostic spam
EntityBackpack repeatedly generates useless diagnostic log spam. We had to suppress it so actual server problems remain visible in the logs.

7. Trader chunk-entry problems
Entering trader chunks has required a dedicated corrective patch to prevent broken trader-area behavior.

8. Quest logout exploit
Quest state can be abused or mishandled through disconnecting, requiring a separate logout-exploit fix.

9. Drone recovery
Drones can become lost, inaccessible, or stuck in bad saved states, requiring administrator recovery commands and server-side repair tools.

10. Static-water failures
Water behavior has required an emergency corrective mod rather than functioning reliably through the normal game systems.

11. Death and respawn handling
We have had to maintain custom respawn handling and carefully test coexistence with the vanilla death system because death-state synchronization is not consistently reliable.

12. Scoreboard and gamestage updating
We have had to use safe caching and throttling to prevent unnecessary or unsafe scoreboard and gamestage updates.

These are not content additions, balance changes, or players demanding more sandbox toys. They are reliability fixes for basic dedicated-server systems: death, respawning, locks, signs, vending machines, backpacks, traders, quests, drones, water, and player interaction states.

The turret issue alone required decompiling the current server assemblies, tracing the client/server damage flow, writing multiple versions of a Harmony patch, conducting forensic audits, and arranging live testing with players. A player should not have to relog because a normal powered turret killed them, and a server administrator should not have to reverse-engineer the game’s network damage system to fix it.

I understand that experimental versions can contain bugs. That does not mean every bug should be dismissed with “do not use experimental.” Experimental builds still need useful bug reports, reproducible testing, validation, and fixes. Administrators reporting these problems are doing unpaid testing and engineering work that directly improves the game.

My request remains the same: stabilize the systems already present, document which setting has authority when values conflict, add useful validation and logging, and resolve the existing dedicated-server defects before continuously expanding the sandbox system.
Click to expand...
Okay, so you listed general problems with servers, but you were talking specifically about sandbox settings. What are those problems? That was what I was replying to.
 
My question is how many of the listed server issues are directly related to exceeding 8 players and needing to police dozens of strangers who are playing in competition with each other.

The devs have priorities that are based on keeping the game stable for its intended use which is primarily for sole survivors and teams of 2-8 friends/family who are not trying to kill each other.

So, for example, your turret death de-sync issue would never even emerge in any play session by players who are playing solo or with friends cooperatively. Thats going to put spending time and resources on fixing it lower on the priority list even if those fixes would also technically benefit the solo and PvE players as well.

Another example are warning reports that spam the F1 console and make it difficult for a server admin to watch over the server and police players. My brother administers the server on which my family plays 7 Days to Die together and that problem has never been an issue ever— because there’s no need to police anyone and he doesn’t sit still wracking up play hours staring at the logs to watch what everyone is doing.

When modders overhaul the game into an unofficial alt version and instabilities arise, it is almost always going to be on the mod author to troubleshoot those issues. They can request TFP to fix those issues as you did but if those issue never happen in the default version there are always going to be other priorities that will come first. (Such as adding new content).

It sounds like your team is successfully figuring out workarounds for at least some of the issues created by the version of 7 Days to Die you like to play.
 
Last edited:
Roland, I appreciate the reply, and you're right that we're finding workarounds. But I want to correct the core assumption, because it's a technical misunderstanding, not a difference of opinion.


The premise that these issues stem from exceeding 8 players and policing strangers doesn't hold up against how the bugs actually work.
Take the one you cited — the turret death desync.
And take the bigger one we're dealing with now: land-claim desync. Both are per-client bugs.
The desync happens independently for each individual client regardless of how many players are on the server.
A claim desyncing for one player on a 40-slot server desyncs exactly the same way it would on a 2-slot server.
Player count is not a variable in the mechanism. So "this only matters because you run more than 8" isn't a prioritization call — it's describing a cause that isn't the cause.

Here's the current one, specifically, since specifics were asked for:

Land-claim protection is enforced entirely client-side in 3.0. The protection checks (World.CanPlaceBlockAt / CanPlaceLandProtectionBlockAt / IsLandProtectedBlock) are only ever called from client-side placement code. On a dedicated server, an incoming block placement goes NetPackageSetBlock.ProcessPackage → GameManager.ChangeBlocks, and that path applies the block change with no server-side land-protection check at all. The server trusts the client to have refused the placement.


The consequence: ownership data is replicated to each client via PersistentPlayerList.NetworkCloneRelevantForPlayer(), filtered per client. When a client's copy of "who owns this claim" desyncs from the server — the same class of stale-state problem as the turret owner data — that client will place blocks inside a claim it no longer sees as protected, and the server applies it, because the server never re-checks. That's players building inside other players' claims. The companion symptom is claims losing protection while the owner is online, which traces to the owner resolution feeding the protection/hardness path (GetLandProtectionHardnessModifierForPlayer) — notably the online-vs-offline math itself is correct, so it's the resolved owner that's wrong, not the durability formula.


None of that depends on being at 8 players or 40. It's a design choice — protection checked client-side, applied server-side without revalidation — and it desyncs per client at any population.


The request stands, and it's a reliability request, not a feature one: make land-claim ownership server-authoritative on the block-apply path, and document which setting has authority when values conflict. Those two things fix a whole category of these problems, PvP or not — a co-op group with a shared base hit by claim desync loses their base the same way we do.
 
Unrelated to the current convo, just wanting to make sure I'm clear on this.

@schwanz9000 @faatal For weapon/tool/armor/vehicle mods with quality levels, are there plans in place for later to allow us to craft higher quality versions of these, or is the plan only to have them findable via looting and trader purchase?

And if it's the latter, are there any mods that will ONLY be available as quality 1? Been looking for a higher quality fuel saver and higher quality drone stun mod, but haven't had any luck yet.
 
Grandpa Minion said:
A claim desyncing for one player on a 40-slot server desyncs exactly the same way it would on a 2-slot server.
Player count is not a variable in the mechanism. So "this only matters because you run more than 8" isn't a prioritization call — it's describing a cause that isn't the cause.
Click to expand...

It may desync in exactly the same way but would it desync at all with fewer than 8 players? You’ve got 40 players and if many of them have turrets, drones, claim blocks, vehicles, etc is that not going to strain the limits of the game? I admit my technical knowledge isn’t the best but I do remember one play when I tried starting 25 campfires at once to test out a horde defense base against a screamer horde. It caused some issues. That was one player with 25 campfires. You’ve got 40 players with 40 campfires, 40 vehicles, 40 claims, 40 drones, 40 turrets, etc.

Your buddy says:

Yes, in 7 Days to Die, this scenario will absolutely crush server performance and cause severe desync. The game's engine (Unity) and network architecture struggle heavily with high counts of active, ticking entities. [1, 2, 3, 4]
Here is exactly why this specific combination will lag out a 7 Days to Die server:

Why It Causes Severe Desync
  • Heat Map Generation: 40 campfires and 40 forges running at the same time generate massive amounts of "Heat" (the game's invisible mechanic that attracts zombie screamers). The server has to constantly calculate heat accumulation and decay across multiple chunks, triggering endless zombie spawn loops. [1, 2]
  • Ticking Inventories: Forges and campfires are not static objects. The server must calculate fuel burn times, melting progress, output queues, and inventory slots for all 80 workstations simultaneously.
  • Physics & Chunk Loading: 40 vehicles (like 4x4 trucks or gyrocopters) moving across the map force the server to rapidly load, generate, and unload world chunks. The server's CPU will bottleneck trying to sync these high-speed coordinate changes to all 40 players. [1, 2, 3]
  • Drone Network Bloat: Robotic Drones are notorious for tanking performance. They constantly calculate 3D pathfinding to follow moving players, scan for enemies, and heal allies. 40 active drones will completely choke the server's main logic thread.
 
Riamus said:
You still haven't given at indication of the sandbox settings that you said were broken and needed fixed before new sandbox settings are added.
Click to expand...
You, above all others, have been here continuously day in day out for the last 2-3 years during the "jar" crisis TFP faced having to bring them back and the challenges encountered in their removal.
At this point, I am not ready to engage in discussions about any sandbox settings, as LCBs are currently my main focus.
If you think the commotion surrounding the "jars" was considerable,
just wait until people learn about the situation with their LCBS in 3.0
 
Grandpa Minion said:
You, above all others, have been here continuously day in day out for the last 2-3 years during the "jar" crisis TFP faced having to bring them back and the challenges encountered in their removal.
At this point, I am not ready to engage in discussions about any sandbox settings, as LCBs are currently my main focus.
If you think the commotion surrounding the "jars" was considerable,
just wait until people learn about the situation with their LCBS in 3.0
Click to expand...
You are the one who specifically brought up sandbox settings...

Grandpa Minion said:
Official Request to TFP: Fix the Current Sandbox System Before Adding More Options
Click to expand...
Grandpa Minion said:
  1. Fix the existing sandbox settings.
  2. Make sure every option applies consistently.
  3. Ensure sandbox codes reproduce the exact intended configuration.
  4. Eliminate conflicts between sandbox settings, server configuration files, and saved game data.
  5. Document which setting takes priority when multiple systems control the same value.
  6. Add proper validation and logging when a sandbox setting fails or is overridden.
Click to expand...

But you aren't willing to comment on sandbox settings? So why did you post at all? Or was that an AI post as I expected and you didn't even read it to know what was written before posting it?
 
Only thing i'd like to see with Sandbox changed is the zombie density sandbox option
make it so "special" or biome zombies are affected at half or one-third the rate of the normal zombies.
they are supposed to be unique and special so even at higher populations they should be reasonable rare in comparison.
right now Ranchers & Chucks overpopulate compared to the normal zombie spawns.
 
Grandpa Minion said:
Roland, I appreciate the reply, and you're right that we're finding workarounds. But I want to correct the core assumption, because it's a technical misunderstanding, not a difference of opinion.


The premise that these issues stem from exceeding 8 players and policing strangers doesn't hold up against how the bugs actually work.
Take the one you cited — the turret death desync.
And take the bigger one we're dealing with now: land-claim desync. Both are per-client bugs.
The desync happens independently for each individual client regardless of how many players are on the server.
A claim desyncing for one player on a 40-slot server desyncs exactly the same way it would on a 2-slot server.
Player count is not a variable in the mechanism. So "this only matters because you run more than 8" isn't a prioritization call — it's describing a cause that isn't the cause.

Here's the current one, specifically, since specifics were asked for:

Land-claim protection is enforced entirely client-side in 3.0. The protection checks (World.CanPlaceBlockAt / CanPlaceLandProtectionBlockAt / IsLandProtectedBlock) are only ever called from client-side placement code. On a dedicated server, an incoming block placement goes NetPackageSetBlock.ProcessPackage → GameManager.ChangeBlocks, and that path applies the block change with no server-side land-protection check at all. The server trusts the client to have refused the placement.


The consequence: ownership data is replicated to each client via PersistentPlayerList.NetworkCloneRelevantForPlayer(), filtered per client. When a client's copy of "who owns this claim" desyncs from the server — the same class of stale-state problem as the turret owner data — that client will place blocks inside a claim it no longer sees as protected, and the server applies it, because the server never re-checks. That's players building inside other players' claims. The companion symptom is claims losing protection while the owner is online, which traces to the owner resolution feeding the protection/hardness path (GetLandProtectionHardnessModifierForPlayer) — notably the online-vs-offline math itself is correct, so it's the resolved owner that's wrong, not the durability formula.


None of that depends on being at 8 players or 40. It's a design choice — protection checked client-side, applied server-side without revalidation — and it desyncs per client at any population.


The request stands, and it's a reliability request, not a feature one: make land-claim ownership server-authoritative on the block-apply path, and document which setting has authority when values conflict. Those two things fix a whole category of these problems, PvP or not — a co-op group with a shared base hit by claim desync loses their base the same way we do.
Click to expand...
You could ask here:
Hank7DTD

Windows Thread '7DTD Player Support'

Hey Survivors,

I'm Hank, a part of Player Support for 7DTD.

I'm creating this tread to share that our Player Support team is here to help with your game, on any platforms.

While we are more than happy to see your posts here, we recently launched a Help Center for 7DTD where you can get personalized 1 on 1 support.

You can reach out to us here: https://7-days-to-die.zendesk.com/hc/en-us/requests/new
  • Like
  • Prime Bless You
 
@faatal or @madmole

Can you add a single class for " Dog, Direwolf, ZombieBear". Why, because the three
of them transgress multiple classes. They are neither animal or zombie but both.
So when configuring the ai to interact with other classes. Those three follow the same
pattern. More than one in an area and they attack each other without damage.

Hierarchy: Timid, Hostileanimal, Zombie, Player, Vulture, Swarm. Predatory zombieanimals
is missing to make it complete. EntityZombieDog gets overridden by entityenemyanimal.

The vulture has its own class, the swarms have no class assigned. So they function as a separate
entity. Or possible give them a separate aitarget designation.

Is it priority, nope, it's actually been close to the same way from way back, but they are a predatory
group of their own. I have adjusted over the alphas, but am at a loss now.

I tried tags, class, remove from extend chain, add to another extend chain, avatarcontroller, factions.
 
Installed industrial light bulbs and my base now feels like very lowgrade brothel where disco music was loved before the apocalypse. They change colour or/and pulsate.

Thought it was fixed.
 
You must log in or register to reply here.
Back
Top