[Feat] Faction Vaults — restricted high-security territory chunks #35

Description

@derrickmehaffy

Scope

  1. Add Faction Vaults — specially designated chunks within a faction's claimed territory that have restricted access controls
  2. Only the faction leader can access vault chunks by default (break, place, interact, open containers)
  3. Leaders can optionally grant officers vault access via a faction permission toggle
  4. Regular faction members, allies, and outsiders are fully blocked from interacting with vault chunks
  5. Vault chunks should be visually distinguishable on the GUI territory map (unique color/icon)
  6. Vault chunks have territorial overclaim protection — they can only be overclaimed if the attacker has a connected overclaim path from wilderness to the vault chunk's border (no skipping over defended territory)
  7. Vault chunks must already be claimed faction territory before being designated as a vault
  8. Configurable limit on how many vault chunks a faction can have (e.g., based on faction size or permission node)

Implementation Details

  1. Data model: Add vault designation to the claim system

    // In Faction or ClaimManager dataSet<ChunkKey> vaultChunks; // subset of claimed chunks marked as vault
  2. Commands:

    • /f vault — toggle vault designation on the chunk you're standing in (must be own claimed territory)
    • /f vault list — list all vault chunks with coordinates
    • /f vault info — show vault status of current chunk
    • /f admin vault <faction> add/remove <x> <z> — admin vault management
    • /f admin vault <faction> list — admin view of faction's vaults
    • /f admin vault <faction> clear — remove all vault designations
  3. Faction permission toggle (in faction settings):

    • officerVaultAccess (default: false) — when enabled, officers can access vault chunks alongside the leader
    • Configurable in the Faction Settings GUI under a "Vault" or "Security" section
  4. Protection integration: Modify ProtectionChecker to add vault-aware access checks

    • When a chunk is a vault chunk, override normal faction territory permissions:
      • Leader: always allowed
      • Officers: allowed only if officerVaultAccess is enabled
      • Members: denied (with vault-specific denial message)
      • Allies/outsiders: denied (normal territory denial)
    • Applies to: block break, block place, block interact, container access, fluid placement/pickup
    • Admin bypass still works (hyperfactions.bypass.*)
  5. Overclaim protection: Vault chunks use territorial adjacency for overclaim eligibility

    • A vault chunk can only be overclaimed if the attacking faction has already overclaimed (or the chunk is unclaimed) at least one directly adjacent chunk (N/S/E/W)
    • This means attackers must push a connected overclaim path from wilderness through the faction's outer territory to reach the vault — they can't just cherry-pick the vault chunk from anywhere
    • Non-vault chunks follow normal overclaim rules (unchanged)
    • This makes vaults harder to reach but not impossible — a determined attacker who pushes through the territory can still breach the vault
    • Vault status is removed when a chunk is overclaimed
  6. GUI integration:

    • Territory map: vault chunks shown with a distinct color (e.g., gold/amber) or overlay pattern
    • Faction Settings: "Vault" section with officer access toggle and vault count display
    • Dashboard: vault count shown alongside claims count (e.g., "Claims: 12 (3 vaults)")
    • Admin faction detail: vault chunk list with remove buttons
  7. Config in config.json:

    {
    "vaults": {
    "enabled": true,
    "maxVaultsPerFaction": 3,
    "maxVaultsPermissionScaling": true,
    "requireAdjacentOverclaim": true,
    "defaultOfficerAccess": false
    }
    }
  8. Permission nodes:

    • hyperfactions.vault.designate — designate/undesignate vault chunks
    • hyperfactions.vault.list — view vault chunk list
    • hyperfactions.vault.limit.<n> — override max vault count (e.g., vault.limit.5 for VIP)
    • hyperfactions.admin.vault — admin vault management
    • hyperfactions.bypass.vault — bypass vault access restrictions
  9. Denial messages:

    • Members: "This is a faction vault. Only the leader can access this area."
    • Members (with officer access on): "This is a faction vault. Only officers and the leader can access this area."
    • Overclaim attempt without adjacency: "This vault chunk can only be overclaimed from adjacent territory. Push through the faction's borders first."

Risks and Alternatives

  1. Risk: Adding a vault layer to the protection checker increases complexity in an already multi-layered system (zones → faction territory → vault) — needs careful ordering so vault checks don't conflict with zone overrides or admin bypass
  2. Challenge: Vault chunks that become unclaimed (faction loses power) need to have their vault status cleaned up properly
  3. Challenge: If a leader goes inactive, vault contents become inaccessible to the rest of the faction — consider adding a "vault lockout timer" where officers gain access after the leader is offline for N days
  4. Challenge: The adjacency check for overclaim needs to handle edge cases — what if the vault is on the faction's border already (adjacent to wilderness)? It should be overclaimable normally in that case since there's nothing to push through
  5. Alternative: Instead of chunk-based vaults, could implement container-level locking (lock individual chests/storage) — more granular but much more complex to implement and track
  6. Alternative: Could use the existing zone flag system with a new "vault" flag on specific chunks rather than a separate vault concept — simpler but less intuitive for players
  7. Alternative: Could tie vault count to faction power level instead of a flat config cap — rewards stronger factions with more secure storage

References and Media

  1. Similar concept in Factions plugins: "faction vaults" typically refer to shared storage GUIs, but this proposal is territory-based protection which is more aligned with real fortress/keep mechanics
  2. Existing protection infrastructure: ProtectionChecker.canInteract(), ClaimManager, FactionPermissions
  3. Existing territory map rendering: FactionMapPage, WorldMapOverlayProvider — vault chunks need a new color entry
  4. Existing faction permissions model: FactionPermissions with boolean toggles — officerVaultAccess follows the same pattern
  5. Overclaim logic: ClaimManager.overclaim() — adjacency check is a simple N/S/E/W neighbor lookup on ChunkKey

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
     blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
    }
    } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
    })();
    (function(){
    try {
    var __m = "github.com";
    var __re = new RegExp('^' + "github\\.com" + '
    
    Skip to content

    [Feat] Faction Vaults — restricted high-security territory chunks #35

    Description

    @derrickmehaffy

    Scope

    1. Add Faction Vaults — specially designated chunks within a faction's claimed territory that have restricted access controls
    2. Only the faction leader can access vault chunks by default (break, place, interact, open containers)
    3. Leaders can optionally grant officers vault access via a faction permission toggle
    4. Regular faction members, allies, and outsiders are fully blocked from interacting with vault chunks
    5. Vault chunks should be visually distinguishable on the GUI territory map (unique color/icon)
    6. Vault chunks have territorial overclaim protection — they can only be overclaimed if the attacker has a connected overclaim path from wilderness to the vault chunk's border (no skipping over defended territory)
    7. Vault chunks must already be claimed faction territory before being designated as a vault
    8. Configurable limit on how many vault chunks a faction can have (e.g., based on faction size or permission node)

    Implementation Details

    1. Data model: Add vault designation to the claim system

      // In Faction or ClaimManager dataSet<ChunkKey> vaultChunks; // subset of claimed chunks marked as vault
    2. Commands:

      • /f vault — toggle vault designation on the chunk you're standing in (must be own claimed territory)
      • /f vault list — list all vault chunks with coordinates
      • /f vault info — show vault status of current chunk
      • /f admin vault <faction> add/remove <x> <z> — admin vault management
      • /f admin vault <faction> list — admin view of faction's vaults
      • /f admin vault <faction> clear — remove all vault designations
    3. Faction permission toggle (in faction settings):

      • officerVaultAccess (default: false) — when enabled, officers can access vault chunks alongside the leader
      • Configurable in the Faction Settings GUI under a "Vault" or "Security" section
    4. Protection integration: Modify ProtectionChecker to add vault-aware access checks

      • When a chunk is a vault chunk, override normal faction territory permissions:
        • Leader: always allowed
        • Officers: allowed only if officerVaultAccess is enabled
        • Members: denied (with vault-specific denial message)
        • Allies/outsiders: denied (normal territory denial)
      • Applies to: block break, block place, block interact, container access, fluid placement/pickup
      • Admin bypass still works (hyperfactions.bypass.*)
    5. Overclaim protection: Vault chunks use territorial adjacency for overclaim eligibility

      • A vault chunk can only be overclaimed if the attacking faction has already overclaimed (or the chunk is unclaimed) at least one directly adjacent chunk (N/S/E/W)
      • This means attackers must push a connected overclaim path from wilderness through the faction's outer territory to reach the vault — they can't just cherry-pick the vault chunk from anywhere
      • Non-vault chunks follow normal overclaim rules (unchanged)
      • This makes vaults harder to reach but not impossible — a determined attacker who pushes through the territory can still breach the vault
      • Vault status is removed when a chunk is overclaimed
    6. GUI integration:

      • Territory map: vault chunks shown with a distinct color (e.g., gold/amber) or overlay pattern
      • Faction Settings: "Vault" section with officer access toggle and vault count display
      • Dashboard: vault count shown alongside claims count (e.g., "Claims: 12 (3 vaults)")
      • Admin faction detail: vault chunk list with remove buttons
    7. Config in config.json:

      {
      "vaults": {
      "enabled": true,
      "maxVaultsPerFaction": 3,
      "maxVaultsPermissionScaling": true,
      "requireAdjacentOverclaim": true,
      "defaultOfficerAccess": false
      }
      }
    8. Permission nodes:

      • hyperfactions.vault.designate — designate/undesignate vault chunks
      • hyperfactions.vault.list — view vault chunk list
      • hyperfactions.vault.limit.<n> — override max vault count (e.g., vault.limit.5 for VIP)
      • hyperfactions.admin.vault — admin vault management
      • hyperfactions.bypass.vault — bypass vault access restrictions
    9. Denial messages:

      • Members: "This is a faction vault. Only the leader can access this area."
      • Members (with officer access on): "This is a faction vault. Only officers and the leader can access this area."
      • Overclaim attempt without adjacency: "This vault chunk can only be overclaimed from adjacent territory. Push through the faction's borders first."

    Risks and Alternatives

    1. Risk: Adding a vault layer to the protection checker increases complexity in an already multi-layered system (zones → faction territory → vault) — needs careful ordering so vault checks don't conflict with zone overrides or admin bypass
    2. Challenge: Vault chunks that become unclaimed (faction loses power) need to have their vault status cleaned up properly
    3. Challenge: If a leader goes inactive, vault contents become inaccessible to the rest of the faction — consider adding a "vault lockout timer" where officers gain access after the leader is offline for N days
    4. Challenge: The adjacency check for overclaim needs to handle edge cases — what if the vault is on the faction's border already (adjacent to wilderness)? It should be overclaimable normally in that case since there's nothing to push through
    5. Alternative: Instead of chunk-based vaults, could implement container-level locking (lock individual chests/storage) — more granular but much more complex to implement and track
    6. Alternative: Could use the existing zone flag system with a new "vault" flag on specific chunks rather than a separate vault concept — simpler but less intuitive for players
    7. Alternative: Could tie vault count to faction power level instead of a flat config cap — rewards stronger factions with more secure storage

    References and Media

    1. Similar concept in Factions plugins: "faction vaults" typically refer to shared storage GUIs, but this proposal is territory-based protection which is more aligned with real fortress/keep mechanics
    2. Existing protection infrastructure: ProtectionChecker.canInteract(), ClaimManager, FactionPermissions
    3. Existing territory map rendering: FactionMapPage, WorldMapOverlayProvider — vault chunks need a new color entry
    4. Existing faction permissions model: FactionPermissions with boolean toggles — officerVaultAccess follows the same pattern
    5. Overclaim logic: ClaimManager.overclaim() — adjacency check is a simple N/S/E/W neighbor lookup on ChunkKey

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      enhancementNew feature or request

      Type

      No type

      Projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
      Skip to content

      [Feat] Faction Vaults — restricted high-security territory chunks #35

      Description

      @derrickmehaffy

      Scope

      1. Add Faction Vaults — specially designated chunks within a faction's claimed territory that have restricted access controls
      2. Only the faction leader can access vault chunks by default (break, place, interact, open containers)
      3. Leaders can optionally grant officers vault access via a faction permission toggle
      4. Regular faction members, allies, and outsiders are fully blocked from interacting with vault chunks
      5. Vault chunks should be visually distinguishable on the GUI territory map (unique color/icon)
      6. Vault chunks have territorial overclaim protection — they can only be overclaimed if the attacker has a connected overclaim path from wilderness to the vault chunk's border (no skipping over defended territory)
      7. Vault chunks must already be claimed faction territory before being designated as a vault
      8. Configurable limit on how many vault chunks a faction can have (e.g., based on faction size or permission node)

      Implementation Details

      1. Data model: Add vault designation to the claim system

        // In Faction or ClaimManager dataSet<ChunkKey> vaultChunks; // subset of claimed chunks marked as vault
      2. Commands:

        • /f vault — toggle vault designation on the chunk you're standing in (must be own claimed territory)
        • /f vault list — list all vault chunks with coordinates
        • /f vault info — show vault status of current chunk
        • /f admin vault <faction> add/remove <x> <z> — admin vault management
        • /f admin vault <faction> list — admin view of faction's vaults
        • /f admin vault <faction> clear — remove all vault designations
      3. Faction permission toggle (in faction settings):

        • officerVaultAccess (default: false) — when enabled, officers can access vault chunks alongside the leader
        • Configurable in the Faction Settings GUI under a "Vault" or "Security" section
      4. Protection integration: Modify ProtectionChecker to add vault-aware access checks

        • When a chunk is a vault chunk, override normal faction territory permissions:
          • Leader: always allowed
          • Officers: allowed only if officerVaultAccess is enabled
          • Members: denied (with vault-specific denial message)
          • Allies/outsiders: denied (normal territory denial)
        • Applies to: block break, block place, block interact, container access, fluid placement/pickup
        • Admin bypass still works (hyperfactions.bypass.*)
      5. Overclaim protection: Vault chunks use territorial adjacency for overclaim eligibility

        • A vault chunk can only be overclaimed if the attacking faction has already overclaimed (or the chunk is unclaimed) at least one directly adjacent chunk (N/S/E/W)
        • This means attackers must push a connected overclaim path from wilderness through the faction's outer territory to reach the vault — they can't just cherry-pick the vault chunk from anywhere
        • Non-vault chunks follow normal overclaim rules (unchanged)
        • This makes vaults harder to reach but not impossible — a determined attacker who pushes through the territory can still breach the vault
        • Vault status is removed when a chunk is overclaimed
      6. GUI integration:

        • Territory map: vault chunks shown with a distinct color (e.g., gold/amber) or overlay pattern
        • Faction Settings: "Vault" section with officer access toggle and vault count display
        • Dashboard: vault count shown alongside claims count (e.g., "Claims: 12 (3 vaults)")
        • Admin faction detail: vault chunk list with remove buttons
      7. Config in config.json:

        {
        "vaults": {
        "enabled": true,
        "maxVaultsPerFaction": 3,
        "maxVaultsPermissionScaling": true,
        "requireAdjacentOverclaim": true,
        "defaultOfficerAccess": false
        }
        }
      8. Permission nodes:

        • hyperfactions.vault.designate — designate/undesignate vault chunks
        • hyperfactions.vault.list — view vault chunk list
        • hyperfactions.vault.limit.<n> — override max vault count (e.g., vault.limit.5 for VIP)
        • hyperfactions.admin.vault — admin vault management
        • hyperfactions.bypass.vault — bypass vault access restrictions
      9. Denial messages:

        • Members: "This is a faction vault. Only the leader can access this area."
        • Members (with officer access on): "This is a faction vault. Only officers and the leader can access this area."
        • Overclaim attempt without adjacency: "This vault chunk can only be overclaimed from adjacent territory. Push through the faction's borders first."

      Risks and Alternatives

      1. Risk: Adding a vault layer to the protection checker increases complexity in an already multi-layered system (zones → faction territory → vault) — needs careful ordering so vault checks don't conflict with zone overrides or admin bypass
      2. Challenge: Vault chunks that become unclaimed (faction loses power) need to have their vault status cleaned up properly
      3. Challenge: If a leader goes inactive, vault contents become inaccessible to the rest of the faction — consider adding a "vault lockout timer" where officers gain access after the leader is offline for N days
      4. Challenge: The adjacency check for overclaim needs to handle edge cases — what if the vault is on the faction's border already (adjacent to wilderness)? It should be overclaimable normally in that case since there's nothing to push through
      5. Alternative: Instead of chunk-based vaults, could implement container-level locking (lock individual chests/storage) — more granular but much more complex to implement and track
      6. Alternative: Could use the existing zone flag system with a new "vault" flag on specific chunks rather than a separate vault concept — simpler but less intuitive for players
      7. Alternative: Could tie vault count to faction power level instead of a flat config cap — rewards stronger factions with more secure storage

      References and Media

      1. Similar concept in Factions plugins: "faction vaults" typically refer to shared storage GUIs, but this proposal is territory-based protection which is more aligned with real fortress/keep mechanics
      2. Existing protection infrastructure: ProtectionChecker.canInteract(), ClaimManager, FactionPermissions
      3. Existing territory map rendering: FactionMapPage, WorldMapOverlayProvider — vault chunks need a new color entry
      4. Existing faction permissions model: FactionPermissions with boolean toggles — officerVaultAccess follows the same pattern
      5. Overclaim logic: ClaimManager.overclaim() — adjacency check is a simple N/S/E/W neighbor lookup on ChunkKey

      Metadata

      Metadata

      Assignees

      No one assigned

        Labels

        enhancementNew feature or request

        Type

        No type

        Projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions

        , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
        Skip to content

        [Feat] Faction Vaults — restricted high-security territory chunks #35

        Description

        @derrickmehaffy

        Scope

        1. Add Faction Vaults — specially designated chunks within a faction's claimed territory that have restricted access controls
        2. Only the faction leader can access vault chunks by default (break, place, interact, open containers)
        3. Leaders can optionally grant officers vault access via a faction permission toggle
        4. Regular faction members, allies, and outsiders are fully blocked from interacting with vault chunks
        5. Vault chunks should be visually distinguishable on the GUI territory map (unique color/icon)
        6. Vault chunks have territorial overclaim protection — they can only be overclaimed if the attacker has a connected overclaim path from wilderness to the vault chunk's border (no skipping over defended territory)
        7. Vault chunks must already be claimed faction territory before being designated as a vault
        8. Configurable limit on how many vault chunks a faction can have (e.g., based on faction size or permission node)

        Implementation Details

        1. Data model: Add vault designation to the claim system

          // In Faction or ClaimManager dataSet<ChunkKey> vaultChunks; // subset of claimed chunks marked as vault
        2. Commands:

          • /f vault — toggle vault designation on the chunk you're standing in (must be own claimed territory)
          • /f vault list — list all vault chunks with coordinates
          • /f vault info — show vault status of current chunk
          • /f admin vault <faction> add/remove <x> <z> — admin vault management
          • /f admin vault <faction> list — admin view of faction's vaults
          • /f admin vault <faction> clear — remove all vault designations
        3. Faction permission toggle (in faction settings):

          • officerVaultAccess (default: false) — when enabled, officers can access vault chunks alongside the leader
          • Configurable in the Faction Settings GUI under a "Vault" or "Security" section
        4. Protection integration: Modify ProtectionChecker to add vault-aware access checks

          • When a chunk is a vault chunk, override normal faction territory permissions:
            • Leader: always allowed
            • Officers: allowed only if officerVaultAccess is enabled
            • Members: denied (with vault-specific denial message)
            • Allies/outsiders: denied (normal territory denial)
          • Applies to: block break, block place, block interact, container access, fluid placement/pickup
          • Admin bypass still works (hyperfactions.bypass.*)
        5. Overclaim protection: Vault chunks use territorial adjacency for overclaim eligibility

          • A vault chunk can only be overclaimed if the attacking faction has already overclaimed (or the chunk is unclaimed) at least one directly adjacent chunk (N/S/E/W)
          • This means attackers must push a connected overclaim path from wilderness through the faction's outer territory to reach the vault — they can't just cherry-pick the vault chunk from anywhere
          • Non-vault chunks follow normal overclaim rules (unchanged)
          • This makes vaults harder to reach but not impossible — a determined attacker who pushes through the territory can still breach the vault
          • Vault status is removed when a chunk is overclaimed
        6. GUI integration:

          • Territory map: vault chunks shown with a distinct color (e.g., gold/amber) or overlay pattern
          • Faction Settings: "Vault" section with officer access toggle and vault count display
          • Dashboard: vault count shown alongside claims count (e.g., "Claims: 12 (3 vaults)")
          • Admin faction detail: vault chunk list with remove buttons
        7. Config in config.json:

          {
          "vaults": {
          "enabled": true,
          "maxVaultsPerFaction": 3,
          "maxVaultsPermissionScaling": true,
          "requireAdjacentOverclaim": true,
          "defaultOfficerAccess": false
          }
          }
        8. Permission nodes:

          • hyperfactions.vault.designate — designate/undesignate vault chunks
          • hyperfactions.vault.list — view vault chunk list
          • hyperfactions.vault.limit.<n> — override max vault count (e.g., vault.limit.5 for VIP)
          • hyperfactions.admin.vault — admin vault management
          • hyperfactions.bypass.vault — bypass vault access restrictions
        9. Denial messages:

          • Members: "This is a faction vault. Only the leader can access this area."
          • Members (with officer access on): "This is a faction vault. Only officers and the leader can access this area."
          • Overclaim attempt without adjacency: "This vault chunk can only be overclaimed from adjacent territory. Push through the faction's borders first."

        Risks and Alternatives

        1. Risk: Adding a vault layer to the protection checker increases complexity in an already multi-layered system (zones → faction territory → vault) — needs careful ordering so vault checks don't conflict with zone overrides or admin bypass
        2. Challenge: Vault chunks that become unclaimed (faction loses power) need to have their vault status cleaned up properly
        3. Challenge: If a leader goes inactive, vault contents become inaccessible to the rest of the faction — consider adding a "vault lockout timer" where officers gain access after the leader is offline for N days
        4. Challenge: The adjacency check for overclaim needs to handle edge cases — what if the vault is on the faction's border already (adjacent to wilderness)? It should be overclaimable normally in that case since there's nothing to push through
        5. Alternative: Instead of chunk-based vaults, could implement container-level locking (lock individual chests/storage) — more granular but much more complex to implement and track
        6. Alternative: Could use the existing zone flag system with a new "vault" flag on specific chunks rather than a separate vault concept — simpler but less intuitive for players
        7. Alternative: Could tie vault count to faction power level instead of a flat config cap — rewards stronger factions with more secure storage

        References and Media

        1. Similar concept in Factions plugins: "faction vaults" typically refer to shared storage GUIs, but this proposal is territory-based protection which is more aligned with real fortress/keep mechanics
        2. Existing protection infrastructure: ProtectionChecker.canInteract(), ClaimManager, FactionPermissions
        3. Existing territory map rendering: FactionMapPage, WorldMapOverlayProvider — vault chunks need a new color entry
        4. Existing faction permissions model: FactionPermissions with boolean toggles — officerVaultAccess follows the same pattern
        5. Overclaim logic: ClaimManager.overclaim() — adjacency check is a simple N/S/E/W neighbor lookup on ChunkKey

        Metadata

        Metadata

        Assignees

        No one assigned

          Labels

          enhancementNew feature or request

          Type

          No type

          Projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
          Skip to content

          [Feat] Faction Vaults — restricted high-security territory chunks #35

          Description

          @derrickmehaffy

          Scope

          1. Add Faction Vaults — specially designated chunks within a faction's claimed territory that have restricted access controls
          2. Only the faction leader can access vault chunks by default (break, place, interact, open containers)
          3. Leaders can optionally grant officers vault access via a faction permission toggle
          4. Regular faction members, allies, and outsiders are fully blocked from interacting with vault chunks
          5. Vault chunks should be visually distinguishable on the GUI territory map (unique color/icon)
          6. Vault chunks have territorial overclaim protection — they can only be overclaimed if the attacker has a connected overclaim path from wilderness to the vault chunk's border (no skipping over defended territory)
          7. Vault chunks must already be claimed faction territory before being designated as a vault
          8. Configurable limit on how many vault chunks a faction can have (e.g., based on faction size or permission node)

          Implementation Details

          1. Data model: Add vault designation to the claim system

            // In Faction or ClaimManager dataSet<ChunkKey> vaultChunks; // subset of claimed chunks marked as vault
          2. Commands:

            • /f vault — toggle vault designation on the chunk you're standing in (must be own claimed territory)
            • /f vault list — list all vault chunks with coordinates
            • /f vault info — show vault status of current chunk
            • /f admin vault <faction> add/remove <x> <z> — admin vault management
            • /f admin vault <faction> list — admin view of faction's vaults
            • /f admin vault <faction> clear — remove all vault designations
          3. Faction permission toggle (in faction settings):

            • officerVaultAccess (default: false) — when enabled, officers can access vault chunks alongside the leader
            • Configurable in the Faction Settings GUI under a "Vault" or "Security" section
          4. Protection integration: Modify ProtectionChecker to add vault-aware access checks

            • When a chunk is a vault chunk, override normal faction territory permissions:
              • Leader: always allowed
              • Officers: allowed only if officerVaultAccess is enabled
              • Members: denied (with vault-specific denial message)
              • Allies/outsiders: denied (normal territory denial)
            • Applies to: block break, block place, block interact, container access, fluid placement/pickup
            • Admin bypass still works (hyperfactions.bypass.*)
          5. Overclaim protection: Vault chunks use territorial adjacency for overclaim eligibility

            • A vault chunk can only be overclaimed if the attacking faction has already overclaimed (or the chunk is unclaimed) at least one directly adjacent chunk (N/S/E/W)
            • This means attackers must push a connected overclaim path from wilderness through the faction's outer territory to reach the vault — they can't just cherry-pick the vault chunk from anywhere
            • Non-vault chunks follow normal overclaim rules (unchanged)
            • This makes vaults harder to reach but not impossible — a determined attacker who pushes through the territory can still breach the vault
            • Vault status is removed when a chunk is overclaimed
          6. GUI integration:

            • Territory map: vault chunks shown with a distinct color (e.g., gold/amber) or overlay pattern
            • Faction Settings: "Vault" section with officer access toggle and vault count display
            • Dashboard: vault count shown alongside claims count (e.g., "Claims: 12 (3 vaults)")
            • Admin faction detail: vault chunk list with remove buttons
          7. Config in config.json:

            {
            "vaults": {
            "enabled": true,
            "maxVaultsPerFaction": 3,
            "maxVaultsPermissionScaling": true,
            "requireAdjacentOverclaim": true,
            "defaultOfficerAccess": false
            }
            }
          8. Permission nodes:

            • hyperfactions.vault.designate — designate/undesignate vault chunks
            • hyperfactions.vault.list — view vault chunk list
            • hyperfactions.vault.limit.<n> — override max vault count (e.g., vault.limit.5 for VIP)
            • hyperfactions.admin.vault — admin vault management
            • hyperfactions.bypass.vault — bypass vault access restrictions
          9. Denial messages:

            • Members: "This is a faction vault. Only the leader can access this area."
            • Members (with officer access on): "This is a faction vault. Only officers and the leader can access this area."
            • Overclaim attempt without adjacency: "This vault chunk can only be overclaimed from adjacent territory. Push through the faction's borders first."

          Risks and Alternatives

          1. Risk: Adding a vault layer to the protection checker increases complexity in an already multi-layered system (zones → faction territory → vault) — needs careful ordering so vault checks don't conflict with zone overrides or admin bypass
          2. Challenge: Vault chunks that become unclaimed (faction loses power) need to have their vault status cleaned up properly
          3. Challenge: If a leader goes inactive, vault contents become inaccessible to the rest of the faction — consider adding a "vault lockout timer" where officers gain access after the leader is offline for N days
          4. Challenge: The adjacency check for overclaim needs to handle edge cases — what if the vault is on the faction's border already (adjacent to wilderness)? It should be overclaimable normally in that case since there's nothing to push through
          5. Alternative: Instead of chunk-based vaults, could implement container-level locking (lock individual chests/storage) — more granular but much more complex to implement and track
          6. Alternative: Could use the existing zone flag system with a new "vault" flag on specific chunks rather than a separate vault concept — simpler but less intuitive for players
          7. Alternative: Could tie vault count to faction power level instead of a flat config cap — rewards stronger factions with more secure storage

          References and Media

          1. Similar concept in Factions plugins: "faction vaults" typically refer to shared storage GUIs, but this proposal is territory-based protection which is more aligned with real fortress/keep mechanics
          2. Existing protection infrastructure: ProtectionChecker.canInteract(), ClaimManager, FactionPermissions
          3. Existing territory map rendering: FactionMapPage, WorldMapOverlayProvider — vault chunks need a new color entry
          4. Existing faction permissions model: FactionPermissions with boolean toggles — officerVaultAccess follows the same pattern
          5. Overclaim logic: ClaimManager.overclaim() — adjacency check is a simple N/S/E/W neighbor lookup on ChunkKey

          Metadata

          Metadata

          Assignees

          No one assigned

            Labels

            enhancementNew feature or request

            Type

            No type

            Projects

            Milestone

            No milestone

            Relationships

            None yet

            Development

            No branches or pull requests

            Issue actions

            , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
            Skip to content

            [Feat] Faction Vaults — restricted high-security territory chunks #35

            Description

            @derrickmehaffy

            Scope

            1. Add Faction Vaults — specially designated chunks within a faction's claimed territory that have restricted access controls
            2. Only the faction leader can access vault chunks by default (break, place, interact, open containers)
            3. Leaders can optionally grant officers vault access via a faction permission toggle
            4. Regular faction members, allies, and outsiders are fully blocked from interacting with vault chunks
            5. Vault chunks should be visually distinguishable on the GUI territory map (unique color/icon)
            6. Vault chunks have territorial overclaim protection — they can only be overclaimed if the attacker has a connected overclaim path from wilderness to the vault chunk's border (no skipping over defended territory)
            7. Vault chunks must already be claimed faction territory before being designated as a vault
            8. Configurable limit on how many vault chunks a faction can have (e.g., based on faction size or permission node)

            Implementation Details

            1. Data model: Add vault designation to the claim system

              // In Faction or ClaimManager dataSet<ChunkKey> vaultChunks; // subset of claimed chunks marked as vault
            2. Commands:

              • /f vault — toggle vault designation on the chunk you're standing in (must be own claimed territory)
              • /f vault list — list all vault chunks with coordinates
              • /f vault info — show vault status of current chunk
              • /f admin vault <faction> add/remove <x> <z> — admin vault management
              • /f admin vault <faction> list — admin view of faction's vaults
              • /f admin vault <faction> clear — remove all vault designations
            3. Faction permission toggle (in faction settings):

              • officerVaultAccess (default: false) — when enabled, officers can access vault chunks alongside the leader
              • Configurable in the Faction Settings GUI under a "Vault" or "Security" section
            4. Protection integration: Modify ProtectionChecker to add vault-aware access checks

              • When a chunk is a vault chunk, override normal faction territory permissions:
                • Leader: always allowed
                • Officers: allowed only if officerVaultAccess is enabled
                • Members: denied (with vault-specific denial message)
                • Allies/outsiders: denied (normal territory denial)
              • Applies to: block break, block place, block interact, container access, fluid placement/pickup
              • Admin bypass still works (hyperfactions.bypass.*)
            5. Overclaim protection: Vault chunks use territorial adjacency for overclaim eligibility

              • A vault chunk can only be overclaimed if the attacking faction has already overclaimed (or the chunk is unclaimed) at least one directly adjacent chunk (N/S/E/W)
              • This means attackers must push a connected overclaim path from wilderness through the faction's outer territory to reach the vault — they can't just cherry-pick the vault chunk from anywhere
              • Non-vault chunks follow normal overclaim rules (unchanged)
              • This makes vaults harder to reach but not impossible — a determined attacker who pushes through the territory can still breach the vault
              • Vault status is removed when a chunk is overclaimed
            6. GUI integration:

              • Territory map: vault chunks shown with a distinct color (e.g., gold/amber) or overlay pattern
              • Faction Settings: "Vault" section with officer access toggle and vault count display
              • Dashboard: vault count shown alongside claims count (e.g., "Claims: 12 (3 vaults)")
              • Admin faction detail: vault chunk list with remove buttons
            7. Config in config.json:

              {
              "vaults": {
              "enabled": true,
              "maxVaultsPerFaction": 3,
              "maxVaultsPermissionScaling": true,
              "requireAdjacentOverclaim": true,
              "defaultOfficerAccess": false
              }
              }
            8. Permission nodes:

              • hyperfactions.vault.designate — designate/undesignate vault chunks
              • hyperfactions.vault.list — view vault chunk list
              • hyperfactions.vault.limit.<n> — override max vault count (e.g., vault.limit.5 for VIP)
              • hyperfactions.admin.vault — admin vault management
              • hyperfactions.bypass.vault — bypass vault access restrictions
            9. Denial messages:

              • Members: "This is a faction vault. Only the leader can access this area."
              • Members (with officer access on): "This is a faction vault. Only officers and the leader can access this area."
              • Overclaim attempt without adjacency: "This vault chunk can only be overclaimed from adjacent territory. Push through the faction's borders first."

            Risks and Alternatives

            1. Risk: Adding a vault layer to the protection checker increases complexity in an already multi-layered system (zones → faction territory → vault) — needs careful ordering so vault checks don't conflict with zone overrides or admin bypass
            2. Challenge: Vault chunks that become unclaimed (faction loses power) need to have their vault status cleaned up properly
            3. Challenge: If a leader goes inactive, vault contents become inaccessible to the rest of the faction — consider adding a "vault lockout timer" where officers gain access after the leader is offline for N days
            4. Challenge: The adjacency check for overclaim needs to handle edge cases — what if the vault is on the faction's border already (adjacent to wilderness)? It should be overclaimable normally in that case since there's nothing to push through
            5. Alternative: Instead of chunk-based vaults, could implement container-level locking (lock individual chests/storage) — more granular but much more complex to implement and track
            6. Alternative: Could use the existing zone flag system with a new "vault" flag on specific chunks rather than a separate vault concept — simpler but less intuitive for players
            7. Alternative: Could tie vault count to faction power level instead of a flat config cap — rewards stronger factions with more secure storage

            References and Media

            1. Similar concept in Factions plugins: "faction vaults" typically refer to shared storage GUIs, but this proposal is territory-based protection which is more aligned with real fortress/keep mechanics
            2. Existing protection infrastructure: ProtectionChecker.canInteract(), ClaimManager, FactionPermissions
            3. Existing territory map rendering: FactionMapPage, WorldMapOverlayProvider — vault chunks need a new color entry
            4. Existing faction permissions model: FactionPermissions with boolean toggles — officerVaultAccess follows the same pattern
            5. Overclaim logic: ClaimManager.overclaim() — adjacency check is a simple N/S/E/W neighbor lookup on ChunkKey

            Metadata

            Metadata

            Assignees

            No one assigned

              Labels

              enhancementNew feature or request

              Type

              No type

              Projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              [Feat] Faction Vaults — restricted high-security territory chunks #35

              Description

              @derrickmehaffy

              Scope

              1. Add Faction Vaults — specially designated chunks within a faction's claimed territory that have restricted access controls
              2. Only the faction leader can access vault chunks by default (break, place, interact, open containers)
              3. Leaders can optionally grant officers vault access via a faction permission toggle
              4. Regular faction members, allies, and outsiders are fully blocked from interacting with vault chunks
              5. Vault chunks should be visually distinguishable on the GUI territory map (unique color/icon)
              6. Vault chunks have territorial overclaim protection — they can only be overclaimed if the attacker has a connected overclaim path from wilderness to the vault chunk's border (no skipping over defended territory)
              7. Vault chunks must already be claimed faction territory before being designated as a vault
              8. Configurable limit on how many vault chunks a faction can have (e.g., based on faction size or permission node)

              Implementation Details

              1. Data model: Add vault designation to the claim system

                // In Faction or ClaimManager dataSet<ChunkKey> vaultChunks; // subset of claimed chunks marked as vault
              2. Commands:

                • /f vault — toggle vault designation on the chunk you're standing in (must be own claimed territory)
                • /f vault list — list all vault chunks with coordinates
                • /f vault info — show vault status of current chunk
                • /f admin vault <faction> add/remove <x> <z> — admin vault management
                • /f admin vault <faction> list — admin view of faction's vaults
                • /f admin vault <faction> clear — remove all vault designations
              3. Faction permission toggle (in faction settings):

                • officerVaultAccess (default: false) — when enabled, officers can access vault chunks alongside the leader
                • Configurable in the Faction Settings GUI under a "Vault" or "Security" section
              4. Protection integration: Modify ProtectionChecker to add vault-aware access checks

                • When a chunk is a vault chunk, override normal faction territory permissions:
                  • Leader: always allowed
                  • Officers: allowed only if officerVaultAccess is enabled
                  • Members: denied (with vault-specific denial message)
                  • Allies/outsiders: denied (normal territory denial)
                • Applies to: block break, block place, block interact, container access, fluid placement/pickup
                • Admin bypass still works (hyperfactions.bypass.*)
              5. Overclaim protection: Vault chunks use territorial adjacency for overclaim eligibility

                • A vault chunk can only be overclaimed if the attacking faction has already overclaimed (or the chunk is unclaimed) at least one directly adjacent chunk (N/S/E/W)
                • This means attackers must push a connected overclaim path from wilderness through the faction's outer territory to reach the vault — they can't just cherry-pick the vault chunk from anywhere
                • Non-vault chunks follow normal overclaim rules (unchanged)
                • This makes vaults harder to reach but not impossible — a determined attacker who pushes through the territory can still breach the vault
                • Vault status is removed when a chunk is overclaimed
              6. GUI integration:

                • Territory map: vault chunks shown with a distinct color (e.g., gold/amber) or overlay pattern
                • Faction Settings: "Vault" section with officer access toggle and vault count display
                • Dashboard: vault count shown alongside claims count (e.g., "Claims: 12 (3 vaults)")
                • Admin faction detail: vault chunk list with remove buttons
              7. Config in config.json:

                {
                "vaults": {
                "enabled": true,
                "maxVaultsPerFaction": 3,
                "maxVaultsPermissionScaling": true,
                "requireAdjacentOverclaim": true,
                "defaultOfficerAccess": false
                }
                }
              8. Permission nodes:

                • hyperfactions.vault.designate — designate/undesignate vault chunks
                • hyperfactions.vault.list — view vault chunk list
                • hyperfactions.vault.limit.<n> — override max vault count (e.g., vault.limit.5 for VIP)
                • hyperfactions.admin.vault — admin vault management
                • hyperfactions.bypass.vault — bypass vault access restrictions
              9. Denial messages:

                • Members: "This is a faction vault. Only the leader can access this area."
                • Members (with officer access on): "This is a faction vault. Only officers and the leader can access this area."
                • Overclaim attempt without adjacency: "This vault chunk can only be overclaimed from adjacent territory. Push through the faction's borders first."

              Risks and Alternatives

              1. Risk: Adding a vault layer to the protection checker increases complexity in an already multi-layered system (zones → faction territory → vault) — needs careful ordering so vault checks don't conflict with zone overrides or admin bypass
              2. Challenge: Vault chunks that become unclaimed (faction loses power) need to have their vault status cleaned up properly
              3. Challenge: If a leader goes inactive, vault contents become inaccessible to the rest of the faction — consider adding a "vault lockout timer" where officers gain access after the leader is offline for N days
              4. Challenge: The adjacency check for overclaim needs to handle edge cases — what if the vault is on the faction's border already (adjacent to wilderness)? It should be overclaimable normally in that case since there's nothing to push through
              5. Alternative: Instead of chunk-based vaults, could implement container-level locking (lock individual chests/storage) — more granular but much more complex to implement and track
              6. Alternative: Could use the existing zone flag system with a new "vault" flag on specific chunks rather than a separate vault concept — simpler but less intuitive for players
              7. Alternative: Could tie vault count to faction power level instead of a flat config cap — rewards stronger factions with more secure storage

              References and Media

              1. Similar concept in Factions plugins: "faction vaults" typically refer to shared storage GUIs, but this proposal is territory-based protection which is more aligned with real fortress/keep mechanics
              2. Existing protection infrastructure: ProtectionChecker.canInteract(), ClaimManager, FactionPermissions
              3. Existing territory map rendering: FactionMapPage, WorldMapOverlayProvider — vault chunks need a new color entry
              4. Existing faction permissions model: FactionPermissions with boolean toggles — officerVaultAccess follows the same pattern
              5. Overclaim logic: ClaimManager.overclaim() — adjacency check is a simple N/S/E/W neighbor lookup on ChunkKey

              Metadata

              Metadata

              Assignees

              No one assigned

                Labels

                enhancementNew feature or request

                Type

                No type

                Projects

                Milestone

                No milestone

                Relationships

                None yet

                Development

                No branches or pull requests

                Issue actions

                , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                Skip to content

                [Feat] Faction Vaults — restricted high-security territory chunks #35

                Description

                @derrickmehaffy

                Scope

                1. Add Faction Vaults — specially designated chunks within a faction's claimed territory that have restricted access controls
                2. Only the faction leader can access vault chunks by default (break, place, interact, open containers)
                3. Leaders can optionally grant officers vault access via a faction permission toggle
                4. Regular faction members, allies, and outsiders are fully blocked from interacting with vault chunks
                5. Vault chunks should be visually distinguishable on the GUI territory map (unique color/icon)
                6. Vault chunks have territorial overclaim protection — they can only be overclaimed if the attacker has a connected overclaim path from wilderness to the vault chunk's border (no skipping over defended territory)
                7. Vault chunks must already be claimed faction territory before being designated as a vault
                8. Configurable limit on how many vault chunks a faction can have (e.g., based on faction size or permission node)

                Implementation Details

                1. Data model: Add vault designation to the claim system

                  // In Faction or ClaimManager dataSet<ChunkKey> vaultChunks; // subset of claimed chunks marked as vault
                2. Commands:

                  • /f vault — toggle vault designation on the chunk you're standing in (must be own claimed territory)
                  • /f vault list — list all vault chunks with coordinates
                  • /f vault info — show vault status of current chunk
                  • /f admin vault <faction> add/remove <x> <z> — admin vault management
                  • /f admin vault <faction> list — admin view of faction's vaults
                  • /f admin vault <faction> clear — remove all vault designations
                3. Faction permission toggle (in faction settings):

                  • officerVaultAccess (default: false) — when enabled, officers can access vault chunks alongside the leader
                  • Configurable in the Faction Settings GUI under a "Vault" or "Security" section
                4. Protection integration: Modify ProtectionChecker to add vault-aware access checks

                  • When a chunk is a vault chunk, override normal faction territory permissions:
                    • Leader: always allowed
                    • Officers: allowed only if officerVaultAccess is enabled
                    • Members: denied (with vault-specific denial message)
                    • Allies/outsiders: denied (normal territory denial)
                  • Applies to: block break, block place, block interact, container access, fluid placement/pickup
                  • Admin bypass still works (hyperfactions.bypass.*)
                5. Overclaim protection: Vault chunks use territorial adjacency for overclaim eligibility

                  • A vault chunk can only be overclaimed if the attacking faction has already overclaimed (or the chunk is unclaimed) at least one directly adjacent chunk (N/S/E/W)
                  • This means attackers must push a connected overclaim path from wilderness through the faction's outer territory to reach the vault — they can't just cherry-pick the vault chunk from anywhere
                  • Non-vault chunks follow normal overclaim rules (unchanged)
                  • This makes vaults harder to reach but not impossible — a determined attacker who pushes through the territory can still breach the vault
                  • Vault status is removed when a chunk is overclaimed
                6. GUI integration:

                  • Territory map: vault chunks shown with a distinct color (e.g., gold/amber) or overlay pattern
                  • Faction Settings: "Vault" section with officer access toggle and vault count display
                  • Dashboard: vault count shown alongside claims count (e.g., "Claims: 12 (3 vaults)")
                  • Admin faction detail: vault chunk list with remove buttons
                7. Config in config.json:

                  {
                  "vaults": {
                  "enabled": true,
                  "maxVaultsPerFaction": 3,
                  "maxVaultsPermissionScaling": true,
                  "requireAdjacentOverclaim": true,
                  "defaultOfficerAccess": false
                  }
                  }
                8. Permission nodes:

                  • hyperfactions.vault.designate — designate/undesignate vault chunks
                  • hyperfactions.vault.list — view vault chunk list
                  • hyperfactions.vault.limit.<n> — override max vault count (e.g., vault.limit.5 for VIP)
                  • hyperfactions.admin.vault — admin vault management
                  • hyperfactions.bypass.vault — bypass vault access restrictions
                9. Denial messages:

                  • Members: "This is a faction vault. Only the leader can access this area."
                  • Members (with officer access on): "This is a faction vault. Only officers and the leader can access this area."
                  • Overclaim attempt without adjacency: "This vault chunk can only be overclaimed from adjacent territory. Push through the faction's borders first."

                Risks and Alternatives

                1. Risk: Adding a vault layer to the protection checker increases complexity in an already multi-layered system (zones → faction territory → vault) — needs careful ordering so vault checks don't conflict with zone overrides or admin bypass
                2. Challenge: Vault chunks that become unclaimed (faction loses power) need to have their vault status cleaned up properly
                3. Challenge: If a leader goes inactive, vault contents become inaccessible to the rest of the faction — consider adding a "vault lockout timer" where officers gain access after the leader is offline for N days
                4. Challenge: The adjacency check for overclaim needs to handle edge cases — what if the vault is on the faction's border already (adjacent to wilderness)? It should be overclaimable normally in that case since there's nothing to push through
                5. Alternative: Instead of chunk-based vaults, could implement container-level locking (lock individual chests/storage) — more granular but much more complex to implement and track
                6. Alternative: Could use the existing zone flag system with a new "vault" flag on specific chunks rather than a separate vault concept — simpler but less intuitive for players
                7. Alternative: Could tie vault count to faction power level instead of a flat config cap — rewards stronger factions with more secure storage

                References and Media

                1. Similar concept in Factions plugins: "faction vaults" typically refer to shared storage GUIs, but this proposal is territory-based protection which is more aligned with real fortress/keep mechanics
                2. Existing protection infrastructure: ProtectionChecker.canInteract(), ClaimManager, FactionPermissions
                3. Existing territory map rendering: FactionMapPage, WorldMapOverlayProvider — vault chunks need a new color entry
                4. Existing faction permissions model: FactionPermissions with boolean toggles — officerVaultAccess follows the same pattern
                5. Overclaim logic: ClaimManager.overclaim() — adjacency check is a simple N/S/E/W neighbor lookup on ChunkKey

                Metadata

                Metadata

                Assignees

                No one assigned

                  Labels

                  enhancementNew feature or request

                  Type

                  No type

                  Projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions