So erstellst du ein FiveM-MLO

Ein funktionierendes FiveM-MLO ist mehr als ein innenraumförmiges Modell. Du brauchst Geometrie, passende Kollision, einen MLO-Archetyp mit Raum- und Portaldaten, eine Weltplatzierung und eine Ressource, die die exportierten Assets ausliefert.

Diese Anleitung verwendet eine eigene Werkstatt mit zwei Räumen als kontrollierte Übung. Sie ist kein herunterladbares, vorgefertigtes Spielasset. Du erstellst die Geometrie selbst. Die folgenden Beispielnamen gehören zur Übung; sie sind weder besondere CodeWalker-Dateinamen noch garantierte Einstellungen für jeden Innenraum.

Was du erstellen wirst

Halte die erste Version bewusst klein: ein Vorderraum, eine dahinterliegende Werkstatt, eine Türöffnung dazwischen und ein Außeneingang. Bewegliche Türen, aufwendige Beleuchtung, Entity-Sets und komplexe Außenersetzungen folgen in einer späteren Revision.

Das Modell dieser Seite veranschaulicht die Beziehungen zwischen den Bereichen. Es ist ein Konzeptdiagramm, kein Nachweis eines Spieltests. Entscheidend für die Abnahme ist, ob der tatsächlich exportierte Innenraum auf deinem Zielserver korrekt funktioniert.

Absolviere vor dem Start den Blender–Sollumz-Export-und-Reimport-Test und erste YMAP-Übung. Du brauchst Grundlagen der Blender-Modellierung; CodeWalker ersetzt keine Modellierungsanwendung.

1. Lege Standort und Build-Ziel fest

Wähle einen Entwicklungsstandort, an dem du umliegende Originalgeometrie und vorhandene Kartenressourcen erkennen kannst. Dokumentiere die gewünschte Weltposition und Ausrichtung. Vermeide beim ersten Versuch einen komplizierten Gebäudeersatz: Bestehende Kollision kann den neuen Eingang blockieren, obwohl dein Modell eine Türöffnung besitzt.

Entscheide dich für Legacy- oder Enhanced-Assets. Verwende getrennte Exportordner, wenn du beide bearbeitest. Die Cfx.re-Einführungsanleitung für Enhanced verweist auf passende Konvertierungswerkzeuge und Verhaltensunterschiede. Nimm nicht an, dass der hier verlinkte dev46-Download die richtige Toolchain für beide Ziele ist.

Formuliere eine kleine Aufgabe: zwei Räume, ein Außeneingang, keine skriptgesteuerten Interaktionen. Zeichne den Grundriss vor den Details. So wird „fertig“ zu einem prüfbaren Zustand statt einem ständig wandernden Ziel.

2. Erstelle den Innenraum-Blockout in Blender

Erstelle Böden, Wände, eine Decke und freie Türöffnungen. Wähle einen konsistenten lokalen Ursprung und dokumentiere die geplante Welttransformation. Die Sollumz-Modellierungsanleitung zeigt, wie du beim Verschieben der bearbeitbaren Geometrie zum Ursprung eine Platzierungsreferenz behältst.

Verwende getrennte Sammlungen für sichtbare Geometrie, Kollision und Referenzmaterial. Ihre Namen dienen deiner Organisation und sind keine vorgeschriebenen Spieldaten. Gestalte die Struktur so, dass du ein Referenzgebäude nicht versehentlich exportierst.

Untersuche das Modell von innen. Prüfe Flächenausrichtung, Wandüberschneidungen und das Verhältnis zwischen Türöffnung und Boden. Ein Zierrahmen darf die nutzbare Öffnung nicht stärker einschränken als geplant. Halte Maßstab und Transformationen in der Datei konsistent; „korrigiere“ eine falsche Platzierung später nicht durch beliebiges Skalieren des gesamten Innenraums auf der Karte.

Speichere einen Zwischenstand beim Blockout. Ein schlichter, begehbarer Raum ist eine bessere Grundlage als eine möblierte Szene mit unklarem Ursprung.

3. Bereite Drawables und Materialien vor

Bereite die sichtbaren Meshes mit Sollumz als GTA-Drawables vor und weise passende Shader-Materialien für deinen Workflow zu. Beginne mit wenigen gewöhnlichen, undurchsichtigen Oberflächen. Komplexes Glas, emissive Elemente und Spezialeffekte erzeugen zusätzliche Fehlerquellen, die du für den Nachweis der Innenraumstruktur nicht brauchst.

Exportiere und prüfe eine repräsentative Oberfläche, bevor du alles texturierst. Kontrolliere, ob Texturreferenzen und Materialdarstellung in CodeWalker erhalten bleiben. Ein kleiner, konsistenter Materialsatz erleichtert außerdem spätere Korrekturen.

Führe eine einfache Asset-Liste. Ein Beispiel könnte enthalten: cw_workshop_shell für die sichtbare Hülle und cw_workshop_col für die Innenraumkollision. Eindeutige Namen helfen dir, die gerade geprüfte Exportdatei zu erkennen.

4. Erstelle die Kollision als eigene Aufgabe

Erstelle eine vereinfachte Kollisionshülle für die vom Spieler berührten Oberflächen. Sie soll tatsächliche Böden, Wände und Öffnungen erhalten, ohne jede Zierkante mechanisch nachzubauen.

Die Sollumz-Kollisionsanleitung behandelt die Konvertierung zu einem Kollisionsverbund und die Zuweisung von Kollisionsmaterialien. Sie erklärt auch raumspezifische Bodenmaterialien für die Zuweisung von Raum-IDs. Beachte die Konventionen deiner Version, statt eine angezeigte Raumnummer für den exakten internen Kollisionswert zu halten.

Prüfe den Außeneingang von beiden Seiten. Identifiziere bei einem bestehenden Gebäude jedes Kollisionsasset, das die Öffnung blockiert. Lösche keine unbeteiligte Weltkollision, nur um die Tür passierbar zu machen. Ein Standort ohne überlappende Ersetzungen macht diesen ersten eigenen Versuch deutlich klarer.

Die Kollisionslektion liefert einen getrennten Testplan für Begehbarkeit und Grenzen.

5. Erstelle das YTYP und den MLO-Archetyp

Archetyp-Definitionen verbinden Asset-Namen mit den vom Spiel benötigten Daten. Die Sollumz-YTYP-Anleitung beschreibt Basisarchetypen für Drawables und einen MLO-Archetyp aus der Kollisionsauswahl. Folge dieser dokumentierten Struktur, statt die sichtbare Hülle allein als vollständigen Innenraum zu behandeln.

Für die Werkstattübung brauchst du eine MLO-Definition, die die vorgesehenen Innenraumassets referenziert und die Innenraumorganisation enthält. Notiere den genauen Namen des MLO-Archetyps; diesen verwendest du später in einem YMAP.

Benenne den Archetyp während der Tests nicht um, ohne alle Referenzen anzupassen. Eine kosmetische Namensbereinigung kann sonst wie ein Rendering-Fehler aussehen.

6. Füge Räume, Limbo und Portale hinzu

Erstelle den Limbo-Raum mit dem vorgesehenen Werkzeug, danach Vorderraum und Werkstatt. Leite Raumgrenzen aus Geometrie ab, die den jeweiligen Bereich tatsächlich beschreibt. Verwende nicht einen riesigen Begrenzungsquader, nur weil eine genaue Auswahl länger dauert.

Erstelle an der inneren Türöffnung ein Portal aus vier Ecken und verbinde die richtigen Räume. Verbinde am Außeneingang den Innenraum gemäß der dokumentierten Richtungskonvention mit Limbo. Ein Portal ist Sichtbarkeitsinformation, weder das sichtbare Türmesh noch eine Öffnung in der Kollision.

Betrachte einen kleinen Graphen: Vorderraum ↔ Werkstatt und Vorderraum ↔ außen. Prüfe Endpunktzuordnung und Orientierung im Editor. Teste danach dieselben Übergänge im Spiel. Verlasse dich nicht auf den zufälligen Viewport-Winkel, aus dem alles richtig aussieht.

Ordne interne Entitäten der passenden Innenraumstruktur zu. Baue nicht den gesamten Innenraum als unverbundene Weltplatzierungen nach, nur weil er dadurch zunächst sichtbar wird. Die Lektion zu Räumen und Portalen erweitert den Zweiraumtest, statt universelle Flag-Werte vorzugeben.

7. Exportiere in einen leeren Ordner

Wähle die vorgesehenen Exportobjekte und prüfe, dass benötigte Objekte nicht versteckt sind. Exportiere über einen einheitlichen Weg. Der dokumentierte XML-Workflow konvertiert die Austauschdateien über CodeWalkers RPF Explorer.

Öffne die exportierten Spielassets vor dem Paketieren. Prüfe, ob die erwarteten Drawables und Kollision vorhanden sind und das YTYP die vorgesehenen Definitionen enthält. Mische nicht das heutige YTYP mit der Kollision der letzten Woche, nur weil die Dateinamen passen.

Bewahre Quellen, Austauschformate und auslieferbare Dateien in getrennten Ordnern auf. Wandle niemals .ydr.xml in .ydr um, indem du nur den Namen änderst. Exportiere oder konvertiere die Datei richtig.

8. Platziere den Innenraum in CodeWalker

Lade die exportierten Assets ins Projekt. Ergänze ein neues YMAP und eine Entität mit dem exakten Namen des MLO-Archetyps. Wende die dokumentierte Platzierungstransformation einmal an. Bei lokal erstellter Geometrie darf dieselbe Weltverschiebung nicht zusätzlich in jede Komponente eingerechnet werden.

Prüfe den Eingang im Verhältnis zur Umgebung und berechne YMAP-Flags und Ausdehnungen vor dem Speichern. Die Sollumz-Platzierungsanleitung dokumentiert diesen Schritt.

CodeWalkers Erzeugung von Spielkartenmanifesten und FiveMs fxmanifest.lua dienen unterschiedlichen Systemen. Eine erzeugte Datei _manifest.ymf ersetzt das folgende Ressourcenmanifest nicht.

9. Erstelle die FiveM-Ressource

Dieses Beispiel geht von einem eigenen YTYP aus namens cw_workshop.ytyp. Die Namen deiner Drawable- und Kollisionsexporte können abweichen; behalte die von deinem Projekt erzeugten Namen bei.

cw_workshop/
  fxmanifest.lua
  stream/
    cw_workshop.ymap
    cw_workshop.ytyp
    cw_workshop_shell.ydr
    cw_workshop_col.ybn
    # Add texture dictionaries and other required exports.

Nutze ein Ressourcenmanifest mit ausdrücklich registriertem YTYP:

fx_version 'cerulean'
game 'gta5'

this_is_a_map 'yes'

files {
    'stream/cw_workshop.ytyp'
}

data_file 'DLC_ITYP_REQUEST' 'stream/cw_workshop.ytyp'

Anweisungen und Datendateityp sind dokumentiert in Cfx.re und dessen Datendateireferenz. Ergänze die weiteren tatsächlichen Projektabhängigkeiten; dieses Beispiel ist kein universelles Manifest für jedes MLO.

10. Teste das Verhalten, nicht nur das Aussehen

Starte die Ressource auf einem Entwicklungsserver und besuche den notierten Standort. Gehe von der Straße durch den Vorderraum in die Werkstatt und zurück. Schaue vor dem Durchqueren durch jede Türöffnung. Drehe dich an der Schwelle um und teste beide Seiten jeder Raumgrenze.

Prüfe feste Böden, nutzbare Öffnungen und unerwünschte Barrieren. Wiederhole bei unterschiedlicher Beleuchtung, verbinde dich neu und nähere dich aus der Ferne. Teste abschließend mit den anderen Kartenressourcen, die dort gemeinsam laufen sollen.

Speichere Beobachtungen mit Koordinaten, Kamerarichtung und genauem Build. Ändere bei einem fehlgeschlagenen Test nur eine Sache gleichzeitig. Ein aus einem Blickwinkel verschwindender Raum erfordert eine andere Untersuchung als ein Spieler, der durch den Boden fällt.

Die nächsten Schritte sind Optimierung und eine wiederholbare Veröffentlichungscheckliste. Nenne das MLO nicht fertig, nur weil ein CodeWalker-Screenshot richtig aussieht.

Folge der Quellübergabe vom Browser an Blender

Es gibt zwei Einstiege: Modelliere die Übung wie oben selbst oder nutze das originale Quellpaket mit zwei Räumen zum Prüfen des eingeschränkten Companion-Workflows. Das Quellpaket ist kein fertiger nativer Innenraum und kein Beleg dafür, dass das Diagramm dieser Seite einen Spieltest bestanden hat.

In Map Studio, beschränke den Plan auf eine Ebene rechteckiger Räume und wähle Legacy. Exportiere das Quellpaket und öffne das CW-Studio-Panel in einer passenden Blender-/Sollumz-Umgebung. Die dokumentierte Basis ist Blender 4.2.23 LTS, Sollumz 2.9.0 und szio 1.3.0.dev9. Das sind festgelegte Integrationsversionen, keine Behauptungen über die „neuesten“ Versionen.

Verwende Importieren, wähle das Paket-ZIP und anschließend Validieren. Prüfe erzeugte Raumhüllen, physische Öffnungen, Raumzuordnungen und Portale vor dem Exportieren in einen neuen Ordner. Wurde generierte Geometrie manuell bearbeitet, bestätige das Ersetzen nicht ohne separat gespeicherte Szene. Das Add-on erkennt generierte Elemente; halte eigene Modelle außerhalb dieser Sammlung, sofern sie nicht neu aufgebaut werden sollen.

Das Bild zeigt die Übergabehilfe im Browser, keine Blender-Ausgabe und keinen GTA-Spielbetrieb. Das Add-on erzeugt einen maschinenlesbaren Bericht und Quell-XML. Prüfe beides; eine freundliche Oberflächenmeldung ersetzt die Kontrolle der tatsächlichen Ausgaben nicht.

Dokumentiere drei getrennte Abnahmeergebnisse

Ändere „nicht verifiziert“ nicht in „bestanden“, ohne die jeweilige Stufe auszuführen. Der Weltursprung des Quellpakets ist illustrativ: Wähle einen echten Testort und prüfe die Nachbargeometrie. Die Anleitung endet mit deinem dokumentierten Spielergebnis, nicht mit dem Herunterladen des Beispiels.