3.6.5

Changelog

[3.6.5] – 2025-06-06

Added

• APIClient
  • get_blacklist_records() – erkennt beide Antwortformate
    (result.records ab v10 / records Legacy).
  • delete_blacklist_record() – akzeptiert JSON-Antwort
    {"result": true, "failed": false}, nacktes true und HTTP 404
    (Record bereits entfernt).

Changed

• Versions-Regex (get_major_version) akzeptiert jetzt Versionen mit oder ohne führendes v (11.5.1, v11.5.1 …).
• consume_unban_messages()
  • Entfernt den Query-Parameter exclude_expired aus Blacklist-Requests.
  • Holt alle Seiten (page_size = 100) und löscht jeden gefundenen Record.
  • Ruft do_unban() nur noch bei API < v10 auf; ab v10 erledigt
    unblacklist_player Ban + Blacklist in einem Schritt.
  • Verbessertes Logging: Seitenanzahl, Lösch-Erfolg, echte Warnungen.

Fixed

• Falsche Warn-Logs „⚠️ Löschen … fehlgeschlagen“, obwohl der Record schon entfernt war.
• Leere Record-Listen bei Blacklist-Abfragen (fehlendes result.records-Parsing).

Security

• Sicherstellt, dass 404-Antworten beim Löschen nicht mehr als Fehler gewertet werden
  → verhindert Log-Spam.

Migration

1. Pull / Deploy v3.6.5.
2. Prüfen, ob das Bearer-Token die Rechte
   api.can_view_blacklists und api.can_delete_blacklist_records besitzt.
3. Dienst / Container neu starten.

Nach dem Update sollte ein Unban alle Blacklist-Einträge
entfernen und keine Fehl-Warnungen mehr erzeugen.

---

3.6.4: Update README.md

Changelog

3.6.4 – 2025-06-06

Added

• APIClient
  • get_blacklist_records() – erkennt beide Antwortformate
    (result.records ab v10 / records Legacy).
  • delete_blacklist_record() – akzeptiert JSON-Antwort
    {"result": true, "failed": false}, nacktes true und HTTP 404
    (Record bereits entfernt).

Changed

• Versions-Regex (get_major_version) akzeptiert jetzt Versionen mit oder ohne führendes v (11.5.1, v11.5.1 …).
• consume_unban_messages()
  • Entfernt den Query-Parameter exclude_expired aus Blacklist-Requests.
  • Holt alle Seiten (page_size = 100) und löscht jeden gefundenen Record.
  • Ruft do_unban() nur noch bei API < v10 auf; ab v10 erledigt
    unblacklist_player Ban + Blacklist in einem Schritt.
  • Verbessertes Logging: Seitenanzahl, Lösch-Erfolg, echte Warnungen.

Fixed

• Falsche Warn-Logs „⚠️ Löschen … fehlgeschlagen“, obwohl der Record schon entfernt war.
• Leere Record-Listen bei Blacklist-Abfragen (fehlendes result.records-Parsing).

Security

• Sicherstellt, dass 404-Antworten beim Löschen nicht mehr als Fehler gewertet werden
  → verhindert Log-Spam.

Migration

1. Pull / Deploy v3.6.4.
2. Prüfen, ob das Bearer-Token die Rechte
   api.can_view_blacklists und api.can_delete_blacklist_records besitzt.
3. Dienst / Container neu starten.

Nach dem Update sollte ein Unban alle Blacklist-Einträge
entfernen und keine Fehl-Warnungen mehr erzeugen.

---

3.6.3

[3.6.3] - 2024-12-23

Hinzugefügt

• Option zur Deaktivierung des Auto-Updaters:
  • Es wurde die Möglichkeit eingeführt, den Auto-Updater über eine Umgebungsvariable in der .env-Datei zu deaktivieren.
  • Standardmäßig bleibt der Auto-Updater aktiviert.
  • Konfiguration:
    • Um den Auto-Updater zu deaktivieren, fügen Sie Ihrer .env-Datei die folgende Zeile hinzu:

      DISABLE_AUTO_UPDATER=true

    • Wenn die Variable DISABLE_AUTO_UPDATER nicht gesetzt oder auf false gesetzt ist, bleibt der Auto-Updater aktiviert.

Änderungen

• Versionsaktualisierung:
  • Die Skriptversion wurde auf 3.6.3 aktualisiert.

---

Beispiel .env-Datei

Auto-Updater aktiviert (Standard):

Es ist keine zusätzliche Konfiguration erforderlich. Optional können Sie die Variable explizit auf false setzen.

API_BASE_URLS=https://api.example.com,https://api.another.com
BEARER_TOKEN=IhrBearerToken
CLIENT_ID=IhrClientID
RABBITMQ_USER=IhrRabbitMQUser
RABBITMQ_PASS=IhrRabbitMQPasswort
RABBITMQ_HOST=localhost
RABBITMQ_PORT=5672
# DISABLE_AUTO_UPDATER=false  # Optional, Standard ist bereits false

Auto-Updater deaktiviert:

Fügen Sie die folgende Zeile hinzu:

DISABLE_AUTO_UPDATER=true

---

Zusammenfassung

In Version 3.6.3 haben Sie die Flexibilität eingeführt, den Auto-Updater bei Bedarf zu deaktivieren, ohne die Standardfunktionalität zu beeinträchtigen. Dies ermöglicht eine bessere Kontrolle über Aktualisierungsprozesse und erleichtert die Anpassung an spezifische Anforderungen.

Falls weitere Fragen oder Anmerkungen bestehen, stehen wir gerne zur Verfügung!

3.6.2

Changelog

[3.6.2] - 2024-12-21

Hinzugefügt

• Auto-Updater:
  • Implementierung eines automatischen Updaters, der regelmäßig (jede Stunde) nach neuen Releases auf GitHub sucht.
  • Der Updater lädt neue Versionen herunter, ersetzt die alten Dateien durch die neuen und aktualisiert die __version__-Variable im Hauptskript.
  • Nach erfolgreichem Update wird das Hauptskript (checkpoint.py) automatisch neu gestartet, um die neuen Änderungen sofort zu übernehmen.
  • Verbesserte Logging-Mechanismen zur besseren Nachverfolgung des Update-Prozesses.

Behoben

• Watchlist Bugfix:
  • Behebung eines Fehlers bei der Verarbeitung von Watchlist-Nachrichten, der dazu führte, dass bestimmte Datenfelder (player_name und player_id) nicht korrekt extrahiert und verarbeitet wurden.
  • Anpassung der Regex zur zuverlässigen Extraktion der __version__-Variable ohne nachfolgende Kommentare, um zukünftige Parsing-Probleme zu vermeiden.
  • Verbesserte Fehlerbehandlung und Logging in den Watchlist-Funktionen, um eine stabilere und zuverlässigere Verarbeitung sicherzustellen.

---

Upgrade-Anweisungen

1. Automatisches Update:

   • Das System aktualisiert sich automatisch auf die neueste Version, ohne dass Eingriffe erforderlich sind. Der Auto-Updater prüft jede Stunde auf neue Releases und führt bei Bedarf ein Update durch.

2. Manuelles Update:

   • Alternativ kannst du das Update manuell durchführen, indem du die neuesten Änderungen aus dem GitHub-Repository abrufst und das Skript checkpoint.py neu startest.

     git pull origin main
     python checkpoint.py

Wichtige Hinweise

• Backup empfohlen:

  • Es wird dringend empfohlen, vor dem Aktualisieren eine Sicherung deiner aktuellen Konfiguration und Daten zu erstellen, um einen versehentlichen Verlust zu verhindern.

• Berechtigungen:

  • Stelle sicher, dass das Skript die notwendigen Berechtigungen hat, um Dateien zu ersetzen und sich selbst während des Update-Prozesses neu zu starten.

• Überprüfung nach dem Update:

  • Nach dem Update solltest du überprüfen, ob alle Funktionen wie erwartet arbeiten. Überprüfe die Log-Dateien (app.log und updater.log) auf etwaige Fehler oder wichtige Informationen zum Update.

---

Zusammenfassung der Änderungen in Version 3.6.2:

• Auto-Updater hinzugefügt: Automatisiert den Update-Prozess, um sicherzustellen, dass das Skript stets auf dem neuesten Stand bleibt.
• Watchlist Bugfix: Fehlerbehebung bei der Verarbeitung von Watchlist-Nachrichten für eine zuverlässigere Funktionalität.

---

Solltest du weitere Fragen oder Anmerkungen haben, stehe ich dir gerne zur Verfügung!

3.5.0

Changelog

• API-Versionierung angepasst: Für API-Versionen ab v10 (einschließlich v11 und zukünftiger Versionen) wird nun dieselbe Logik wie für v10 angewendet. Dadurch entfällt die Notwendigkeit, den Code bei neuen Versionen manuell anzupassen, solange sich die API nicht grundlegend ändert.
• Nachrichtenverarbeitung vereinfacht: Sämtliche manuellen Aufrufe von message.ack() und message.nack() entfernt. Stattdessen wird nun überall async with message.process(): genutzt, um Acknowledge/Nack automatisch über den Kontextmanager handhaben zu lassen.
• Fehlerbehandlung über Exceptions: Anstelle von manuellem Zurückstellen oder Acknowledge bei Fehlern werden nun Exceptions ausgelöst. Der message.process() Kontextmanager sorgt dafür, dass Nachrichten bei unhandled Exceptions automatisch zurückgestellt werden.
• Code-Qualität: Vereinfachte Kontrollstrukturen und einheitlichere Behandlung von Nachrichten, was die Wartung und Erweiterung des Codes erleichtert.

3.3.1

Changelog

Verbesserte Handhabung von KeyboardInterrupt und sauberer Shutdown

Datum: 19.10.2024

Datei: checkpoint.py

Änderungen:

1. Abfangen von KeyboardInterrupt in der main()-Funktion:

   • Was wurde geändert?

     • Ein try...except-Block wurde um den Hauptteil der main()-Funktion hinzugefügt, um KeyboardInterrupt abzufangen.
     • Beim Erhalt eines KeyboardInterrupt werden alle laufenden asynchronen Tasks (consume_messages, consume_unban_messages, etc.) ordnungsgemäß abgebrochen.
     • Die Funktion asyncio.gather() wird mit dem Parameter return_exceptions=True aufgerufen, um sicherzustellen, dass alle Tasks korrekt beendet werden, auch wenn sie Ausnahmen auslösen.

   • Warum wurde dies geändert?

     • Um sicherzustellen, dass das Programm bei einem manuellen Abbruch durch den Benutzer (z.B. durch Drücken von Ctrl+C) die laufenden Prozesse sauber beendet und Ressourcen wie Verbindungen zu RabbitMQ ordnungsgemäß freigibt.
     • Verhindert unerwartete Ausnahmen und Fehlermeldungen während des Shutdowns.

2. Anpassung der Verbraucherfunktionen (consume_*), um asyncio.CancelledError abzufangen:

   • Was wurde geändert?

     • In jeder der consume_*-Funktionen (consume_messages, consume_unban_messages, consume_tempban_messages, consume_watchlist_messages, consume_unwatch_messages) wurde ein try...except-Block hinzugefügt.
     • Dieser fängt asyncio.CancelledError ab, das ausgelöst wird, wenn der Task abgebrochen wird.
     • Zusätzlich wird ein allgemeiner except-Block hinzugefügt, um andere unerwartete Ausnahmen zu protokollieren.

   • Warum wurde dies geändert?

     • Durch das Abfangen von asyncio.CancelledError kann jeder Task sauber beendet werden, ohne dass unhandhabte Ausnahmen auftreten.
     • Verbessert die Stabilität des Programms und ermöglicht einen kontrollierten Shutdown der einzelnen Aufgaben.

3. Hinzufügen von Logging-Meldungen:

   • Was wurde geändert?

     • Zusätzliche Logging-Meldungen wurden hinzugefügt, um den Status des Programms besser zu verfolgen.
     • Beim Start und Abbruch jeder Verbraucherfunktion wird nun eine entsprechende Meldung protokolliert (z.B. "Task consume_messages wurde abgebrochen.").
     • Beim Schließen der Verbindungen in der finally-Klausel der main()-Funktion wird eine Meldung ausgegeben ("Schließe Verbindungen...").

   • Warum wurde dies geändert?

     • Erhöht die Transparenz des Programmablaufs und erleichtert das Debugging.
     • Gibt dem Benutzer Feedback darüber, was beim Beenden des Programms passiert.

4. Anpassung des Hauptprogramms (if __name__ == '__main__'):

   • Was wurde geändert?

     • Ein zusätzlicher try...except-Block wurde um den Aufruf von asyncio.run(main()) hinzugefügt.
     • Dieser fängt KeyboardInterrupt ab, falls es außerhalb der main()-Funktion auftritt.
     • Beim Abfangen wird eine Logging-Meldung ausgegeben ("Programm wurde durch KeyboardInterrupt beendet.").

   • Warum wurde dies geändert?

     • Um sicherzustellen, dass das gesamte Programm sauber beendet wird, selbst wenn ein KeyboardInterrupt außerhalb der main()-Funktion auftritt.
     • Verhindert unhandhabte Ausnahmen und ermöglicht einen kontrollierten Shutdown.

Zusammenfassung der Vorteile:

• Sauberer Shutdown des Programms: Durch das ordnungsgemäße Abfangen von Unterbrechungssignalen und das kontrollierte Beenden von Tasks und Verbindungen wird sichergestellt, dass keine Ressourcen offengelassen oder beschädigt werden.
• Verbesserte Fehlerbehandlung: Unerwartete Ausnahmen werden abgefangen und protokolliert, was die Stabilität des Programms erhöht und das Debugging erleichtert.
• Erhöhte Transparenz: Durch detaillierte Logging-Meldungen kann der Programmablauf besser nachvollzogen werden.

Fix: SyntaxError in `api_manager.py`

Changelog

Fix: SyntaxError in api_manager.py

• Problem behoben: Ein SyntaxError trat auf, weil das Schlüsselwort async with außerhalb einer asynchronen Funktion verwendet wurde.
• Datei betroffen: api_manager.py
• Änderungen:
  • Die Methode report_api_version wurde von einer asynchronen Funktion zu einer synchronen Funktion umgewandelt.
    • Vorher: Verwendung von async def und aiohttp für asynchrone HTTP-Anfragen.
    • Nachher: Verwendung von def und requests für synchrone HTTP-Anfragen.
  • Entfernt den Import von aiohttp, da es nicht mehr benötigt wird.
  • Hinzugefügt oder sichergestellt, dass import requests und import logging am Anfang der Datei vorhanden sind.
  • Fehlerbehandlung und Logging wurden verbessert, um mögliche Ausnahmen zu erfassen und zu protokollieren.

Details der Änderung in api_manager.py:

• Alte Version der Methode report_api_version:

  async def report_api_version(self, client_id):
      url = "https://api.hackletloose.eu/update_client_version"
      timestamp = datetime.datetime.utcnow().isoformat()
      data = {
          'client_id': client_id,
          'api_version': self.api_version,
          'timestamp': timestamp
      }
      async with aiohttp.ClientSession() as session:
          async with session.post(url, json=data) as response:
              if response.status == 200:
                  logging.info(f"API-Version {self.api_version} erfolgreich gemeldet für Client {client_id} mit Timestamp {timestamp}")
              else:
                  logging.error(f"Fehler beim Melden der API-Version {self.api_version} für Client {client_id} mit Timestamp {timestamp}")

• Neue Version der Methode report_api_version:

  def report_api_version(self, client_id):
      url = "https://api.hackletloose.eu/update_client_version"
      timestamp = datetime.datetime.utcnow().isoformat()
      data = {
          'client_id': client_id,
          'api_version': self.api_version,
          'timestamp': timestamp
      }
      try:
          response = requests.post(url, json=data)
          if response.status_code == 200:
              logging.info(f"API-Version {self.api_version} erfolgreich gemeldet für Client {client_id} mit Timestamp {timestamp}")
          else:
              logging.error(f"Fehler beim Melden der API-Version {self.api_version} für Client {client_id} mit Timestamp {timestamp}")
      except Exception as e:
          logging.error(f"Fehler beim Melden der API-Version: {e}")

Konsistenz und Verbesserungen

• Konsistente Nutzung von HTTP-Bibliotheken: Alle HTTP-Anfragen innerhalb der APIClient-Klasse verwenden nun das requests-Modul, was die Wartbarkeit und Lesbarkeit des Codes verbessert.
• Fehlerbehandlung: Verbesserte Fehlerbehandlung in der Methode report_api_version, um Ausnahmen zu protokollieren und unerwartete Abstürze zu vermeiden.
• Entfernte unnötige Importe: import aiohttp wurde entfernt, da es nicht mehr benötigt wird.
• Logging: Zusätzliche Logging-Statements wurden hinzugefügt, um den Status von HTTP-Anfragen und möglichen Fehlern besser nachverfolgen zu können.

3.2.0 v10 Fixes

Changelog von Version 3.1.0 zu 3.2.0

Version 3.2.0 (Aktuelle Version)

Neue Features:

1. Dynamische Zuordnung von player_id und player_name in consume_tempban_messages:

   • Basierend auf der API-Version wird nun dynamisch entweder player_name oder player sowie player_id oder steam_id_64 zugeordnet.
   • Erhöht die Flexibilität und Kompatibilität mit unterschiedlichen API-Versionen.

2. Verarbeitung von Watchlist-Nachrichten basierend auf API-Versionen:

   • Die consume_watchlist_messages-Funktion berücksichtigt jetzt unterschiedliche API-Versionen (v10 und v9.x), um die korrekten Datenfelder (player_name und player_id vs. player und steam_id_64) zu verarbeiten.

Verbesserungen:

1. Fehlerbehandlung in connect_to_tempban_rabbitmq:

   • Besseres Error-Handling durch Einfügen eines Try-Catch-Blocks in der Funktion connect_to_tempban_rabbitmq, um Fehler beim Verbindungsaufbau zu RabbitMQ abzufangen und optional weiterzuleiten.

2. Robustheit des Message-Handling in consume_watchlist_messages:

   • Neue Logik, um zu vermeiden, dass Nachrichten mehrfach verarbeitet werden, falls ein Fehler auftritt, und zusätzliche Absicherung durch Verwendung eines Flags (processed), das den Verarbeitungsstatus der Nachricht verfolgt.

3. Fehlerhafte Nachrichtenzurückstellung:

   • Verbesserte Fehlerbehandlung in den consume_*_messages-Funktionen. Nachrichten, die nicht korrekt verarbeitet werden können, werden nun zuverlässiger wieder in die Queue gestellt oder nicht erneut eingereiht, je nach Kontext.

Fehlerbehebungen:

1. Stabilitätsprobleme beim Zurückstellen von Nachrichten:

   • Verbesserte Fehlerbehandlung bei der Wiederverarbeitung von Nachrichten in consume_watchlist_messages, um Situationen zu vermeiden, in denen Nachrichten irrtümlich als verarbeitet markiert werden.

2. Behebung von Problemen mit nicht wiederholten Nachrichten:

   • Sicherstellung, dass Nachrichten, die nicht erfolgreich verarbeitet wurden, korrekt zur Wiederholung in die Queue gestellt werden, oder aber explizit verworfen werden.

Entfernte Features:

• Keine Features wurden entfernt.

Sonstiges:

• Allgemeine Code-Bereinigung und Verbesserung der Lesbarkeit durch zusätzliche Kommentare und strukturelle Anpassungen.

3.1.0 Fix v10

Changelog: ban_client.py und api_manager.py

---

Änderungen in ban_client.py

1. Fehlerbehandlung und Logging verbessert:

   • Überprüfungen hinzugefügt:
     • Vor dem Verarbeiten von Ban-, Unban-, Tempban-, Watchlist- und Unwatch-Nachrichten werden jetzt player_name und player_id auf ihre Existenz überprüft.
   • Logging-Verbesserungen:
     • Verbesserte Log-Meldungen und detailliertere Informationen bei Fehlern.

2. Nachrichtenverarbeitung:

   • Fehlende Daten validieren:
     • Wenn player_name oder player_id in den Nachrichten fehlt, wird die Nachricht abgelehnt und nicht erneut in die Warteschlange gestellt (nack(requeue=False)).
   • Alle Versionen verwenden steam_id:
     • Unabhängig von der API-Version wird jetzt immer die steam_id (player_id) für alle Ban- und Unban-Operationen verwendet.

3. Kleinere Korrekturen und Verbesserungen:

   • Verwendeter client_id:
     • Der client_id wird konsequent bei allen RabbitMQ-Verbindungen und API-Aufrufen genutzt.
   • Timeout und Rückstellungslogik für RabbitMQ-Nachrichten:
     • Nachrichten werden nur dann erneut in die Warteschlange gestellt (requeue=True), wenn die JSON-Daten ungültig sind oder ein unerwarteter Fehler auftritt.

---

Änderungen in api_manager.py

1. API-Aufrufe optimiert:

   • Logging bei API-Anfragen:
     • Detaillierte Log-Meldungen für jeden API-Aufruf, einschließlich der gesendeten Nutzlast und der empfangenen Antwort.
   • API-Versionen unterstützt:
     • Die API-Aufrufe sind jetzt so gestaltet, dass sie sowohl mit Version 9.9.5 als auch mit Version 10 der API kompatibel sind.
     • Beispielsweise wurden URLs und Payloads je nach API-Version angepasst.

2. Verbesserte Fehlerbehandlung:

   • Erweiterte Logging bei Fehlern:
     • Fehler bei API-Aufrufen werden jetzt umfassender geloggt, um die Fehlersuche zu erleichtern.
   • Korrektur von API-Aufrufen:
     • Einige API-Endpunkte wie do_blacklist_player und do_watch_player verwenden jetzt das korrekte Format für die Payload, abhängig von der API-Version.

3. Verbesserte API-Kompatibilität:

   • Handling von Versionen:
     • Der player_id wird jetzt immer als steam_id verwendet, unabhängig von der API-Version, was die Konsistenz und Kompatibilität verbessert.
   • Neue Felder hinzugefügt:
     • Einige API-Aufrufe wurden aktualisiert, um zusätzliche Felder zu unterstützen, z.B. player_name bei der watch_player-Funktion für API v10.

4. Fehlertoleranz erhöht:

   • Fehler in API-Antworten:
     • Bei fehlgeschlagenen API-Aufrufen wird jetzt detaillierter darüber informiert, warum der Aufruf fehlschlug (z.B. durch Logging der vollständigen Antwort).

---

Dieses Changelog fasst die wesentlichen Änderungen zusammen, die in den Dateien ban_client.py und api_manager.py vorgenommen wurden. Die Updates umfassen Verbesserungen bei der Fehlerbehandlung, umfassendere Logging-Funktionen und eine bessere Kompatibilität zwischen verschiedenen API-Versionen.

3.0.0

Update 3.0.0 für Hack let Loose

Wir freuen uns, das Update 3.0.0 für Hack let Loose vorzustellen. Dieses Update bringt bedeutende Verbesserungen und neue Funktionen, die die Verwaltung von Banns und Entbannungen effizienter und transparenter machen. Mit einer klareren Struktur für jede Community und einer überarbeiteten Abstimmungslogik stellen wir sicher, dass alle Entscheidungen fair getroffen werden und die Zusammenarbeit innerhalb der Community gestärkt wird.

Changelog für das Client-Skript

1. Klarere Struktur für jede Community

Vor diesem Update wurden alle Banns und Entbannungen über ein zentrales System verwaltet, was manchmal zu Verwirrung führte. Mit dem neuen Update hat nun jede Community ihre eigene, separate Warteschlange zur Verwaltung von Banns und Entbannungen. Das bedeutet:

• Klarheit und Ordnung: Jede Community kann ihre Entscheidungen unabhängig treffen und verwalten.
• Schnellere Verarbeitung: Durch die getrennten Warteschlangen wird alles effizienter und gezielter bearbeitet.

2. Neue Abstimmungslogik

Die Abstimmungslogik wurde überarbeitet, um sicherzustellen, dass alle Stimmen fair gezählt werden und Enthaltungen nicht die Entscheidung blockieren.

• Start der Abstimmung:

  • Eine Nachricht wird im Abstimmungskanal gepostet.
  • Alle berechtigten Communities haben die Möglichkeit, abzustimmen.

• Stimmabgabe:

  • Communities stimmen durch Reaktionen ab:
    • 👍 (Daumen hoch) für Zustimmung
    • 👎 (Daumen runter) für Ablehnung
  • Die Abstimmung bleibt für einen festgelegten Zeitraum (24 Stunden) offen.
  • In dieser Zeit erhält der Spieler einen temporären Bann (24 Stunden).

• Beispiel für Stimmverteilung:

  • 5 Communities stimmen mit 👍
  • 3 Communities stimmen mit 👎
  • 6 Communities enthalten sich

• Auswertung der Stimmen:

  • Stimmen werden gezählt, und Enthaltungen werden zur Mehrheit gezählt:
    • Wenn mehr 👍-Stimmen als 👎-Stimmen vorliegen, werden Enthaltungen als 👍-Stimmen gezählt.
    • Wenn mehr 👎-Stimmen als 👍-Stimmen vorliegen, werden Enthaltungen als 👎-Stimmen gezählt.

• Ergebnis:

  • In unserem Beispiel haben 11 von 14 Communities (5 👍 + 6 Enthaltungen) für Zustimmung gestimmt.
  • Die Mehrheit entscheidet, ob der Bann oder die Entbannung durchgeführt wird.

• Berücksichtigung der 👎-Stimmen:

  • Communities, die mit 👎 stimmen, sind von der Durchsetzung des Banns oder der Entbannung ausgeschlossen.
  • Beispiel: 3 Communities stimmen mit 👎, also wird der Bann für diese 3 Communities nicht durchgesetzt, selbst wenn die Mehrheit dafür ist.

Diese Änderungen gewährleisten, dass Entscheidungen fair getroffen werden und die Stimme jeder Community zählt. Wir glauben, dass diese Verbesserungen die Zusammenarbeit und Transparenz in unserer Community weiter stärken werden.

Änderungen an der API-Unterstützung

• Unterstützung für v10 der API:

  • Neue Endpunkte und Felder: Unterstützung für player_id und player_name in der API v10.
  • Überarbeitete Methoden:
    • do_perma_ban: Unterscheidung zwischen steam_id_64 und player_id basierend auf der API-Version.
    • do_temp_ban: Anpassung der Payload je nach API-Version.
    • do_unban: Unterscheidung der Parameter basierend auf der API-Version.
    • do_blacklist_player: Anpassung der Endpunkte und Parameter für v10.
    • do_watch_player: Hinzufügen des player_name Feldes in der API v10.
    • do_unwatch_player: Anpassung der Payload für v10.
    • post_player_comment: Verwendung des korrekten Feldes (player_id vs. steam_id_64) basierend auf der API-Version.

• Fehlerbehebung und Verbesserungen:

  • Fehler beim Posten von Kommentaren wurden behoben.
  • Verbesserte Handhabung von Fehlermeldungen und Logging für bessere Nachvollziehbarkeit.
  • Sicherstellung der Kompatibilität mit beiden API-Versionen (v9.9.4 und v10).

Diese Änderungen sorgen dafür, dass das System sowohl mit der aktuellen als auch mit der neuen API-Version reibungslos funktioniert und gleichzeitig die neuen Funktionalitäten und Verbesserungen der API v10 nutzt.

Updateanweisungen

Um das Skript nach dem Update korrekt zu konfigurieren, müssen die folgenden Schritte befolgt werden:

1. .env Datei anpassen: Stellen Sie sicher, dass die .env Datei die korrekten Anmeldedaten und Konfigurationswerte enthält. Hier ein Beispiel für eine .env Datei:

BEARER_TOKEN=DEINTOKEN
API_BASE_URLS=https://xyz.domain.com
API_USER=DeinRCONuser
API_PASS=Passwort
CLIENT_ID=DeineClientID
RABBITMQ_USER=DeinRabbitMQ-Benutzer
RABBITMQ_PASS=DeinRabbitMQ-Passwort
RABBITMQ_HOST=rabbit.1bv.eu
RABBITMQ_PORT=5672

Wichtig: Die CLIENT_ID=DeineClientID muss korrekt eingetragen werden, da sie entscheidend für die Funktion des Skripts ist.

2. Anmeldedaten speichern:
   • Rolle: XYZ - Admins
   • Benutzername: user_DeineClientID
   • Passwort: DeinPasswort

Diese Anmeldedaten sind wichtig für die Anmeldung beim Skript und sollten sicher gespeichert werden.

3. Skript ausführen:

   • Stellen Sie sicher, dass alle Abhängigkeiten installiert sind.
   • Führen Sie das Skript mit den angepassten Konfigurationswerten in der .env Datei aus.

4. Client-Skript neustarten: Beim Update des CRCON muss auch das Client-Skript neugestartet werden.

Änderungen an bestehenden Funktionen

Für bestehende Clans und Communities, die das neue System nutzen möchten:

1. Anmeldedaten anzeigen: Klicken Sie auf die Schaltfläche "Anmeldedaten anzeigen" im Kanal register-server, um Ihre neuen Anmeldedaten zu erhalten.
2. .env Datei aktualisieren: Aktualisieren Sie Ihre .env Datei mit den neuen Anmeldedaten.
3. Client-Skript: Führen Sie das Skript mit den neuen Konfigurationswerten aus.