Feature Request: UUID- & Player-Daten aus File-System in MySQL migrieren

[StonDragon]

Alles klar 👍
Hier ist der bereinigte, kompakte und GitHub-Issues-optimierte Text.
Er ist nicht zu lang, klar strukturiert und direkt als Issue verwendbar.

---

🚀 Feature Request: Player UUID & Daten von File-System auf MySQL umstellen

Beschreibung

Aktuell speichert der PlayerListener Spielerinformationen (UUID, Name, IP-Adresse) dateibasiert (z. B. uuids.yml).
Für größere Netzwerke und einen stabilen Langzeitbetrieb ist diese Lösung nur eingeschränkt skalierbar.

Dieses Issue schlägt vor, die Speicherung und Verwaltung von Spieler-UUIDs vollständig auf MySQL umzustellen.

---

🎯 Ziel

• Ablösung der filebasierten UUID-Verwaltung

• Zentrale, performante Speicherung in einer MySQL-Datenbank

• Unterstützung für bestehende und neue Spieler

• Automatische Aktualisierung von Namen und IP-Adressen

---

🧩 Geplante Player-API

Einführung einer zentralen Storage-/Access-Klasse (z. B. PlayerAccess oder PlayerRepository).

// Prüfen, ob Spieler existiert
pa.playerExists(uuid);
// Aktuellen Namen abrufen

pa.currentName(uuid);
// Aktuelle IP abrufen

pa.currentIp(uuid);
// Namen aktualisieren

pa.setName(uuid, newName);
// IP aktualisieren

pa.setIp(uuid, newIp);

Alle Methoden sollen Insert & Update unterstützen.

---

🔄 Verhalten beim Player-Login

Beim PostLoginEvent:

1. Prüfen, ob der Spieler bereits existiert

2. Falls nicht vorhanden → neuen Datensatz anlegen

3. Falls vorhanden:

   • Namen aktualisieren (falls geändert)

   • IP aktualisieren (falls geändert)

   • letzten Login-Zeitpunkt aktualisieren

---

🗄️ Datenbank (Vorschlag)

Tabelle: players

Feld	Typ	Beschreibung
uuid	CHAR(36)	Primärschlüssel
current_name	VARCHAR(32)	Aktueller Spielername
current_ip	VARCHAR(45)	Letzte bekannte IP
first_join	TIMESTAMP	Erster Login
last_join	TIMESTAMP	Letzter Login

---

⚙️ Technische Anforderungen

• MySQL-Anbindung

• Async DB-Zugriffe (Velocity-konform)

• Prepared Statements

• Saubere Trennung:

  • Listener → Events

  • Storage → Datenzugriff

• Konfigurierbare DB-Zugangsdaten

---

📈 Nutzen

• Bessere Skalierbarkeit

• Keine wachsenden YAML-Dateien

• Zentrale Datenhaltung

• Grundlage für zukünftige Features (Security, Stats, Webpanel)

---

Status: Feature Request
Priorität: Hoch

---

Wenn du möchtest, kann ich dir als nächsten Schritt auch:

• ein SQL-Create-Script

• oder eine erste PlayerStorage-Implementierung
  vorbereiten.