Der letzte Export ist nicht automatisch die Veröffentlichung. Eine Veröffentlichung ist ein identifizierbares Paket mit bekanntem Ziel und dokumentierten Prüfungen. Halte die Entscheidung so überschaubar, dass andere sie ohne dein Gedächtnis nachvollziehen können.
Diese Checkliste ist ein redaktioneller Testplan für dein Projekt, keine Plattformzertifizierung und kein Nachweis, dass die Tutorial-Assets in GTA V getestet wurden.
Erstelle den Kandidaten aus sauberen Ausgaben
Exportiere in einen neuen Ordner oder leere bewusst nur dein eigenes Bereitstellungsverzeichnis. Kopiere die vorgesehenen Spielassets und vergleiche die Dateinamen mit deiner Liste. Alte Exporte dürfen nicht allein deshalb bleiben, weil der letzte sie nicht überschrieben hat.
Halte passende YMAP-, YTYP-, Drawable-, Kollisions- und Texturdateien zusammen. Notiere bei Versionsverwaltung die Revision, andernfalls mindestens einen datierten Quellstand und eine Toolchain-Notiz.
Packe niemals ein ganzes GTA-Archiv oder unbeteiligte Drittanbieter-Assets dazu, um eine fehlende Abhängigkeit zu verstecken. Identifiziere sie und kläre, ob das Paket sie enthalten darf.
Benenne das unterstützte Ziel genau
Dokumentiere GTA-Edition, vorgesehenen Spiel-Build, Toolchain und Testserverbedingungen. „FiveM-kompatibel“ ist weniger hilfreich als eine klar eingegrenzte Beschreibung der Prüfungen.
Führe für Legacy- und Enhanced-Ausgaben getrennte Build-Protokolle und Regressionsergebnisse. Nutze den Artikel zur Editionsplanung als Ausgangspunkt für diese Organisation.
Teste vier Verhaltensarten
Ankunft: Nähere dich aus mehreren realistischen Richtungen und Entfernungen. Teste eine frische Verbindung, nicht nur einen Ressourcen-Neustart direkt am Eingang.
Innenraumübergänge: Durchquere jede Raumverbindung in beide Richtungen. Halte an Schwellen und drehe die Kamera. Nutze dieselbe Route wie in der Portallektion.
Physische Interaktion: Teste Böden, Stufen, Eingänge und tatsächlich vorhandene Grenzen. Halte Kollisions- und Darstellungsergebnisse getrennt.
Zusammenspiel: Betreibe die Karte zusammen mit den vorgesehenen Nachbarressourcen. Identifiziere überlappende Ersetzungen und gemeinsame Abhängigkeiten vor der Verteilung.
Wähle zusätzliche Tests nach den ausgelieferten Funktionen. Bewegliche Türen brauchen Verhaltenstests; eine schlichte offene Werkstatt wird durch ein Häkchen für eine nicht vorhandene Funktion nicht verlässlicher.
Gestalte das Testprotokoll brauchbar
Speichere je Fehler Ort, Reproduktionsschritte, Soll- und Ist-Ergebnis sowie Kandidatenversion. Ein Screenshot ergänzt diese Angaben, ersetzt sie aber nicht.
Lass eine andere Person die Einrichtung ohne dein Arbeitsverzeichnis durchführen. Fehlt ein benötigter Dateiname, eine Registrierung oder Ressource, korrigiere Paket oder Anleitung statt Raten zu verlangen.
Bereite eine rückgängig machbare Bereitstellung vor
Bewahre die letzte funktionierende Ressource als zusammenpassendes Paket auf. Definiere Rollback-Auslöser, etwa einen reproduzierbar blockierten Eingang oder schweren Konflikt in der Zielkonfiguration.
Nutze geplante Wartung auf gemeinsam genutzten Servern. Prüfe unfertige Kollision nicht bei aktiven Spielern. Wiederhole nach der Bereitstellung einen kurzen Funktionstest mit dem Veröffentlichungsordner selbst.
Füge eine klare Übergabe hinzu
Liefere eine README mit Installation, Ressourcenname, Zielbedingungen, Abhängigkeiten, bekannten Grenzen und Version. Nenne Werkzeuge und Assets gemäß ihren Bedingungen. Verlinke Originalquelle und Download von CodeWalker statt eigene Urheberschaft am Werkzeug anzudeuten.
Gute Versionshinweise dürfen kurz sein: Was hat sich geändert, wo wird getestet und braucht eine bestehende Installation einen anderen Schritt? Der Wert liegt in der Wiederholbarkeit, nicht in langen Behauptungslisten.