Floodgate-Konten verknüpfen: Daten und Rechte vorab prüfen
Bevor ihr die Kontoverknüpfung mit Floodgate auf einem bestehenden Minecraft-Server aktiviert oder verändert, haltet fest, welcher Identität die Spielerdaten gehören. Erprobt den Wechsel mit kontrollierten Testkonten und prüft Inventare, Berechtigungen und alle wichtigen Plugins. Ein erfolgreicher Login reicht für die Freigabe nicht aus.
Laut Geysers Dokumentation zur Verknüpfung verwenden verknüpfte Spieler den Fortschritt ihres Java-Kontos, einschließlich Inventar und Position. Der separate Bedrock-Fortschritt wird nach dem Aufheben der Verknüpfung wieder zugänglich. Plant deshalb keine automatische Zusammenführung zweier Spielverläufe ein.
Dieser Leitfaden richtet sich an Community-Verantwortliche und Teams, die Crossplay-Integrationen beauftragen. Er beschreibt einen vorgeschlagenen Abnahmeablauf. Die Prüfungen wurden nicht auf einer Mineando-Installation durchgeführt; eine Kompatibilitätszusage für eure Plugins ist damit nicht verbunden.
Legt das gewünschte Spielerlebnis fest
Beschreibt zuerst das Ziel, bevor ihr die Konfiguration ändert. Soll eine Person von beiden Editionen aus dasselbe bestehende Java-Profil nutzen? Möchtet ihr unabhängige Profile unterstützen? Wer hilft jemandem, der bereits auf beiden Konten wertvollen Fortschritt hat?
Ein konkreter Fall macht die Entscheidung greifbar: Eine Teilnehmerin besitzt unter ihrer Bedrock-Identität ein Haus und unter Java ein anderes Inventar. In der Änderungsplanung muss stehen, was sie nach der Verknüpfung sehen soll, welche Bestandsdaten geprüft werden müssen und wer eine Übertragung genehmigen darf. „Crossplay funktioniert“ beantwortet diese Fragen nicht.
Dokumentiert, ob ihr globale, lokale oder beide Verknüpfungsverfahren verwendet. Floodgate beschreibt, dass lokale Einträge Vorrang vor globalen haben. Berücksichtigt das, wenn sich eine Testumgebung anders verhält als der laufende Server. Dass auf beiden Floodgate installiert ist, belegt noch keine vergleichbare Konfiguration.
Erklärt den Teilnehmenden vor der Verknüpfung, was sich ändern wird. Fragt niemals nach Microsoft-Passwörtern oder Wiederherstellungscodes. Die Kontrolle über ein Konto sollte über den vorgesehenen Verknüpfungsablauf nachgewiesen werden, ohne persönliche Zugangsdaten an das Team weiterzugeben.
Erstellt ein Verzeichnis der Identitäten und Daten
Erfasst für jedes Testkonto Edition, sichtbaren Namen, die vom Server beobachtete UUID, den Verknüpfungszustand und den Verbindungsweg. Die UUID ist die Spielerkennung, die ihr zusätzlich zum angezeigten Namen vergleichen solltet. Nutzt Serveraufzeichnungen: Die Floodgate-FAQ nennt Logs als Möglichkeit, UUIDs von Bedrock-Spielern zu ermitteln.
Ergänzt eine Übersicht für die tatsächlich eingesetzten Komponenten:
| Daten oder Zugriff | Zu klärende Frage | Aufzubewahrender Nachweis |
|---|---|---|
| Inventar und Endertruhe | Welches Profil soll in welchem Zustand aktiv sein? | Kontrollierter Inhalt vorher und nachher |
| Berechtigungen und Teamzugriff | Welches Konto ist für welche Rolle autorisiert? | Geprüfte Identität und wirksame Rechte |
| Grundstücke, Homes und Wirtschaft | Woran erkennt das jeweilige Plugin den Eigentümer? | Pluginspezifische Abfrage und Sollzustand |
| Website oder Eventintegration | Welche Kennung speichert die Integration? | Testdatensatz und dokumentierte Zuordnung |
Das sind Prüffragen, keine Behauptung über ein einheitliches Speicherverfahren aller Plugins. Lasst euch vom Entwickler für jede Komponente den verwendeten Schlüssel und den unterstützten Migrationsweg nennen. Unbekannte Antworten bleiben offene Anforderungen.
Kopiert nicht vorschnell Spielerdateien, ändert keine Datenbankzeilen auf Verdacht und vergebt keine Ränge anhand ähnlich aussehender Namen. Klärt zuerst die Zuordnung zwischen bisheriger und vorgesehener Identität. Jede Datenübertragung braucht einen eigenen Ablauf und einen wiederherstellbaren Ausgangszustand.
Richtet eine Probe ohne Schreibzugriff auf den Livebetrieb ein
Verwendet eine isolierte Kopie mit den relevanten Softwareversionen und bewusst angelegten Testdaten. Sie darf weder produktive Plugin-Datenbanken verändern noch echte Belohnungen oder Integrationen auslösen. Der Leitfaden zur Probe einer Minecraft-Wiederherstellung erläutert die Prüfung in einer isolierten Umgebung.
Nutzt Konten, die euer Team kontrolliert. Bei globaler Verknüpfung ist die Änderung nicht auf den Testserver begrenzt. Plant sie daher nur für diese Konten und dokumentiert deren Ausgangszustand. Experimente mit lokalen Einträgen gehören möglichst in eine getrennte Testkonfiguration; Abweichungen vom Produktivsystem müssen ausdrücklich festgehalten werden.
Bereitet leicht erkennbare, wertarme Testdaten vor: unterschiedliche Inventarinhalte, ein Test-Home, eine gewöhnliche Berechtigung und ein Teamrecht, das die Teilnehmerin keinesfalls erhalten darf. Notiert vor jeder Anmeldung den Sollzustand. Damit fällt eine falsche Identitätszuordnung eher auf als bei einem leeren neuen Profil.
Prüft die Abläufe mit jedem unverzichtbaren Plugin
Die folgende Matrix ist ein Prüfplan und enthält keine Messergebnisse. Ergänzt konkrete Pluginnamen, Softwarestände, Zeitpunkte und Beobachtungen.
| Ablauf | Erforderliche Beobachtung |
|---|---|
| Java-Anmeldung vor der Änderung | Bestehende Java-Daten und Rechte entsprechen dem Ausgangszustand |
| Bedrock-Anmeldung ohne Verknüpfung | Der separate Ausgangszustand ist eindeutig erfasst |
| Bedrock-Anmeldung mit Verknüpfung | Das vorgesehene Java-Profil ist aktiv; Plugin-Ergebnisse passen zur vereinbarten Zuordnung |
| Erneute Anmeldung und Wechsel zwischen eingerichteten Backends | Identität und erwartete Daten je Server bleiben konsistent |
| Verknüpfung des Testpaars aufheben | Das erwartete separate Profil erscheint; Plugin-Zustände werden erneut geprüft |
| Wiederholung mit einem gewöhnlichen Teilnehmerkonto | Keine ungewollten Teamrechte oder zusätzlichen Belohnungen |
Vergibt ein Plugin beim ersten Beitritt eine Belohnung, ordnet es Eigentum zu oder synchronisiert es Website-Daten, prüft doppelte Aktionen und falsche Empfänger gezielt. Das ist eine vorgeschlagene Abnahmebedingung für eure Integration und keine Aussage, dass Floodgate solche Fehler verursacht.
Fragt bei Eigenentwicklungen nach, wie Floodgate-Spieler erkannt und verknüpfte Identitäten aufgelöst werden. Die Floodgate-API bietet Spielererkennung und Informationen zur Verknüpfung. Der Entwickler sollte dokumentieren, an welcher Stelle eurer Architektur diese Informationen verfügbar sind. Eine Vermutung anhand des Namenspräfixes sollte nicht die Grundlage der Identitätszuordnung sein.
Stoppt bei ungeklärten Abweichungen
Ein leeres Inventar ist ein Untersuchungsbefund und keine Erlaubnis, ein anderes Profil zu überschreiben. Unerwartetes Eigentum, zusätzliche Belohnungen oder erhöhte Rechte müssen die Freigabe stoppen. Bewahrt die Vorher-Nachher-Nachweise auf und ermittelt, welche Komponente die Entscheidung getroffen hat.
Ändert Präfixe nicht als spontane Reparatur: Die Floodgate-FAQ warnt vor Namenskonflikten beim Entfernen des Präfixes. Behandelt Namensänderungen als gesonderte Änderung mit eigener Prüfung.
Unterscheidet im Störungsplan drei Vorgänge: die Verknüpfung aufheben, eine genehmigte Datenübertragung rückgängig machen und ein Backup wiederherstellen. Setzt nicht voraus, dass der erste Vorgang die anderen beiden erledigt. Legt Verantwortlichkeiten fest und klärt, wie ihr neuen Fortschritt abgleicht, falls bereits wieder gespielt wurde.
Gebt den Betrieb frei, wenn Identitätsverzeichnis, Plugin-Matrix, Teilnehmeranleitung und Zuständigkeiten für die Wiederherstellung vollständig sind. Falls Plugins angepasst oder Websites mit diesen Identitäten verbunden werden sollen, nehmt diese Ergebnisse in den Auftrag für Minecraft-Entwicklung auf. Mineando übernimmt bezahlte Projekte mit individuell vereinbartem Umfang und Angebot; laufender Support wird separat vereinbart.
