Bans & Mutes

Das Modul punishments liefert netzwerkweite Banns und Mutes mit festen Gründen aus reasons.yml, Eskalationsstufen, Admin-Banns, Rang-Schutz, Spieler-Steckbrief (/lookup), Historie und Entbannungsanträge im Dashboard.

Einschalten

• Modul-Schlüssel: punishments (keine Abhängigkeiten). Siehe Module & Presets.
• Im Netzwerk auf dem Proxy einschalten: Der Proxy registriert /ban, /unban, /mute, /unmute, /lookup, /playerinfo, /history, /modify und /resethistory und führt sie zentral aus. Die Spigot-Varianten sind nur der Fallback für Einzelserver.
• Die Bann-Prüfung beim Join läuft auf jedem Server, auch ohne das Modul.

reasons.yml

Alle Bann- und Mute-Gründe stehen in einer Liste. Maßgeblich ist die reasons.yml auf dem Proxy: Er legt sie beim Start und bei /eternal reload in der Datenbank ab. API/Dashboard (innerhalb von 30 s) und alle Spigot-Server (innerhalb einer Minute) übernehmen genau diese Liste. Die Datei auf den Spigots gilt nur, wenn kein Proxy da ist.

reasons:
  - id: 1
    type: ban
    label: "Hacking / Cheating"
    duration: permanent

  - id: 5
    type: ban
    label: "Schwere Beleidigung"
    duration: 7d
    escalation:
      - 7d          # 1. Mal
      - 30d         # 2. Mal
      - permanent   # 3. Mal und jedes weitere

  - id: 10
    type: ban
    label: "Strafbare Inhalte"
    duration: permanent
    permission: eternal.reason.extreme

  - id: 20
    type: mute
    label: "Chat-Spam"
    duration: 1h

  - id: 90
    type: ban
    label: "Server-Sabotage"
    duration: permanent
    admin: true

Außerdem enthält reasons.yml die Report-Gründe (report-reasons, siehe Reports) und die Verkürzungs-Vorlagen für Entbannungsanträge (appeal-shorten-templates, siehe unten).

Grund-Rechte im Dashboard (eternal.ban.reason.<id>)

Für jeden Grund registriert Eternal automatisch das Recht eternal.ban.reason.<id> (Kategorie „reasons“ im Rechte-Editor). Es steuert den Web-Report-Flow: Im Dialog „Bannen/Muten aus Report“ erscheinen nur Gründe, die der Teamler verwenden darf, und die API lehnt einen Grund ohne passendes Recht mit 403 ab.

Ein Grund ist im Dashboard nutzbar, wenn alle drei Punkte erfüllt sind:

1. Basis-Recht: eternal.mute (Mute-Grund) bzw. eternal.ban oder eternal.ban.admin (je nach admin:).
2. eternal.ban.reason.<id> – Standard-Stufe Team, also Opt-out: Jeder mit Basis-Recht darf jeden Grund, bis ein Admin den Grund für einen Rang auf Aus stellt.
3. Ein in reasons.yml gesetztes permission: muss zusätzlich gehalten werden.

Die Option Sonstiges im Dialog (freies Label + Dauer) sendet keinen Grund und braucht nur das Basis-Recht.

Befehle

Alle Befehle laufen im Netzwerk auf dem Proxy. Spielernamen werden auch für Offline-Spieler aufgelöst.

Benachrichtigungen über neue Banns und Mutes bekommen alle mit eternal.notify.

config.yml

# Verhalten von /resethistory
history:
  reset-mode: hard   # hard = Einträge physisch löschen
                     # soft = Einträge mit hidden=1 behalten (per SQL wiederherstellbar),
                     #        zählen nicht mehr für die Eskalation, nicht in /history

Wer darf wen bestrafen (Stufen)

Bannen und Muten ist rang-geschützt: Der Ausführende braucht eine echt höhere Stufe als das Ziel. Gleiche Ränge können sich also nicht gegenseitig bestrafen.

• Stufe = Maximum aus dem höchsten gehaltenen Recht eternal.tier.0 … eternal.tier.100 und der Priorität der höchsten Gruppe (Eternal Perms, früher CloudNet-sortId).
• Ist das Ziel offline, zählt die zuletzt gespeicherte Stufe aus seinem Profil.
• eternal.bypass hebt den Schutz komplett auf. Die Konsole darf immer.
• groupid eines Grundes nutzt dieselbe Stufe: Stufe ≥ groupid ersetzt das fehlende Grund-Recht.
• Im Dashboard sind /lookup-Ansicht und Historie zusätzlich rang-geschützt (eigene Stufe muss höher sein, eternal.bypass umgeht das). Ingame sind /lookup und /history nicht rang-geschützt.

Altbestand: Mit cloudnet.legacy-mapping: true werden die unter cloudnet.groups eingetragenen Gruppen per Name auf Rechte und tier abgebildet. Mit Eternal Perms ist das nicht nötig (Standard false).

Bann-Screen

Der Kick-Text beim Bann und beim Join-Versuch kommt aus translations/<sprache>.yml, Schlüssel ban-kick-screen:

ban-kick-screen: |-
  &dEternal &8»

  &7Du wurdest vom Netzwerk &cgebannt&7.

  &dGrund&8: &b{reason}
  &dDauer&8: &7{duration}
  &dBann-ID&8: &c#{id}{appealBlock}

  &8Beschwerde: &f/appeal

Die Zeile „Beschwerde: /appeal“ meint die Antrags-Seite im Dashboard (<Dashboard-URL>/appeal). Passe sie an deine Domain an. Weitere Texte: ban-broadcast, mute-blocked-chat, ban-perm-denied, unban-admin-only, tier-blocked-action.

Entbannungsanträge

Gebannte Spieler stellen Anträge auf zwei Wegen:

• Ohne Login: Seite /appeal im Dashboard – Spielername, Bann-ID und Begründung (mindestens 10 Zeichen). Name und ID müssen zum aktiven Bann passen.
• Mit Login: Mein Konto → Entbannungsantrag stellen. Gebannte Spieler kommen per Passwort-Login ins Dashboard (siehe Dashboard: Login & Konten). Dort sehen sie auch frühere Anträge und, falls vorhanden, das Replay zu ihrem Bann.

Pro Bann ist nur ein offener Antrag möglich.

Bearbeiten (Moderation → Entbannungsanträge)

Die Vorlagen kommen aus reasons.yml:

appeal-shorten-templates:
  - id: immediate
    label: "Sofort entbannen"
    duration: 0s
  - id: 1d
    label: "Auf 1 Tag verkuerzen"
    duration: 1d
  - id: 7d
    label: "Auf 1 Woche verkuerzen"
    duration: 7d

Die Dauer lässt sich im Dialog überschreiben (1d, 6h, 30m, permanent).

Dashboard-Seiten

Ein Web-Bann kickt den Spieler sofort.

Typische Stolperfallen

• „Für diesen Grund fehlt dir die nötige Permission“ – Grund hat ein eigenes permission: (z. B. Grund 10 braucht eternal.reason.extreme) oder ist ein Admin-Grund.
• „Du hast nicht den Rang, um … zu bestrafen“ – Ziel hat dieselbe oder eine höhere Stufe. Prioritäten der Ränge prüfen.
• Grund-Änderung kommt nicht an – reasons.yml auf dem Proxy bearbeiten und dort /eternal reload ausführen. Änderungen auf den Spigots werden im Netzwerk ignoriert.
• /modify setduration verlängert ungewollt – die neue Dauer zählt ab dem Zeitpunkt des Befehls, nicht ab Bann-Beginn.
• IDs wiederverwenden – eine geänderte Bedeutung einer bestehenden id verfälscht Eskalation und Historie. Neue Gründe besser mit neuer id anlegen.
• Ingame-Entbannung und Replays – Replays zu einem Bann werden beim Aufheben über das Dashboard gelöscht. Siehe Replays.
• Die Rechte eternal.reportsystem und eternal.lookup.bypass (in plugin.yml und im Beispiel unter cloudnet.groups) stammen aus älteren Versionen und werden im Code nicht mehr geprüft. Reports bearbeitet man mit eternal.report.handle, den Rang-Schutz umgeht eternal.bypass.