Behandle den Ressourcenordner als Veröffentlichungspaket, nicht als Arbeitsverzeichnis. Er enthält die spielbereiten Dateien deiner Karte und ein klares Manifest. Blender-Backups, Editorprojekte und unkonvertierte Austauschdateien gehören anderswohin.
Beginne mit einem leeren Verzeichnis
Nutze für einen kleinen eigenen Innenraum eine Struktur wie diese:
cw_workshop/
fxmanifest.lua
stream/
cw_workshop.ymap
cw_workshop.ytyp
cw_workshop_shell.ydr
cw_workshop_col.ybn
Dies ist eine Beispielliste, keine vollständige Liste für jedes Projekt. Ergänze Texturen und andere tatsächlich benötigte Exportabhängigkeiten. Die Namen müssen zu deinen Assets und Referenzen passen, nicht nur diesem Beispiel ähneln.
Schreibe das Ressourcenmanifest
Für das einzelne YTYP dieses Beispiels:
fx_version 'cerulean'
game 'gta5'
this_is_a_map 'yes'
files {
'stream/cw_workshop.ytyp'
}
data_file 'DLC_ITYP_REQUEST' 'stream/cw_workshop.ytyp'
Cfx.re dokumentiert Ressourcenanweisungen in seiner Manifestreferenz und den YTYP-Registrierungstyp in seiner Datendateireferenz.
Liste bei mehreren eigenen YTYPs Dateien und Registrierungen konsistent auf oder verwende die dokumentierten Glob-Muster bewusst. Registriere keine Dateien, die du nicht auslieferst. Eine Karte mit vorhandenen Spielarchetypen kann ein kleineres Manifest verwenden, wie in der Anleitung zum ersten YMAP.
Die Manifest-Helfer erzeugt dieses kleine Beispiel im Browser. Es prüft weder deine Assets noch ein vollständiges MLO.
Verwechsle die Manifeste nicht
Ein von CodeWalker erzeugtes Spielkartenmanifest ist nicht fxmanifest.lua. Ebenso ist eine .cwproj keine Spielkarte und kann nicht anstelle ihrer Exporte gestreamt werden.
Nutze die von deiner Toolchain erzeugten nativen Spieldateien. Eine geänderte Dateiendung ist keine Konvertierung. Halte Austauschdateien außerhalb des Veröffentlichungsverzeichnisses, damit versehentliche Kopien auffallen.
Starte sie auf einem Entwicklungsserver
Lege die Ressource im Ressourcenverzeichnis des Servers ab. Kategorieordner wie [maps] organisieren Projekte; der Ressourcenname im Befehl muss weiterhin zum tatsächlichen Ressourcenordner passen.
In der Serverkonsole:
refresh
ensure cw_workshop
Hinterlege die passende ensure -Zeile für spätere Starts in der Serverkonfiguration. Prüfe die Serverausgabe, statt aus der Befehlseingabe einen erfolgreichen Ladevorgang abzuleiten. Die Dokumentation der Serverbefehle ist maßgeblich für das Befehlsverhalten.
Besuche die notierten Testkoordinaten. Eine Ressource kann starten, ohne Inhalte am erwarteten Ort zu platzieren. Prüfe Platzierung daher getrennt vom Start.
Teste das ausgelieferte Paket, nicht deinen Arbeitsbereich
Kopiere nur den Veröffentlichungskandidaten an einen sauberen Testort. Vergleiche seine Dateiliste mit den geplanten Exporten. Funktioniert die Karte nur mit einer anderen experimentellen Ressource, identifiziere die fehlende Abhängigkeit, statt sie implizit zu lassen.
Teste Neuverbindung, Annäherung von außerhalb und einen Serverstart mit von Anfang an konfigurierter Ressource. Wiederhole bei einem MLO auch Raum-, Portal- und Kollisionsrouten der entsprechenden Lektionen.
Halte Legacy- und Enhanced-Ausgaben getrennt. Der Artikel zu Spieleditionen erklärt, warum ein früherer erfolgreicher Legacy-Test keine Enhanced-Kompatibilität belegt.
Halte Aktualisierungen rückgängig machbar
Versioniere den Veröffentlichungsordner oder das Archiv und behalte das vorherige funktionierende Paket. Dokumentiere genaue Änderungen und Testroute. Nutze auf einem gemeinsam genutzten Server den Wartungsprozess des Betreibers, statt an verbundenen Spielern zu experimentieren.
Stelle nach einer fehlgeschlagenen Bereitstellung den gesamten bekannten funktionierenden Dateisatz wieder her. Ein altes YMAP mit neuerem YTYP oder neuer Kollision erschwert den Rollback. Eine reproduzierbare Veröffentlichung lässt sich als Einheit identifizieren, wiederherstellen und ersetzen.
Installiere ein YMAP nur mit Spiel-Props
Verwende einen neuen Ressourcenordner, etwa cw_three_props, mit fxmanifest.lua im Stammverzeichnis und dem nativen YMAP in stream/. Halte Projekt-JSON und Austausch-XML außerhalb des ausgelieferten stream-Verzeichnisses. Für das einfache Beispiel kann das Manifest so aussehen:
fx_version 'cerulean'
game 'gta5'
this_is_a_map 'yes'
Dies setzt voraus, dass alle Archetypen im Zielspiel und DLC-Kontext vorhanden sind. Ein eigenes Modell kann auch bei nur einer YMAP-Platzierung eigene Definitionen und Abhängigkeiten benötigen. Nutze den Generator nur dann mit deaktivierter benutzerdefinierter Option, wenn diese Voraussetzung zutrifft.
Registriere ein eigenes YTYP unter seinem tatsächlichen Dateinamen
Wenn du stream/cw_workshop_types.ytypbereitstellst, muss die Ressource genau diese Datei deklarieren. Der Ressourcenordnername zwingt das YTYP nicht zum gleichen Basisnamen:
files {
'stream/cw_workshop_types.ytyp'
}
data_file 'DLC_ITYP_REQUEST' 'stream/cw_workshop_types.ytyp'
Füge dies dem Kartenmanifest hinzu, nicht dem YMAP-XML. Die Cfx.re-Datendateireferenz beschreibt diesen Registrierungstyp. Mehrere eigene Definitionen benötigen passende Deklarationen; ressourcenübergreifende Assets außerdem einen dokumentierten Abhängigkeits- und Startplan. Der kleine Generator behandelt ein optionales YTYP, keinen vollständigen Abhängigkeitsgraphen.
Grenze Ressourcenstartfehler ein
Führe refresh nach dem Hinzufügen des Ressourcenordners aus, danach ensure cw_three_props mit dem tatsächlichen Ordnernamen. Prüfe zuerst die Serverkonsole. Bei unbekannter Ressource kontrollierst du Ordnerverschachtelung und Manifestnamen, bei einem Lua-Parsefehler die Manifestsyntax. Speichere Dateien ohne versteckte Endung .txt .
„ensure succeeded“ bestätigt den Start, nicht die Asset-Gültigkeit. Verbinde dich neu, besuche die genauen Koordinaten und prüfe alle Platzierungen. Bei unsichtbaren Inhalten oder türabhängigem Flackern nutze die symptombasierte Diagnose. Halte die Quellbeispiele außerhalb der Produktion, bis ihre getrennten nativen und spielinternen Prüfschritte erfolgt sind.