Skip to content

[Bug]: Friendly fire zone flag has no effect on ally PvP in warzones #70

@derrickmehaffy

Description

@derrickmehaffy

Plugin Version

0.9.0 (possibly reported on earlier version — zone settings GUI in screenshot does not match current flag list)

Operating System

Linux (Debian/Ubuntu)

Bug Description

Allied faction players cannot damage each other in a warzone even when the FRIENDLY_FIRE zone flag is explicitly enabled (set to custom ON). The admin toggled the flag both on and off and neither state changed the behavior — allies remained unable to PvP in the warzone.

Reported context: Two players from allied factions ([WORLD] and [WORF]) fighting in a warzone named "FFA Warzone" (WAR type, 36 chunks). Admin (juxe) toggled Friendly Fire to custom ON via the zone settings GUI. Chat shows "allies cant hurt each other" persisting after the toggle.

Code analysis (current version):

The zone-based PvP check in ProtectionChecker.canDamagePlayerChunk() (lines 393-404) appears logically correct:

RelationType relation = relationManager.getPlayerRelation(attackerUuid, defenderUuid);
if (relation == RelationType.ALLY) {
    if (friendlyFireAllowed) {
        // FRIENDLY_FIRE=true → check child flag
        if (!zone.getEffectiveFlag(ZoneFlags.FRIENDLY_FIRE_ALLY)) {
            return PvPResult.DENIED_ALLY;
        }
        // FRIENDLY_FIRE_ALLY defaults to true for warzones → falls through
    } else if (!config.isAllyDamage()) {
        // FRIENDLY_FIRE=false, allyDamage=false → deny
        return PvPResult.DENIED_ALLY;
    }
}
// Falls through to → return ALLOWED_WARZONE

When FRIENDLY_FIRE=true (custom ON) and FRIENDLY_FIRE_ALLY=true (warzone default), the code should fall through and return ALLOWED_WARZONE. The logic appears correct on paper, which means the issue is likely in one of these areas:

  1. Zone not found at combat location: If zoneManager.getZone() returns null for the combat chunk, the code skips to the non-zone path (line 410+) which uses config.isAllyDamage() (default false) as the sole check — denying ally damage regardless of zone flags
  2. Flag persistence issue: The GUI toggle may not persist the flag change to storage, or the zone's in-memory flags map may not reflect the GUI change until a reload
  3. Previous version logic: If this was reported on an earlier version, the friendly fire flag hierarchy may have been implemented differently or the fallback logic may have had a different code path
  4. Config override: allyDamage = false in CoreConfig (line 52) is the global default. When the zone IS found but FRIENDLY_FIRE=false, the code falls back to this config value (line 400). If both paths default to deny, neither toggle state would visibly change behavior unless the zone flag is correctly read AND the zone is correctly found

Key files:

  • ProtectionChecker.java (lines 343-448 — canDamagePlayerChunk(), zone-based PvP check)
  • ZoneFlags.java (lines 85-87 — FRIENDLY_FIRE, FRIENDLY_FIRE_FACTION, FRIENDLY_FIRE_ALLY definitions)
  • ZoneFlags.java (lines 452-459 — warzone defaults: FRIENDLY_FIRE=false, children =true)
  • Zone.java (lines 275-288 — getEffectiveFlag(), flat lookup with zone-type default fallback)
  • CoreConfig.java (line 52 — allyDamage = false global default)
  • PvPDamageProtection.java (lines 58-101 — handle(), delegates to canDamagePlayer())

Steps to Reproduce

  1. Create two factions and set them as allies
  2. Create a warzone (WAR type)
  3. Toggle Friendly Fire to ON (custom) in the zone settings GUI
  4. Have players from the two allied factions attempt to PvP in the warzone
  5. Observe allies cannot damage each other despite the flag being enabled
  6. Toggle Friendly Fire OFF and observe behavior doesn't change either

Expected Behavior

When Friendly Fire is enabled (ON) in a warzone's zone settings, allied faction players should be able to damage each other within that warzone. When disabled (OFF), allies should be protected from each other.

Additional information

  • Reported by server player, admin attempted to fix by toggling the flag in both directions — neither direction affected behavior
  • Zone settings GUI screenshot shows the flag correctly marked as (custom) with checkbox ON
  • May have been reported on a previous version — the zone flag list in the screenshot does not match the current version's flag set
  • Needs reproduction testing on current v0.9.0 to determine if this is still present or was fixed in a recent update
  • Debug logging (/f admin debug protection on) would help identify which code path is taken and what PvPResult is returned

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions