Do you use PrismaCore?
laceLandProtectionBlock(worldPos, owner)Currently running 2.4.2... It was still and issue. Let me know if you need any help testing changes, I can upload to my dedicated server to test.@Prisma501 verified major issue with the mod causing lcbs on multiplayer to degrade
View attachment 39514
================================================================================
PrismaCore 2.4 - Land Claim Blocks deactivate to 1 HP on dedicated servers
7 Days to Die V 3.0.0 (b252)
================================================================================
SUMMARY
--------------------------------------------------------------------------------
On a dedicated server running 7 Days to Die V 3.0.0 (b252) with PrismaCore 2.4,
every player-placed Land Claim Block (LCB / keystoneBlock, 7000 max HP) drops to
1/7000 HP and loses its protection. The trigger is a chunk reload (a player
leaves ~100 m and the area reloads). It affects EVERY claim from EVERY player,
happens ONLY on the dedicated server, and CANNOT be reproduced in single-player.
Root cause: PrismaCore's Harmony prefix on TEFeatureLandClaim.OnAdded returns
false and never reproduces the vanilla claim registration. The claim is therefore
never written to the persistent claim map. On the next chunk load, vanilla
detects the missing registration and runs its "deactivate claim" path, which
deliberately sets the block to MaxDamage - 1 (= 1 HP).
This is a PrismaCore code issue, not a server-config issue. All server settings
were verified correct.
ENVIRONMENT
--------------------------------------------------------------------------------
- Game: V 3.0.0 (b252), LinuxServer 64-bit, dedicated
- Mod (confirmed in server log):
Loaded Mod: PrismaCore (2.4)
Initializing mod PrismaCore
- LCB block: vanilla keystoneBlock, MaxDamage = 7000
- Server land-claim settings (verified live with gg, all correct):
LandClaimDecayMode = 2 (None / BuffedUntilExpired)
LandClaimExpiryTime = 1000
LandClaimOnlineDurabilityModifier = 15
LandClaimOfflineDurabilityModifier = 15
LandClaimOfflineDelay = 0
LandClaimSize = 41
LandClaimCount = 7
SYMPTOM
--------------------------------------------------------------------------------
- A freshly placed LCB shows full health.
- The owner walks ~100 m away (chunk unloads) and returns (chunk reloads).
- The LCB now reads 1 / 7000 and provides no protection.
- Reproduced across multiple testers and multiple separately-placed LCBs.
- Single-player with the same map/settings (and without the full server mod set)
does NOT reproduce it.
THE VANILLA MECHANISM (decompiled from Assembly-CSharp, b252)
--------------------------------------------------------------------------------
1. Registration happens in TEFeatureLandClaim.OnAdded. It is the first thing the
method does:
TEFeatureLandClaim::OnAdded(Vector3i, BlockValue)
-> PersistentPlayerList:
-> PersistentPlayerData::AddLandProtectionBlock(pos)
-> writes the claim into m_lpBlockMap
(+ player.LPBlocks + players.xml persistence)
If OnAdded does not run, the claim is NEVER entered into m_lpBlockMap.
2. On chunk load, vanilla validates the claim and deactivates it if missing:
TEFeatureLandClaim::OnLoad()
-> IsPrimary()
-> (claim position not found in m_lpBlockMap)
-> HandleDeactivateLandClaim(blockPos)
3. HandleDeactivateLandClaim forces the block to 1 HP (server-side only).
Decompiled, the relevant steps are:
HandleDeactivateLandClaim(Vector3i pos):
GameManager.persistentPlayers.m_lpBlockMap.Remove(pos) // strip registration
NavObjectManager.UnRegisterNavObjectByPosition(pos,"land_claim")
LandClaimBoundsHelper.RemoveBoundsHelper(pos)
if (ConnectionManager.IsServer) { // <-- server-only branch
blockValue.damage = blockValue.Block.MaxDamage - 1; // 7000 - 1 -> damage 6999 -> 1 HP
world.SetBlockRPC(pos, blockValue); // pushes 1/7000 to clients
// also sends NetPackageEntityMapMarkerRemove
}
The if (ConnectionManager.IsServer) guard is exactly why this is server-only
and not reproducible in single-player: the MaxDamage - 1 write only executes
on a dedicated server.
For a 7000 HP LCB: damage = 7000 - 1 = 6999, leaving 1 / 7000, which matches
the in-game display exactly.
WHAT PRISMACORE 2.4 DOES (from the shipped PrismaCore.dll)
--------------------------------------------------------------------------------
PrismaCore.Patcher.DoPatching() locates TEFeatureLandClaim.OnAdded and installs
PrismaCore.StateManager.LCB as a Harmony PREFIX under the id com.prisma.core.
The prefix's effective behavior is:
RegionReset.HandleLCB(blockPos, blockValue, owner);
return false; // <-- skips the original TEFeatureLandClaim.OnAdded entirely
A Harmony prefix returning false prevents the original OnAdded from running.
Because the original is skipped, PlaceLandProtectionBlock -> AddLandProtectionBlock
never executes, so the claim is NEVER registered in m_lpBlockMap.
PrismaCore's prefix does NOT call PlaceLandProtectionBlock itself, and the DLL
does not reference AddLandProtectionBlock or LPBlocks to reproduce that
registration. So the claim is placed visually but is never persisted as an
owned claim.
Net effect:
LCB placed
-> PrismaCore prefix runs HandleLCB, returns false
-> vanilla OnAdded skipped
-> claim NOT added to m_lpBlockMap
-> (chunk reloads)
-> OnLoad -> IsPrimary fails -> HandleDeactivateLandClaim
-> server sets damage = MaxDamage - 1
-> LCB shows 1/7000, no protection
This reproduces 100% of the observed symptoms: server-only, every claim, every
player, on chunk reload, with the durability/decay settings being irrelevant.
THINGS RULED OUT (so this isn't a config wild-goose-chase)
--------------------------------------------------------------------------------
- SandboxCode - not responsible (LCB settings aren't part of the sandbox code;
verified the full b252 sandbox option list contains no land-claim option).
- LandClaimDecayMode = 2 - correct; decompiled
GetLandProtectionHardnessModifierForPlayer returns a constant modifier until
expiry under mode 2. Not the cause.
- LandClaimOnline/OfflineDurabilityModifier = 15 - this is a hardness multiplier
applied as damagePerHit = rawDamage / (blockHardness * modifier) in
ItemActionAttack.Hit. Higher = tougher. It does not unregister a claim or set
HP to 1. Not the cause.
- Other mods - searched all installed mods. The Allocs server-fixes mod only
READS the claim multiplier for the web map; it writes nothing. No other mod
patches claim registration or block damage in a way that does this. PrismaCore
is the only mod that prefixes TEFeatureLandClaim.OnAdded.
- PrismaCore settings toggles - none of the options in PrismaCoreSettings.xml
(e.g. QuestPoiProtection_Enabled, AllPoiProtection_Enabled, the reset-region
toggles) disable the OnAdded prefix. The patch is installed unconditionally in
DoPatching().
SUGGESTED FIX
--------------------------------------------------------------------------------
The OnAdded prefix needs to either let vanilla registration happen or reproduce
it. Either of these resolves it:
Option A - let the original run after PrismaCore's logic:
// in StateManager.LCB prefix
RegionReset.HandleLCB(blockPos, blockValue, owner);
return true; // allow vanilla TEFeatureLandClaim.OnAdded to execute and register the claim
(If PrismaCore needs to block placement in specific cases - e.g. LCB inside a
reset region - return false ONLY in those cases, and otherwise return true.)
Option B - keep returning false, but reproduce the vanilla registration inside
the prefix/HandleLCB:
GameManager.Instance.persistentPlayers.PlaceLandProtectionBlock(worldPos, owner);
// then continue with PrismaCore's own bookkeeping
Either way, the claim must end up in m_lpBlockMap (and the normal persistence) so
that OnLoad -> IsPrimary succeeds and HandleDeactivateLandClaim is not triggered
on reload.
RECOVERY FOR AFFECTED SERVERS
--------------------------------------------------------------------------------
LCBs already reduced to 1/7000 are no longer registered claims -
HandleDeactivateLandClaim removed them from m_lpBlockMap and stripped their
markers, so they are now just unowned keystoneBlock husks at 1 HP. A restart will
not re-register them. After installing a corrected build, owners should pick up
and re-place their LCBs so a fixed OnAdded registers them properly.
================================================================================
for sure, right now ive fired up a test server 64.44.100.82:26910 pw=NAPVP
Fixed in 2.4.1 2 days ago. Tested on 2 high pop server. Issue is gone.@Prisma501 verified major issue with the mod causing lcbs on multiplayer to degrade
View attachment 39514
================================================================================
PrismaCore 2.4 - Land Claim Blocks deactivate to 1 HP on dedicated servers
7 Days to Die V 3.0.0 (b252)
================================================================================
SUMMARY
--------------------------------------------------------------------------------
On a dedicated server running 7 Days to Die V 3.0.0 (b252) with PrismaCore 2.4,
every player-placed Land Claim Block (LCB / keystoneBlock, 7000 max HP) drops to
1/7000 HP and loses its protection. The trigger is a chunk reload (a player
leaves ~100 m and the area reloads). It affects EVERY claim from EVERY player,
happens ONLY on the dedicated server, and CANNOT be reproduced in single-player.
Root cause: PrismaCore's Harmony prefix on TEFeatureLandClaim.OnAdded returns
false and never reproduces the vanilla claim registration. The claim is therefore
never written to the persistent claim map. On the next chunk load, vanilla
detects the missing registration and runs its "deactivate claim" path, which
deliberately sets the block to MaxDamage - 1 (= 1 HP).
This is a PrismaCore code issue, not a server-config issue. All server settings
were verified correct.
ENVIRONMENT
--------------------------------------------------------------------------------
- Game: V 3.0.0 (b252), LinuxServer 64-bit, dedicated
- Mod (confirmed in server log):
Loaded Mod: PrismaCore (2.4)
Initializing mod PrismaCore
- LCB block: vanilla keystoneBlock, MaxDamage = 7000
- Server land-claim settings (verified live with gg, all correct):
LandClaimDecayMode = 2 (None / BuffedUntilExpired)
LandClaimExpiryTime = 1000
LandClaimOnlineDurabilityModifier = 15
LandClaimOfflineDurabilityModifier = 15
LandClaimOfflineDelay = 0
LandClaimSize = 41
LandClaimCount = 7
SYMPTOM
--------------------------------------------------------------------------------
- A freshly placed LCB shows full health.
- The owner walks ~100 m away (chunk unloads) and returns (chunk reloads).
- The LCB now reads 1 / 7000 and provides no protection.
- Reproduced across multiple testers and multiple separately-placed LCBs.
- Single-player with the same map/settings (and without the full server mod set)
does NOT reproduce it.
THE VANILLA MECHANISM (decompiled from Assembly-CSharp, b252)
--------------------------------------------------------------------------------
1. Registration happens in TEFeatureLandClaim.OnAdded. It is the first thing the
method does:
TEFeatureLandClaim::OnAdded(Vector3i, BlockValue)
-> PersistentPlayerList:
-> PersistentPlayerData::AddLandProtectionBlock(pos)
-> writes the claim into m_lpBlockMap
(+ player.LPBlocks + players.xml persistence)
If OnAdded does not run, the claim is NEVER entered into m_lpBlockMap.
2. On chunk load, vanilla validates the claim and deactivates it if missing:
TEFeatureLandClaim::OnLoad()
-> IsPrimary()
-> (claim position not found in m_lpBlockMap)
-> HandleDeactivateLandClaim(blockPos)
3. HandleDeactivateLandClaim forces the block to 1 HP (server-side only).
Decompiled, the relevant steps are:
HandleDeactivateLandClaim(Vector3i pos):
GameManager.persistentPlayers.m_lpBlockMap.Remove(pos) // strip registration
NavObjectManager.UnRegisterNavObjectByPosition(pos,"land_claim")
LandClaimBoundsHelper.RemoveBoundsHelper(pos)
if (ConnectionManager.IsServer) { // <-- server-only branch
blockValue.damage = blockValue.Block.MaxDamage - 1; // 7000 - 1 -> damage 6999 -> 1 HP
world.SetBlockRPC(pos, blockValue); // pushes 1/7000 to clients
// also sends NetPackageEntityMapMarkerRemove
}
The if (ConnectionManager.IsServer) guard is exactly why this is server-only
and not reproducible in single-player: the MaxDamage - 1 write only executes
on a dedicated server.
For a 7000 HP LCB: damage = 7000 - 1 = 6999, leaving 1 / 7000, which matches
the in-game display exactly.
WHAT PRISMACORE 2.4 DOES (from the shipped PrismaCore.dll)
--------------------------------------------------------------------------------
PrismaCore.Patcher.DoPatching() locates TEFeatureLandClaim.OnAdded and installs
PrismaCore.StateManager.LCB as a Harmony PREFIX under the id com.prisma.core.
The prefix's effective behavior is:
RegionReset.HandleLCB(blockPos, blockValue, owner);
return false; // <-- skips the original TEFeatureLandClaim.OnAdded entirely
A Harmony prefix returning false prevents the original OnAdded from running.
Because the original is skipped, PlaceLandProtectionBlock -> AddLandProtectionBlock
never executes, so the claim is NEVER registered in m_lpBlockMap.
PrismaCore's prefix does NOT call PlaceLandProtectionBlock itself, and the DLL
does not reference AddLandProtectionBlock or LPBlocks to reproduce that
registration. So the claim is placed visually but is never persisted as an
owned claim.
Net effect:
LCB placed
-> PrismaCore prefix runs HandleLCB, returns false
-> vanilla OnAdded skipped
-> claim NOT added to m_lpBlockMap
-> (chunk reloads)
-> OnLoad -> IsPrimary fails -> HandleDeactivateLandClaim
-> server sets damage = MaxDamage - 1
-> LCB shows 1/7000, no protection
This reproduces 100% of the observed symptoms: server-only, every claim, every
player, on chunk reload, with the durability/decay settings being irrelevant.
THINGS RULED OUT (so this isn't a config wild-goose-chase)
--------------------------------------------------------------------------------
- SandboxCode - not responsible (LCB settings aren't part of the sandbox code;
verified the full b252 sandbox option list contains no land-claim option).
- LandClaimDecayMode = 2 - correct; decompiled
GetLandProtectionHardnessModifierForPlayer returns a constant modifier until
expiry under mode 2. Not the cause.
- LandClaimOnline/OfflineDurabilityModifier = 15 - this is a hardness multiplier
applied as damagePerHit = rawDamage / (blockHardness * modifier) in
ItemActionAttack.Hit. Higher = tougher. It does not unregister a claim or set
HP to 1. Not the cause.
- Other mods - searched all installed mods. The Allocs server-fixes mod only
READS the claim multiplier for the web map; it writes nothing. No other mod
patches claim registration or block damage in a way that does this. PrismaCore
is the only mod that prefixes TEFeatureLandClaim.OnAdded.
- PrismaCore settings toggles - none of the options in PrismaCoreSettings.xml
(e.g. QuestPoiProtection_Enabled, AllPoiProtection_Enabled, the reset-region
toggles) disable the OnAdded prefix. The patch is installed unconditionally in
DoPatching().
SUGGESTED FIX
--------------------------------------------------------------------------------
The OnAdded prefix needs to either let vanilla registration happen or reproduce
it. Either of these resolves it:
Option A - let the original run after PrismaCore's logic:
// in StateManager.LCB prefix
RegionReset.HandleLCB(blockPos, blockValue, owner);
return true; // allow vanilla TEFeatureLandClaim.OnAdded to execute and register the claim
(If PrismaCore needs to block placement in specific cases - e.g. LCB inside a
reset region - return false ONLY in those cases, and otherwise return true.)
Option B - keep returning false, but reproduce the vanilla registration inside
the prefix/HandleLCB:
GameManager.Instance.persistentPlayers.PlaceLandProtectionBlock(worldPos, owner);
// then continue with PrismaCore's own bookkeeping
Either way, the claim must end up in m_lpBlockMap (and the normal persistence) so
that OnLoad -> IsPrimary succeeds and HandleDeactivateLandClaim is not triggered
on reload.
RECOVERY FOR AFFECTED SERVERS
--------------------------------------------------------------------------------
LCBs already reduced to 1/7000 are no longer registered claims -
HandleDeactivateLandClaim removed them from m_lpBlockMap and stripped their
markers, so they are now just unowned keystoneBlock husks at 1 HP. A restart will
not re-register them. After installing a corrected build, owners should pick up
and re-place their LCBs so a fixed OnAdded registers them properly.
================================================================================
github.com
Version 2.4.1 3.0.0 b252 Experimental (NOT 2.6 b14 Stable compatible)* fixed landclaims deactivating after owner logging offHere are is the mod folder I am currently running on my server:
No. Unless you use other api mods that handle and suppress chat (chatcolor, muting, chatname overriding). Then the api mod handling those must load last.
Make sure you use latest 2.4.2 (or at least 2.4.1)
thanks for the quick reply, ill grab it and definately check it now.Fixed in 2.4.1 2 days ago. Tested on 2 high pop server. Issue is gone.
There ya go.
Releases · Prisma501/PrismaCore
API Mod for 7DaysToDie Dedicated Servers. Contribute to Prisma501/PrismaCore development by creating an account on GitHub.
Version 2.4.1 3.0.0 b252 Experimental (NOT 2.6 b14 Stable compatible)
* fixed landclaims deactivating after owner logging off
Fixed in 2.4.1. You run 2.4.
2.4.2 is latest
Keystoneblock is no block anymore, but a TEFeatureLandclaim. Had to rewrite the handling of placing LCB in resetregion and on protected pois/questpois and various advanced claims. With initial realease i made the booboo that if not handled and removed by PrismaCore i returned false on the harmony patched void. Which cut 75% of LCB vanilla handling off. That was fixed in 2.4.1
Verified as well. Was listening to other players, so I hopped in to test myself. Placed my claim block, drove to a different biome for a bit, and came back and saw no degredation of my claim block. I will watch it futher, but seems to be resovled. (v2.4.2)
