Plugin Version
0.10.2
Operating System
Linux (Debian/Ubuntu)
Bug Description
Three related zone flag issues affecting interaction control in claimed territory and admin zones:
1. Door flag bypasses parent block_interact check
door_use is evaluated directly without checking its parent flag block_interact. The parent-child hierarchy is defined in ZoneFlags.getParentFlag() but ProtectionChecker.canInteractChunk() maps DOOR directly to ZoneFlags.DOOR_USE and never verifies the parent. This means disabling block_interact on a zone does NOT disable doors — you have to toggle door_use separately, which defeats the purpose of the parent flag.
This likely affects all interaction children: container_use, bench_use, processing_use, seat_use.
2. No zone flag for lights (torches, lanterns)
There is no light_use or torch_use flag. Light interactions (toggling torches/lanterns) are not specifically handled by BlockUseProtectionSystem — they fall through to the generic OTHER case which checks block_interact. There is no way to independently control light toggling in zones (e.g., allow doors but block light toggling, or vice versa).
3. No zone flag for NPC dialogue/conversation
NpcInteractionProtectionHandler only intercepts InteractionType.Use (F-key taming) and maps it to NPC_TAME. There is no flag or handler for NPC dialogue/conversation. Players cannot talk to NPCs in protected territory regardless of flag settings — there is no flag to allow it.
Steps to Reproduce
Door parent check:
- Create a zone and set
block_interact to false
- Set
door_use to true
- Doors still work — child flag ignores disabled parent
Lights:
- Place torches/lanterns in a zone
- No flag exists to control toggling them independently
- They follow
block_interact generically with no granular control
NPC dialogue:
- Place an NPC with dialogue in claimed/zoned territory
- Try to talk to it — blocked with no way to allow it
- No zone flag exists for NPC dialogue
Expected Behavior
- Child interaction flags (
door_use, container_use, etc.) should respect their parent block_interact — if the parent is false, children should be false regardless of their individual setting
- A
light_use flag should exist as a child of block_interact to control torch/lantern toggling independently
- An
npc_dialogue or npc_talk flag should exist to allow/deny NPC conversations in zones, separate from npc_tame
Logs
No response
Code Snippets
Issue 1 — ProtectionChecker.canInteractChunk() maps directly without parent check:
String flagName = switch (type) {
case INTERACT, USE -> ZoneFlags.BLOCK_INTERACT;
case DOOR -> ZoneFlags.DOOR_USE; // directly, no parent check
case CONTAINER -> ZoneFlags.CONTAINER_USE;
// ...
};
boolean allowed = zone.getEffectiveFlag(flagName); // only checks child flag
Parent hierarchy exists but is unused during evaluation:
// ZoneFlags.getParentFlag()
case DOOR_USE, CONTAINER_USE, BENCH_USE, PROCESSING_USE, SEAT_USE -> BLOCK_INTERACT;
Media
No response
Additional information
- Issue 1 affects all 5 interaction children, not just doors
- Issue 3 may be partially a Hytale server API limitation — NPC dialogue events may not be exposed server-side. Needs investigation into whether
PlayerInteractEvent fires for dialogue or if it's client-only
- The
getParentFlag() and isParentFlag() methods in ZoneFlags suggest the parent-child system was designed to be enforced but the enforcement was never wired into ProtectionChecker
Plugin Version
0.10.2
Operating System
Linux (Debian/Ubuntu)
Bug Description
Three related zone flag issues affecting interaction control in claimed territory and admin zones:
1. Door flag bypasses parent
block_interactcheckdoor_useis evaluated directly without checking its parent flagblock_interact. The parent-child hierarchy is defined inZoneFlags.getParentFlag()butProtectionChecker.canInteractChunk()mapsDOORdirectly toZoneFlags.DOOR_USEand never verifies the parent. This means disablingblock_interacton a zone does NOT disable doors — you have to toggledoor_useseparately, which defeats the purpose of the parent flag.This likely affects all interaction children:
container_use,bench_use,processing_use,seat_use.2. No zone flag for lights (torches, lanterns)
There is no
light_useortorch_useflag. Light interactions (toggling torches/lanterns) are not specifically handled byBlockUseProtectionSystem— they fall through to the genericOTHERcase which checksblock_interact. There is no way to independently control light toggling in zones (e.g., allow doors but block light toggling, or vice versa).3. No zone flag for NPC dialogue/conversation
NpcInteractionProtectionHandleronly interceptsInteractionType.Use(F-key taming) and maps it toNPC_TAME. There is no flag or handler for NPC dialogue/conversation. Players cannot talk to NPCs in protected territory regardless of flag settings — there is no flag to allow it.Steps to Reproduce
Door parent check:
block_interacttofalsedoor_usetotrueLights:
block_interactgenerically with no granular controlNPC dialogue:
Expected Behavior
door_use,container_use, etc.) should respect their parentblock_interact— if the parent isfalse, children should befalseregardless of their individual settinglight_useflag should exist as a child ofblock_interactto control torch/lantern toggling independentlynpc_dialogueornpc_talkflag should exist to allow/deny NPC conversations in zones, separate fromnpc_tameLogs
No response
Code Snippets
Issue 1 —
ProtectionChecker.canInteractChunk()maps directly without parent check:Parent hierarchy exists but is unused during evaluation:
Media
No response
Additional information
PlayerInteractEventfires for dialogue or if it's client-onlygetParentFlag()andisParentFlag()methods inZoneFlagssuggest the parent-child system was designed to be enforced but the enforcement was never wired intoProtectionChecker