Oliver199
Member
Ich dachte mir, dass sich hier eventuell jemand dafür interessiert ein wenig in CXL herumzumodden (wenn nicht, ist es mir auch egal 
)
Dazu wurde durch den User haltendehand ein kurzer Leitfaden geschrieben, der ein Grundlagenwissen zum Modden in Cities XL gibt. Die Berechtigung zur Verbreitung dieses Textes liegt mir vor.
Die im Leitfaden beschriebenen Packing und Unpacking Tools sind hier downzuloaden:
Beschreibung und Download von Okeanos' Packager
Beschreibung und Download von Okeanos' Unpacker
Der folgende Text wurde durch den User haltendehand verfasst.
Ein Leitfaden zum Dateisystem und zum Modding von CXL.
1. Kapitel: Vor dem Modden...
1.1 Konventionen
Buchstaben oder Zeichen, die sich zwischen [ und ] befinden stellen Tasten dar, die gedrückt werden sollen.
1.2 Voraussetzungen
1(eine) legale Kopie des Spiels "Cities XL" von Monte Cristo Games
1.3 Vorbereitungen
Da Monte Cristo Games leider die gesamten Spielinhalte in Archive gepackt hat, müssen wir, um auf diese Daten zuzugreifen, die Spielinhalte erst entpacken. Dies ist durch ein externes Programm am einfachsten zu erreichen. Inzwischen gibt es 4 solcher Programme, wobei in diesem Leitfaden davon ausgegangen wird, dass ihr Okeanos„ Unpacker und Packager benutzt. Es ist zwar ohne Probleme möglich, diesen Leitfaden mit einem Anderen Programm zu verfolgen, jedoch müsst ihr in diesem Fall einige Anweisungen anpassen.
1.4 Die Bedienung der beiden Programme
1.4.1 Der Unpacker
Um alle Spieldaten von einer Installation zu entpacken, wählt bitte den Menü punkt "Unpack Installation". Daraufhin sollten die TextBox namens “Game Folder” und der daneben liegende Button "Browse" nicht mehr ausgegraut erscheinen. Stellt bitte vor dem Entpacken sicher, dass der angezeigte Ordner auch tatsächlich mit dem Ordner in dem eure CXL-Installation liegt übereinstimmt.
Wenn dies nicht der Fall ist, dann klickt bitte auf "Browse" und geht in eurem Dateisystem bis zum Ordner, der eure CXL-Installation enthält.
Um dem Programm zu sagen, wo die Spieledaten entpackt werden sollten, klickt bitte auf den Button "Browse" neben der TextBox "Target Folder", und navigiert zum Ordner in dem die Spieldaten entpackt werden sollen.
Um die ausgewählte Installation nun auch tatsächlich zu entpacken, muss man auf "Run" klicken. Der Status der Operation wird, zusammen mit dem Namen der Datei die aktuell verarbeitet wird, unten im Programm angezeigt.
Wenn ihr hingegen einzelne .patch, .pak oder gar .sgbin Archive entpacken wollt, solltet ihr auf "Unpack Single Package" klicken. Nun sollte die TextBox namens "Package Filename" und der 1 danebenliegende Button "Browse" nicht mehr ausgegraut sein. Um die Datei auszuwählen, die entpackt werden soll, klickt bitte auf "Browse", navigiert zum Ordner, der diese Datei beinhaltet, wählt diese Datei aus und klickt auf "Öffnen".
Um dem Programm zu sagen, wohin die Datei entpackt werden soll, klickt bitte auf den Button "Browse" neben der TextBox "Target Folder", und navigiert zum Ordner, in dem die Datei entpackt werden soll.
1.4.2 Der Packager
Um die Dateien, nachdem sie modifiziert wurden, wieder in das Spiel einzufügen, wird ein weiteres Programm gebraucht, was auch von Okeanos kommt: der Packager.
Um eine modifizierte Datei ins Spiel einzufügen, muss sie erst mal ins Programm geladen werden. Dies macht ihr indem ihr auf den Button "+ New Entry" klickt. Im nun aufgegangenen Fenster mit Namen "Package Entry" solltet ihr auf den Button "Browse" klicken, bis zum Ordner navigieren, der die geänderte Datei enthält, diese auswählen und auf "Öffnen" klicken.
In der TextBox "Full Name" sollte nun der Dateiname stehen. Diesen Namen könnt ihr, wenn ihr möchtet, ändern, dies macht jedoch keinen wirklichen Unterschied. Unter "Format" könnt ihr zwischen "Compressed"(empfohlen) und "Uncompressed" wählen. Unkomprimierte Dateien sind größer, bieten jedoch trotzt dem keinen spürbaren Geschwindigkeitsvorteil.
Klickt nun auf "Ok".
Nun sollte die Datei in der "Haupttabelle" im Programm hinzugefügt worden sein.
Wenn ihr weitere Dateien hinzufügen wollt, macht bitte dasselbe, was ihr gemacht habt, um die erste Datei in das Programm zu laden. Es ist leider nicht möglich, mehrere Dateien auf einmal in das Programm zu laden.
Wenn ihr alle Dateien ins Programm geladen habt, die ihr ersetzen wollt, dann müsst ihr das ganze natürlich noch als .patch abspeichern. Dies macht ihr, indem ihr entweder auf die Diskette, oder auf "File" und dann auf "Save" klickt.
Hier müsst ihr dann bis in den Unterordner "Paks" navigieren, der sich im Installationsordner von Cities XL befindet, und dort die Datei abspeichern, indem ihr erst in die TextBox "Dateiname" euren gewünschten Dateinamen mit der Endung ".patch"("Dateiname. patch") eingibt, und dann auf "Speichern" klickt.
Achtung: Die Dateiendung .pak sollte nicht benutzt werden, da sie erfahrungsgemäß Probleme bereiten kann.
Achtung: Die Namenskonvention für Modnamen ist: Autor_Mod.patch, und nicht Autor_Mod_Version.patch, da ansonsten durch die verschiedenen Modversionen Konflikte auftreten könnten
Tipp: Der Ordner "paks" kann unendlich viele Unterordner haben, die wiederum unendlich viele Unterordner haben können. Ich empfehle folgendes Ordnersystem: "Paks/Autor/Modname"
2. Kapitel: Das Dateisystem
Wenn es etwas gibt, was man Monte Cristo nicht vorwerfen kann, dann ist es das, ein undurchsichtiges Dateisystem kreiert zu haben. Es ist zwar nicht unbedingt sofort verständlich, was sich wo befindet, aber das ist bei so viel Inhalt wohl auch nicht möglich.
Die "Wurzel" des Dateisystems von Cities XL ist der Ordner "data". Hier ist faktisch alles enthalten, was es im Spiel an Inhalt gibt. Data besitzt 13 Unterordner, wobei die meisten davon entweder nur sehr schwer modbar(planet, interface, engine, shader) oder nicht wirklich nützlich/wichtig sind(sound, save, fonte, commercial). Auf diese wird zwar trotzdem eingegangen werden, aber erwartet nichts Großartiges.
Die wichtigsten Ordner hingegen sind(vom wichtigstem bis zum unwichtigstem) folgende: design, gfx, config, localization und interface, wobei config der am einfachstem modbare ist(zusammen mit localization, wobei sich
localization nur zusammen mit design vernünftig benutzen lässt) und für den Anfang völlig ausreicht. Dieser enthält recht viele *.cfg Dateien, die fast alle Konstanten die im Spiel vorkommen bestimmen(z.B. Multiplikatoren, Kameras...). Mehr darüber später.
2.1 Der "design" Ordner
Der Ordner "design" ist, dem Namen zu trotz, der Kern des Spiels. Hier befindet sich fast alles, was keine Textur und kein 3D-Modell ist. Von Skripten über Objekte(sowohl grafisch als auch spieltechnisch) bis hin zu ganzen Szenen.
Die Unterordner sind die folgenden:
1)"actor" enthält .actor Dateien(XML-Dateien die im Spiel vorkommende Vehikel und Menschen beschreiben)
2)"budget" enthält XML-Dateien die ausschließlich wirtschaftliche Faktoren behandeln.
3)"buildings" enthält .class Dateien(XML-Dateien die alle spieltechnischen Faktoren von jedem im Spiel vom User positionierbarem Objekt bestimmen).
4)"citizen" unnützer Ordner.
5)"culture" enthält XML-Dateien, die die 4 Bevölkerungsschichten beschreiben(wobei lowlife die unqualifizierten Arbeiter sind, Allam die qualifizierten("Short name" ist All. Wenn ihr also in .class oder in .layout Dateien auf "all" trifft(wenn es auf Bevölkerungsgruppen bezogen ist), dann sind damit nicht "alle" gemeint, sondern die qualifizierten Arbeitskräfte)suit die Führungskräfte und elite die Spitzenkräfte).
6)"debug" wurde wohl von MC zum Debuggen der Engine von Cities XL benutzt. Alles was er enthält, wird nicht benutzt, er ist also weitestgehend nutzlos.
7)"decoration" enthält .class Dateien, die Bäume, zum kleinen Teil das Terrain und sonstige Props beschreiben
8)"defautavatar" enthält den Standard-Avatar, der jedoch nicht nur nutzlos, sondern zudem auch noch nicht modbar ist.
9)"editor" enthält .class Dateien, die einige Bausteine die in .layout Dateien genutzt werden beschreibt. Es hat keinen Sinn, dies zu modden.
10)"emitter" enthält .class Dateien, ist aber nicht sinnvoll modbar.
11)"gem"enthält ganze 4 .class Dateien mit jeweils einer Zeile nützlichen Code. Wird nur von "citizen" und von "particle“ übertroffen.
12)"particle" enthält einen Unterordner, dieser enthält eine .class, diese enthält 1 Zeile an Code, die ein Partikel in etwa so beschreibt:"Ein Partikel ist wie ein Partikel positionierbar", und das obwohl bis jetzt kein Partikelsystem ins Spiel integriert wurde.
13)"layout" enthält .layout Dateien, die den graphische(und zum Teil auch den spielmechanischen) Teil von Straßen und Gebäuden beschreiben. Sie bringen die verschiedenen .sgbin Modelle zusammen, wodurch sie am Ende wie ein/e echte/s Straße/Gebäude aussehen.
14)"massplacementtool" enthält .class Dateien, die die korrekte Funktionsweise der verschiedenen Zonetypen ermöglichen.
15)"mission" enthält .class Dateien, die für Missionen hätten gebraucht werden können. Dieses Feature wurde leider nicht implementiert, also ist es auch nutzlos, diese zu verändern.
16)"report" enthält die .report Dateien(die mit Notepad leicht öffenbar sind). Diese verweisen auf den jeweiligen Text, der in einem anderen Ordner zu finden ist(dazu später mehr). Die Auswirkungen der anderen Einträge(theme, image, icone und mode(was sich darauf bezieht, ob der Report an ein GEM gebunden ist oder nicht)) wurden leider nicht in CitiesXL implementiert.
17)"resource"enthält .XML Dateien, die zum Teil die Ressourcen beschreiben. Faktisch nicht modbar.
18)"saynete" enthält .saynete Dateien(die mit Notepad leicht öffenbar sind). Diese beschreiben die verschiedenen Animationen und werden von den .actor Dateien genutzt.
19)"script" enthält .lua Dateien(die mit Notepad leicht öffenbar sind). Diese sind mehr als eine Ergänzung zum Hardcode, was aber nicht bedeutet, dass sie nicht modbar sind, ganz im Gegenteil.
20)"tourist" enthält eine .class Datei mit insgesamt 3 Linien Code, die besagen, dass ein Tourist ein "Tourist" ist-ein sehr ungewohnter Sachverhalt.
21)"tutorialsaves" enthält die originalen Spielstände der Tutorials.
2.2 Der "gfx" Ordner
Der Ordner "gfx" enthält alles, was im Spiel mit Grafik zu tun hat.
Die Unterordner sind die folgenden:
1)"animation" enthält nicht modbare .motion Dateien, die die verschiedenen Bewegungen(gehen, schwimmen, tanzen...)darstellen, und von .actor und von .saynete Dateien genutzt werden.
2)"avatar" enthält sowohl XML-Dateien, die die Einflussnahme der verschiedenen Schieberegler auf die Knochen kontrollieren, als auch sgbin-Archive, die das Aussehen von allem, was sich nicht durch Knochen steuern lässt(Haarschnitte, Augenbrauen und Brillen zusammen mit den jeweiligen Texturen) bestimmen.
3)"building" enthält sgbin-Archive, die das Aussehen von vielen Gebäuden bestimmen.
4)"character" enthält sgbin-Archive, die das Aussehen von allen Personen im Spiel bestimmen(hauptsächlich Fußgänger)
5)"editor" enthält sgbin-Archive, die solche nützlichen Dinge beinhalten wie einen grünen Pfeil, einen roten Pfeil und einen Pfeil ohne Farbe, oder sgbin-Archive, die nur ein gelbes Kästchen beinhalten(zum Beispiel "junction.sgbin").
6)"furnitures" enthält .sgbin-Archive, die das Aussehen von Dekoration, Papierkörben und sogar vom Millennium Wheel bestimmen.
7)"furntituresstreet" enthält .sgbin-Archive, die das Aussehen von Straßenschildern(die im Moment nicht genutzt werden), einem Müllcontainer, einem Hydranten, einer Telefonkabine, eines U-Bahneingangs und der Bushaltestelle bestimmen.
8)"landscape" enthält Gras-, Gestein- und Plazatexturen, land-Dateien, die das Aussehen der Karten bestimmen, water Dateien, die das Aussehen des Wassers bestimmen, und XML-Dateien, die die verschiedenen Materialien beschreiben.
9)"objects" enthält sgbin-Archive, die das Aussehen von verschiedenen Objekten bestimmen, die weder in die Kategorie "furniture" noch in die Kategorie "furntiturestreet" gepasst hätten.
10)"particles" enthält .particle Dateien, die wahrscheinlich die verschiedenen Partikel beschreiben. Da im Spiel keine Partikel gebraucht werden, ist auch dieser Ordner nutzlos(Ausnahme: das Auto licht).
11)"placeholder" enthält sgbin-Archive, die das Aussehen der Platzhalter bestimmen. Sie zu modden ist nicht sinnvoll.
12)"planet" enthält mehrere Texturen verschiedenen Typs.
13)"road" enthält sgbin-Archive, die das Aussehen der Straßen, der Brücken und der Tunnel bestimmen.
14)"sky" enthält mehrere XML-Dateien, die das Aussehen des Himmels unter verschiedenen Umständen beschreiben.
15)"trees" enthält alle Bäume in dem von Speedtree benutztem Format.
16)"vehicle" enthält sgbin-Archive, die das Aussehen aller Vehikel bestimmen.
2.2 Der "interface" Ordner
Der Ordner "interface" enthält fast alles, was mit der Benutzeroberfläche zu tun hat.
Die Unterordner sind die folgenden:
1)"bits" enthält gfx-Dateien, die das Aussehen von einigen Ladebildschirmen und von einigen weiteren "Interfaceschnipseln".
2)"cfg" enthält XML-Dateien, die eine unbekannte Funktion haben
3)"ddstexture" enthält dds-Dateien, die das Aussehen von allen Thumbnails bestimmen.
4)"fonts" enthält eine .gfx Datei, die das Aussehen der Fonts, die im Interface benutzt werden, bestimmt.
5)"icons" enthält tga- und XML-Dateien, die das Aussehen von unbenutzten Icons bestimmen
6)"panels" enthält gfx- und lua-Dateien, die das Aussehen der verschiedenen Panels und einige Funktionen derselben bestimmen
7)"screens" enthält lua-Dateien, die bestimmen, was beim Öffnen der verschiedenen Panels geschieht
8)"texture" enthält .tga-Dateien, die nichts bestimmen, da sie nicht genutzt werden.
2.3 Die Anderen Ordner in einer kurzen Übersicht
1)"commercial" enthält sowohl die Texturen, die an den Werbeplakaten gezeigt werden(im .png Format), als auch zwei .XML Dateien, wobei die "pdm.xml" die Auftrittswarscheinlichkeit der verschiedenen Werbeplakate beeinflusst, während die "vehicles.xml" die Auftrittswarscheinlichkeit der Autotypen der Marke Ford und Mini vor und nach dem Bau des jeweiligen Autohauses beeinflusst(bei Mini ist der Name des Autohändlers natürlich "none", also "keiner").
2)"config" enthält mehrere .cfgs, die fast alle Konstanten die im gesamten Spiel genutzt werden definieren.
3)"engine" mag zwar für die Engine wichtig sein, nicht aber für uns.
4)"fonte" enthält die zwei benutzten Fonts, wobei das Format .FNT ein von MC kreiertes Format ist, was im Moment nicht öffenbar ist.
5)"level" enthält die Maps, einen Editor dafür findet ihr im CXS-Forum.
6)"localization" enthält unter "de", "en" und "fr" jeweils die deutschen, englischen und französischen
Texte des Spiels. Das ist auch der Grund, weswegen in .class, .report und in weiteren Dateien statt der echten Texte immer nur "Keys" auftauchen, die in diesen Dateien aufgelöst werden.
7)"planet" enthält die verschiedenen Planeten, wobei im Singleplayer nur Laury benutzt wird.
8)"save" enthält den Speicherstand von Capital City.
9)"shader" enthält .fx Dateien, die C++ Code enthalten. Nicht wirklich modbar.
10)"sound" enthält zahlreiche .wav Dateien, die jedoch allesamt nicht benutzt werden.
3. Kapitel: Die Dateien
Monte Cristo scheint eine ausgeprägte Vorliebe gegenüber dem XML-Format zu haben, da fast alles, was es im Spiel an nicht grafischem Inhalt gibt, im XML-Format oder zumindest in einem XML-ähnlichem Format zur Verfügung steht. Dies kommt uns natürlich zu gute, da es bedeutet, dass wir alles in einem weit verbreiteten und einheitlichen Format haben.
Tipp: Notepad reicht völlig aus, um fast alle Dateien zu öffnen. Wenn es Dateien gibt, die nicht damit geöffnet werden sollten, werde ich darauf hinweisen
3.1 Die Konfigurationsdateien
Die Konfigurationsdateien sind der ideale Startpunkt für einen Modding-Anfänger: sie sind zwar einfach zu erlernen, bieten jedoch trotzdem ein hohes Maß an Kontrolle und viele Möglichkeiten, eigene Inhalte zu implementieren.
Geht nun bitte zum Ordner „data/config“. Hier solltet ihr einige .cfg-Dateien, zwei XML-Dateien und einen Unterordner sehen. Die .cfg-Dateien sind hier auf jeden Fall die wichtigsten Dateien, da eine der XML-Dateien auf das Ski-GEM bezogen ist, während die Andere über die Bedürfnisse der verschiedenen Bevölkerungsgruppen bei verschiedenen Einwohnerzahlen entscheidet. Die Dateien im Unterordner entscheiden darüber, wie ein Objekt bei welcher Kameraentfernung angezeigt wird. In diesem Leitfaden werden die in diesem Ordner vorhandenen XML-Dateien, der Unterordner und die in „gem“ anfangenden Konfigurationsdateien ignoriert.
3.1.1 Der erste Mod
Unser erster Mod wird dem Spiel eine neue Kamera hinzufügen.
Öffne nun die Dateien „camera.cfg“, „cameralist.cfg“ und „cameraex.cfg“
Tipp: Um beim Modden eine bessere Übersicht über die(meist vielen) gleichzeitig geöffneten Dateien zu haben, empfehle ich euch, die Task bar(Die neben dem „Start“ Knopf) auf die linke oder die rechte Seite des Bildschirm zu verschieben. Vor dem Verschieben müsst ihr kontrollieren, ob die Task bar blockiert ist, was ihr durch einen Rechtsklick auf die Task bar und die Kontrolle des Eintrags „Task bar blockieren“ kontrolliert. Wenn neben diesem ein Haken ist, dann klickt bitte auf den Eintrag, woraufhin der Haken verschwinden sollte. Nachdem ihr dies getan habt, klickt die Task bar an, haltet die Maustaste gedrückt und verschiebt die Task bar zum rechten oder zum linken Bildschirmrand. Lasst die linke Maustaste los, sobald sich die Position der Task bar ändert. Nun sollten alle offenen Fenster vertikal aufgelistet sein.
Die Dateien in einer kurzen Übersicht:
1)camera.cfg beinhaltet die allgemeinen Eigenschaften von allen Kameras
2)cameraex.cfg beinhaltet für die Engine wichtige Informationen über jede Kamera(z.B. ob
Schatten angezeigt werden sollen)
3)cameralist.cfg beinhaltet eine geordnete Liste aller Kameras, die das Spiel über die vorhandenen Kameras und deren Reihenfolge informiert. Wenn hier kein Eintrag erfolgt, dann wird die entsprechende Kamera auch nicht geladen.
3.1.1.1 Die camera.cfg
Wie ihr sehen könnt, hat in dieser Datei jede Kamera einen Eintrag in der Konfigurationsdatei, und jeder Kameraeintrag hat wiederum eine gewisse Anzahl an Attributen und an weiteren Einträgen(z.B. SPEED), die wiederum ihre eigenen Attribute haben.
Hier eine kurze Erklärung einiger Attribute:
<Height> ist die Höhe über Grund der Kamera in Metern
<DistanceMin> und <DistanceMax> sind jeweils die minimale und maximale Entfernung der Kamera vom Boden. Wenn diese beiden Werte nicht übereinstimmen, wird die Entfernung einen Zufallswert haben, der zwischen diesen beiden liegt.
<PitchMin> und <PitchMax> sind jeweils die minimale und die maximale Rotation(auf die Y-Achse bezogen) der Kamera. Wenn diese beiden Werte nicht übereinstimmen, dann ist es möglich, durch das Gedrückt halten des Mausrades und der gleichzeitigen Bewegung der Maus nach unten oder nach oben die Neigung der Kamera zu ändern(natürlich nur innerhalb des durch <PitchMin> und <PitchMax> vorgeschriebenen Limits).
<StrafeSpeed> ist die Scrollgeschwindigkeit der jeweiligen Kamera.
<SayneteVisible>, <VehicleVisible> und <PedestrianVisible> geben an, ob in dieser Kamera Szenen, Vehikel und Fußgänger zu sehen sind.
3.1.1.2 Die cameraex.cfg
Auch in dieser Datei hat jede Kamera einen Eintrag in der Konfigurationsdatei, eine gewisse Anzahl an Attributen und weitere Einträge im „Haupteintrag“ der Kamera, die wiederum eigene Attribute haben.
Hier eine kurze Erklärung einiger Attribute:
<FurnitureVisible> geht von 0 bis 4 und entscheidet über die Anzahl an Dekorationsobjekten die in der jeweiligen Kamera einsehbar sind.
<HideTunnelRoads> bestimmt, ob die Straßen, die in Tunneln geführt werden, bei dieser Kamera angezeigt werden sollen.
Die Werte unter <Bus> bestimmen ausschließlich die Icon-Größen der Bus-Icons im Spiel. Wenn ihr diese nicht gerade besonders groß oder besonders klein haben wollt, empfehle ich euch, bei allen Werten einen Mittelwert zwischen den entsprechenden Werten der vorangegangenen und der nächsten Kamera zu benutzen
Was genau alle anderen Attribute beeinflussen ist nicht klar. Es wird deswegen empfohlen, bei der Erstellung einer neuen Kamera bei diesen Attributen auf die Werte der nächstnäheren Kamera zurückzugreifen(ich rate davon ab, Mittelwerte zwischen der vorherigen und der nächsten Kamera zu machen, da dies unerwünschte Nebeneffekte mit sich bringen könnte)
3.1.1.3 Die cameralist.cfg
Die cameralist.cfg gibt dem Spiel die Ordnung der Kameras vor, wenn ihr hier also die 1st
Person-Kamera hinter die Supermappy-Kamera einfügt, dann wird, wenn aus der Supermappy-Kamera raus gezoomt wird, auch tatsächlich die 1st-Person Kamera gezeigt, da das Spiel keine Plausibilitätsprüfung macht - zurecht, da vom Spiel erwartet wird, dass ihr wisst, was ihr macht.
Die Kameraliste ist in mehrere Teile aufgeteilt, wovon im Spiel(wenn ihr keinen Freischaltmod benutzt) 3 benutzt werden: „CAMERA_GAME“, „CAMERA_EARTHVIEW“ und „CAMERA_PHOTO“
Für unseren Mod werden wir ausschließlich „CAMERA_GAME“ benutzen.
3.1.1.3 Kameras hinzufügen.
Es ist natürlich möglich, einen komplett selber geschriebenen neuen Eintrag zu machen, jedoch hat diese Methode zwei große Nachteile: sie dauert länger, und sie ist sehr viel fehleranfälliger.
Deswegen empfehle ich, die Kamera, die sich in der camera.cfg vor der Kamera, die ihr einfügen möchtet befindet auszuwählen und [Strg]+[C] zu drücken, was ihr auch gleich machen solltet.
Nun solltet ihr eine neue Zeile direkt unter der Kamera kreieren, diese rechtsklicken, und im nun erscheinenden Kontextmenü „Einfügen“ auswählen.
In diesem Leitfaden wird davon ausgegangen, dass ihr eine neue Kamera namens „STREET_NEIGHBOUR“ kreiert, und dass die Werte am Ende des Modifizierens dieser Datei zwischen denen der Kamera „STREET“ und der Kamera „NEIGHBOUR“ liegen sollen.
Die zu kopierende Kamera ist hier also „STREET“.
Wenn ihr dies getan habt, sollte unter der originalen Kamera eine weitere Kamera mit dem gleichen Namen und den gleichen Werten sein.
Um Konflikte zu vermeiden, sollten wir als erstes den Namen der neuen Kamera ändern: dies machen wir, indem wir den Namen des Opening Tag(<STREET>) und den des Closing Tag(</STREET>) ändern. In diesem Fall wird davon ausgegangen, dass der neue Opening Tag <STREET_NEIGHBOUR> und der neue Closing Tag </STREET_NEIGHBOUR> ist(Der Name ist jedoch beliebig, solange Opening Tag und Closing Tag übereinstimmen).
Nun sollten die verschiedenen Werte angepasst werden:
<Height> sollte einen Wert zwischen 150 und 200 haben(also in etwa der Mittelwert zwischen der vorherigen und der nächsten Kamera, der jedoch mehr in Richtung der vorherigen geht)
<DistanceMin> und <DistanceMax> sollten übereinstimmen und einen Wert haben, der um zirka 30% höher ist als der von <Height>
<PitchMin> und <PitchMax> sollten Werte von jeweils 0 und 89.9 haben, wodurch garantiert wird, dass der User die Kamera in alle Richtungen rotieren kann.
<Fov> sollte einen Wert von zirka 67.8 haben(also in etwa der Mittelwert zwischen der vorherigen und der nächsten Kamera, der jedoch mehr in Richtung der vorherigen geht)
Die Anderen Werte sollten alles Mittelwerte zwischen den entsprechenden Werten der vorherigen und der nächsten Kamera sein, außer natürlich die Werte die „0“ oder „1“ sind. Diese sollten immer entweder „0“ oder „1“ bleiben, also FALSE oder TRUE
Das war‟s für die camera.cfg.
Für die cameraex.cfg sollte das gleiche gemacht werden(Kamera „STREET“ kopieren und einfügen und den Namen des Opening und Closing Tag auf „STREET_NEIGHBOUR“ abändern(der Name kann auch anders sein, muss aber mit dem bereits in der camera.cfg
benutzten übereinstimmen), wobei die Attribute hier natürlich andere Namen haben(und auch Anderes bewirken)
Alle Werte der Attribute, die sich zwischen <Bus> und </Bus> befinden, sollten Mittelwerte zwischen den Werten der entsprechenden Attribute der vorherigen und der nächsten Kamera sein. Ich empfehle jedoch, keine Dezimalwerte zu benutzen, da dies meistens zu einem Absturz des Spiels führen wird.
Die Werte von <Near>, <Far>, <TopScale>, <QScale>, <EScale>, <DoTSM>, <DoPSSM>, <DoPicking>, <FakePickingDistance> und <SplitFactor> sollten denen der vorherigen Kamera entsprechen.
<FurnitureVisible> darf kein Dezimalwert sein, entscheidet euch also für eine der beiden Einstellungen(je höher, desto mehr Props werden angezeigt werden).
<FurnitureMaxViewDistance> ist die Entfernung ab der keine Props mehr angezeigt werden.
<ShowSimIcons> bestimmt ob die Gebäudesymbole angezeigt werden(Bankrottsymbol, neuer Einwohner/Arbeiter hinzugekommen und andere)
Jetzt fehlt nur noch die cameralist.cfg.
Die cameralist.cfg besteht, wie bereits erwähnt, aus verschiedenen Teilen. Wichtig sind für uns ausschließlich <Group1> und <Group2> von <CAMERA_GAME>.
Fügt nun euren Kameranamen an der richtigen Stelle ein(In unserem Fall wäre das zwischen „STREET“ und „NEIGHBOUR“. Um sicherzugehen, dass ihr ihn nicht falsch schreibt, solltet ihr ihn aus der camera.cfg oder aus der cameraex.cfg kopieren und einfügen.
Wenn ihr nun die Datei zusammenpackt und sie als .patch speichert, solltet ihr im Spiel eine weitere Kamera haben. Da es recht schwierig zu bemerken ist, ob tatsächlich eine neue Kamera da ist, könnt ihr versuchen, bei jeder einzelnen Kamera die Kamera nach oben zu rotieren-wenn es bei einer klappt, dann habt ihr erfolgreich euren ersten Mod fertiggestellt. Glückwunsch!
Achtung: Wenn ihr wirklich einen „neuen“ Kameramod machen möchtet, dann empfehle ich euch, euren Kameramod uns(ich, Oliver und Gobo77) zu geben. Wir werden ihn dann wahrscheinlich in unseren Kameramod einbauen-natürlich mit Eintrag eures Namens in den Anfangspost des Kameramod-Threads
3.1.2 Cheating
Zum Glück(oder leider) ist Cheating in Cities XL sehr einfach: es ist nicht unbedingt nötig, mehrere dutzend Dateien jeweils einzeln zu bearbeiten, nein, es reicht, in einer einzigen Datei ein paar wenige Änderungen vorzunehmen: diese Datei nennt sich „sim.cfg“ und ist faktisch eine der wichtigsten Dateien im Spiel.
Die sim.cfg
Die sim.cfg enthält mehrere Attribute, die das Verhalten des Spiels maßgeblich beeinflussen. Ich werde euch nun die am besten für Cheating benutzbaren aufzählen und erklären:
<percentjoblessmax> ist die Rate an Arbeitslosen, ab der niemand mehr der entsprechenden Bevölkerungsgruppe einzieht. Wenn ihr diese Rate auf 99% stellt, dann werden auch dann neue Bewohner einziehen, wenn fast alle Bewohner arbeitslos sind.
<forcemaxsatisfaction> bewirkt, wenn auf „1“ gesetzt, dass alle Einwohner rundum glücklich sind.
<enablebankruptcy> bewirkt, wenn auf „1“ gesetzt, dass die Firmen nicht mehr bankrott gehen können.
Das war eine kurze Übersicht über die sim.cfg. Die Attribute sind zwar eigentlich viel mehr, jedoch würde es den Rahmen sprengen, hier alle zu erklären. Außerdem sind alle Attribute in dieser Datei kommentiert(wenn auch auf Französisch), was bedeutet, dass ihr auch alleine den Sinn und die Benutzung der restlichen Attribute verstehen könnt-notfalls halt durch ausprobieren.
3.2 Die class-Dateien
Wie wir bereits gesehen haben, sind Konfigurationsdateien zweifellos der beste Einstieg ins Modding von Cities XL. Sie sind außerdem ideal zur Veränderung von globalen Variablen und zur Definierung von Konstanten. Sie sind jedoch nicht dafür geeignet, Werte einzelner Objekte zu ändern - und hier kommen Class-Dateien ins Spiel.
Class-Dateien sind, wie die Konfigurationsdateien, zwar eigentlich nur umbenannte XML-Dateien, besitzen jedoch im Gegensatz zu Konfigurationsdateien ein einheitliches Design und einheitliche Attribute, was nicht nur en Leitfaden kürzer, sondern auch die Erlernung des Dateiformats einfacher macht.
Tipp: Um die Lage aller Gebäude im Dateisystem ausfindig zu machen, empfehle ich, karel53‟s Tabelle zu benutzen. Diese ist in der „Modding“ Sektion des CXS-Forums zu finden
Eine Übersicht über die verschiedenen Attribute
Erst einmal eine Übersicht über alle Attribute:
<View>
<Panel> sollte immer BuildingSelection als Wert haben
<NameKey>, <NameKeySim>, <DescriptionKey>, <Param1Key>, <Value1Key>, <Param2Key>, <Value2Key>, <Param3Key> und <Value3Key> werden im Teil über localization-Dateien behandelt
</View>
<Display>
<Model> hat als Wert den Dateinamen des zu ladende Modells. Die Datei mit dem hier angegebenen Dateinamen wird vom Spiel im Ordner „data/gfx/building“ gesucht.
<Placeholder> hat als Wert den Dateinamen des zu ladenden Placeholders, also ein Modell was geladen wird wenn <Model> nicht gefunden wird. Der Wert von diesem Attribut sollte nicht geändert werden.
<SelectionLayer> bestimmt den Layer, der beim Auswählen des Gebäudes angezeigt wird - in diesem Fall „School_1“
<Thumb> bestimmt das Icon, was im Menü für das Objekt angezeigt wird.
Eine Datei mit dem angegebenen Dateinamen wird im Ordner data/interface/ddstexture/buildings“ gesucht, wobei die Datei im .dds oder im .tga Format vorhanden sein muss. Die Dateiendung muss mit angegeben werden.
</Display>
<Placement>
<Type> kann als Wert „BUILDING“, „PLAZA“, „ROAD“ oder „TERRAFORM“ haben und bestimmt die Weise, in der das Objekt positioniert wird
<Overpickable> sollte als Wert immer 1 haben.
<Merge> sollte als Wert immer 0 haben.
</Placement>
<Terraform>
<Enabled> bestimmt, ob das Gebäude das Gelände unter und um sich terraformen darf.
<UseDefault> sollte als Wert immer 1 haben.
<DigDepth> bestimmt die maximale Tiefe der Grube, die das Gebäude graben darf.
<LevelWidth>, <CutWidth> und <AngleMax> haben eine unbekannte Funktion.
</Terraform>
<LayerDisplay> bestimmt den Layer, der bei der Platzierung des Gebäudes angezeigt wird.
</Placement>
<EntityPosition>
<CollisionShape>
<Dimension> bestimmt die Länge und Breite des Objektes
<Height> bestimmt die Höhe des Objektes
</CollisionShape>
</EntityPosition>
<Layouts>
<LayoutFileX> bestimmt die zu ladende layout-Datei, Mehr darüber später.
</Layouts>
<Tags>Bestimmt die Tags. Je nach Tag-Auswahl wird das Objekt entsprechend im Menü positioniert.
<Entity>
<Type> kann als Wert „BUILDING“, „ROADLINE“ oder <PLAZA> haben.
<Serializable> bestimmt, ob das Objekt serialisierbar ist.
<WithOptional1> bestimmt die erste „Nebeneigenschaft“ des Objektes.
<WithOptional2> bestimmt die zweite „Nebeneigenschaft“ des Objektes
</Entity>
<JobProvider>
<MaxJobPerCulture>
<LowLife> bestimmt die Anzahl an Jobs für die unqualifizierten Arbeitskräfte
<AllAm> bestimmt die Anzahl an Jobs für die qualifizierten Arbeitskräfte
<Suit> bestimmt die Anzahl an Jobs für die Führungskräfte
<Elite> bestimmt die Anzahl an Jobs für die Spitzenkräfte
</MaxJobPerCulture>
<JobAttractivityPerCulture>
<LowLife> bestimmt die Attraktivität der Jobs für die unqualifizierten Arbeitskräfte
<AllAm> bestimmt die Attraktivität der Jobs für die qualifizierten Arbeitskräfte
<Suit> bestimmt die Attraktivität der Jobs für die Führungskräfte
<Elite> bestimmt die Attraktivität der Jobs für die Spitzenkräfte
</JobAttractivityPerCulture>
</JobProvider>
<Layer>
<ShapeX>
<LayerName> bestimmt den Namen des vom Gebäude beeinflussten Layer
<Radius> bestimmt den Radius, auf den die Änderung Einfluss nehmen sollte
<InfluenceMin> bestimmt den minimalen Einfluss des Gebäudes auf den Layer
<InfluenceMax> bestimmt den maximalen Einfluss des Gebäudes auf den Layer
<Type> bestimmt, wie der Layer sich ausbreiten soll
<GroupID> hat einen unbekannten Effekt, es ist jedoch ratsam, den Wert nicht zu verändern
</ShapeX>
</Layer>
<BudgetAgent>
<CitizenProvider> hat einen unbekannten Effekt
<MaxMonthlyCost> bestimmt die maximalen monatlichen Kosten
<UpkeepCost> bestimmt die Unterhaltungskosten des Gebäudes
<IsCityLink> bestimmt, ob das Gebäude ein CityLink ist
<IsPublicBuilding> bestimmt, ob das Gebäude ein öffentliches Gebäude ist
<BudgetExpenseCategory>bestimmt, in welche Kategorie die verursachten Kosten fallen
</BudgetAgent>
<ResourceAgent>
<MaxProduction>
<ProductionX>
<ResourceName> Name der produzierten Ressource
<ResourceNumber> bestimmt die maximale Anzahl an Ressourcen, die produziert werden können
</ProductionX>
</MaxProduction>
<MaxRequirement>
<RequirementX>
<ResourceName> Name der benötigten Ressource
<ResourceNumber> bestimmt die maximale Anzahl an Ressource, die verbraucht werden können
<RequirementX>
</MaxRequirement>
</ResourceAgent>
<Construction>
<IsDestroyable>bestimmt, ob das Gebäude zerstörbar ist
<IsZoneConstruction>bestimmt, ob das Gebäude in Zonen gebaut werden kann
<PlacementType>bestimmt, wie das Gebäude gebaut werden soll
</Construction>
<Conditions>
Wird hier nicht erklärt, da in dieser Sektion sehr viele verschiedene Attribute benutzt werden können.
</Conditions>
Hinweis: Hier wurden nicht alle Attribute eingetragen, da dies leider den Rahmen sprengen würde.
Versucht nun selber, folgendes zu tun:
1)Verringert den Effekt des Gebäudes
2)Verringert die Anzahl an eingestellten unqualifizierten Arbeitern
Die Lösung findet ihr auf der letzten Seite dieses Leitfadens.
3.2 layout-Dateien
Wir haben nun gesehen, wie sowohl globale Variablen als auch Werte einzelner Objekte geändert werden können. Es wird nun Zeit zu sehen, wie wir das Aussehen des Umfelds von Objekten ändern können.
Dies wird durch layout-Dateien gemacht. Diese Dateien sind zum Glück noch einheitlicher aufgebaut als .class Dateien.
3.2.1 Lampen neben einem Gebäude positionieren.
Wir werden nun versuchen, eine Lampe neben einem Gebäude zu positionieren, wobei in diesem Leitfaden das „Gesundheitszentrum“ benutzt wird, was die niedrigste Stufe der Gesundheitseinrichtungen darstellt.
Wie ihr vielleicht schon im Spiel bemerkt habt, hat das Gesundheitszentrum zwar einen Weg, der vom Eingang bis zur Straße führt, dieser wird jedoch nur von einer Lampe beleuchtet.
Öffnet nun die Datei „b_hea01_t1_base.layout“ im Ordner „data/design/layout/b_service“
Tipp: wenn ihr mal nicht wisst, wo ihr eine bestimme layout-Datei findet, schaut euch einfach das Attribut „<LayoutFile1>“an.
Eine layout-Datei besteht aus vielen verschiedenen <LayoutEntry> Einträgen, die jeweils ein Objekt in der Szene darstellen.
Hier ist ein kurze Übersicht über die verschiedenen Attribute, die ein solcher Eintrag üblicherweise hat:
<LayoutEntry>
<ID> bestimmt die Unique ID des Objektes. Diese ist zwar beliebig, darf jedoch mit keiner ID von einem anderen Objekt in der gleichen Datei übereinstimmen
<Type> bestimmt den Typ des Objektes. Ich empfehle, fast immer FURNITURE zu benutzen.
<PrototypeFile> ist die .class Datei, die das zu verwende Modell bestimmt
<Position> bestimmt die Position des Objektes
<Rotation> bestimmt die Rotation des Objektes
</LayoutEntry>
Um nun eine neue Straßenlampe zu erstellen, müssen wir einen neuen <LayoutEntry> erschaffen. Dies macht ihr am besten, indem ihr einen bereits bestehenden Eintrag kopiert und direkt unter dem bereits bestehenden einfügt.
Danach solltet ihr zuallererst die ID ändern.
„Type“ sollte „Furniture“ sein, und das PrototypeFile sollte das der Straßenlampe sein, also „data\design\decoration\furniture\bobo\f_bob_streetlight02.class“.
„Position“ sollte auf „-4.32560034,-12.14140034, 0.004272460006“ gesetzt werden(ihr könnt es natürlich ändern, wenn ihr eine andere Position bevorzugt).
Wenn ihr nun die Datei packt, das Spiel startet und ein neues Gesundheitszentrum baut, solltet ihr auf dem Gesundheitszentrum neben dem Weg eine Straßenlampe sehen. Glückwunsch!
.de, .fr und .en-Dateien
Diese Dateien werden auch Localization-Dateien genannt, da sie die Texte des Spiels bestimmen und es somit lokalisieren.
In Cities XL werden für alle Texte Keys benutzt, damit nicht in jeder Datei der Text in drei verschiedene Sprachen erscheint, was die Datei nur unübersichtlich machen würde.
Diese Keys sind folgendermaßen aufgebaut:
CLASS_KEYNAME_TYP
Class steht für die Klasse des Objektes, also B_(Building), R_(Road), H_(House), D_(Decoration) und LDM_(Landmark).
Keyname steht für den Keynamen, also den(verkürzten) Namen des Objektes.
Typ steht für den Typen des Textes, also _TTL(Title), _TXT(Text) und _DES(Description)
In der aufrufenden Datei muss außerdem vor dem Keynamen immer ein „&“ stehen, während in den Lokalisationsdateien „#FIELD_ID“ dem Key vorangesetzt werden muss.
Verwirrt? Hier ist ein Beispiel:
In der aufrufenden Datei:
<Title>&CLASS_KEYNAME_TTL</Title> <Text>&CLASS_KEYNAME_TXT</Text> <Description>&CLASS_KEYNAME_DES</Description>
In der Lokalisationsdatei:
#FIELD_ID CLASS_KEYNAME_TTL
Dies ist der Titel
#FIELD_ID CLASS_KEYNAME_TXT
Dies ist der Text
#FIELD_ID CLASS_KEYNAME_DES
Dies ist die Beschreibung
Lösung
Lösung der Aufgabe auf Seite 12:
1)<InfluenceMin> und <InfluenceMax> müssen verringert werden
2)<LowLife> unter <JobProvider> und <MaxJobPerCulture> muss verringert werden.
Schlusswort
Dies ist die erste Version des kurzen Leitfadens zum Modding von Cities XL, und ich hoffe, es hat euch gefallen, obwohl natürlich sicherlich noch ein paar Fehler drin sind. Mir zumindest hat es Spaß gemacht, und ich hoffe, dass das selbe für euch gilt.
Wenn ihr Verbesserungsvorschläge habt, dann zögert nicht, einen Post im entsprechendem Thread zu verfassen.
.sgbin Dateien
Sind Dateien die die Textur und höchstwarscheinlich auch das Modell der jeweiligen Gebäude bestimmen. Da die Prozesse diese zu entpacken (ist ein manueller Vorgang) und das Verändern der Texturen sehr aufwenig ist, wird auf diese hier nicht näher eingegangen. Bei besonderem Interesse, bitte einen CXL-Modder kontaktieren.
Copyright-Anmerkungen.
Dieses Werk wird euch unter folgenden Bedingungen zur Verfügung gestellt:
1) Es ist untersagt, dieses Werk ohne eine ausdrückliche schriftliche Genehmigung von Seiten des Autors zu verändern
2) Es ist nicht untersagt, dieses Werk zu vervielfältigen
3) Es ist nicht untersagt, dieses Werk oder Kopien des selben in jeglicher Form zu verbreiten.
©2010, haltendehand
)Dazu wurde durch den User haltendehand ein kurzer Leitfaden geschrieben, der ein Grundlagenwissen zum Modden in Cities XL gibt. Die Berechtigung zur Verbreitung dieses Textes liegt mir vor.
Die im Leitfaden beschriebenen Packing und Unpacking Tools sind hier downzuloaden:
Beschreibung und Download von Okeanos' Packager
Beschreibung und Download von Okeanos' Unpacker
Der folgende Text wurde durch den User haltendehand verfasst.
Ein Leitfaden zum Dateisystem und zum Modding von CXL.
1. Kapitel: Vor dem Modden...
1.1 Konventionen
Buchstaben oder Zeichen, die sich zwischen [ und ] befinden stellen Tasten dar, die gedrückt werden sollen.
1.2 Voraussetzungen
1(eine) legale Kopie des Spiels "Cities XL" von Monte Cristo Games
1.3 Vorbereitungen
Da Monte Cristo Games leider die gesamten Spielinhalte in Archive gepackt hat, müssen wir, um auf diese Daten zuzugreifen, die Spielinhalte erst entpacken. Dies ist durch ein externes Programm am einfachsten zu erreichen. Inzwischen gibt es 4 solcher Programme, wobei in diesem Leitfaden davon ausgegangen wird, dass ihr Okeanos„ Unpacker und Packager benutzt. Es ist zwar ohne Probleme möglich, diesen Leitfaden mit einem Anderen Programm zu verfolgen, jedoch müsst ihr in diesem Fall einige Anweisungen anpassen.
1.4 Die Bedienung der beiden Programme
1.4.1 Der Unpacker
Um alle Spieldaten von einer Installation zu entpacken, wählt bitte den Menü punkt "Unpack Installation". Daraufhin sollten die TextBox namens “Game Folder” und der daneben liegende Button "Browse" nicht mehr ausgegraut erscheinen. Stellt bitte vor dem Entpacken sicher, dass der angezeigte Ordner auch tatsächlich mit dem Ordner in dem eure CXL-Installation liegt übereinstimmt.
Wenn dies nicht der Fall ist, dann klickt bitte auf "Browse" und geht in eurem Dateisystem bis zum Ordner, der eure CXL-Installation enthält.
Um dem Programm zu sagen, wo die Spieledaten entpackt werden sollten, klickt bitte auf den Button "Browse" neben der TextBox "Target Folder", und navigiert zum Ordner in dem die Spieldaten entpackt werden sollen.
Um die ausgewählte Installation nun auch tatsächlich zu entpacken, muss man auf "Run" klicken. Der Status der Operation wird, zusammen mit dem Namen der Datei die aktuell verarbeitet wird, unten im Programm angezeigt.
Wenn ihr hingegen einzelne .patch, .pak oder gar .sgbin Archive entpacken wollt, solltet ihr auf "Unpack Single Package" klicken. Nun sollte die TextBox namens "Package Filename" und der 1 danebenliegende Button "Browse" nicht mehr ausgegraut sein. Um die Datei auszuwählen, die entpackt werden soll, klickt bitte auf "Browse", navigiert zum Ordner, der diese Datei beinhaltet, wählt diese Datei aus und klickt auf "Öffnen".
Um dem Programm zu sagen, wohin die Datei entpackt werden soll, klickt bitte auf den Button "Browse" neben der TextBox "Target Folder", und navigiert zum Ordner, in dem die Datei entpackt werden soll.
1.4.2 Der Packager
Um die Dateien, nachdem sie modifiziert wurden, wieder in das Spiel einzufügen, wird ein weiteres Programm gebraucht, was auch von Okeanos kommt: der Packager.
Um eine modifizierte Datei ins Spiel einzufügen, muss sie erst mal ins Programm geladen werden. Dies macht ihr indem ihr auf den Button "+ New Entry" klickt. Im nun aufgegangenen Fenster mit Namen "Package Entry" solltet ihr auf den Button "Browse" klicken, bis zum Ordner navigieren, der die geänderte Datei enthält, diese auswählen und auf "Öffnen" klicken.
In der TextBox "Full Name" sollte nun der Dateiname stehen. Diesen Namen könnt ihr, wenn ihr möchtet, ändern, dies macht jedoch keinen wirklichen Unterschied. Unter "Format" könnt ihr zwischen "Compressed"(empfohlen) und "Uncompressed" wählen. Unkomprimierte Dateien sind größer, bieten jedoch trotzt dem keinen spürbaren Geschwindigkeitsvorteil.
Klickt nun auf "Ok".
Nun sollte die Datei in der "Haupttabelle" im Programm hinzugefügt worden sein.
Wenn ihr weitere Dateien hinzufügen wollt, macht bitte dasselbe, was ihr gemacht habt, um die erste Datei in das Programm zu laden. Es ist leider nicht möglich, mehrere Dateien auf einmal in das Programm zu laden.
Wenn ihr alle Dateien ins Programm geladen habt, die ihr ersetzen wollt, dann müsst ihr das ganze natürlich noch als .patch abspeichern. Dies macht ihr, indem ihr entweder auf die Diskette, oder auf "File" und dann auf "Save" klickt.
Hier müsst ihr dann bis in den Unterordner "Paks" navigieren, der sich im Installationsordner von Cities XL befindet, und dort die Datei abspeichern, indem ihr erst in die TextBox "Dateiname" euren gewünschten Dateinamen mit der Endung ".patch"("Dateiname. patch") eingibt, und dann auf "Speichern" klickt.
Achtung: Die Dateiendung .pak sollte nicht benutzt werden, da sie erfahrungsgemäß Probleme bereiten kann.
Achtung: Die Namenskonvention für Modnamen ist: Autor_Mod.patch, und nicht Autor_Mod_Version.patch, da ansonsten durch die verschiedenen Modversionen Konflikte auftreten könnten
Tipp: Der Ordner "paks" kann unendlich viele Unterordner haben, die wiederum unendlich viele Unterordner haben können. Ich empfehle folgendes Ordnersystem: "Paks/Autor/Modname"
2. Kapitel: Das Dateisystem
Wenn es etwas gibt, was man Monte Cristo nicht vorwerfen kann, dann ist es das, ein undurchsichtiges Dateisystem kreiert zu haben. Es ist zwar nicht unbedingt sofort verständlich, was sich wo befindet, aber das ist bei so viel Inhalt wohl auch nicht möglich.
Die "Wurzel" des Dateisystems von Cities XL ist der Ordner "data". Hier ist faktisch alles enthalten, was es im Spiel an Inhalt gibt. Data besitzt 13 Unterordner, wobei die meisten davon entweder nur sehr schwer modbar(planet, interface, engine, shader) oder nicht wirklich nützlich/wichtig sind(sound, save, fonte, commercial). Auf diese wird zwar trotzdem eingegangen werden, aber erwartet nichts Großartiges.
Die wichtigsten Ordner hingegen sind(vom wichtigstem bis zum unwichtigstem) folgende: design, gfx, config, localization und interface, wobei config der am einfachstem modbare ist(zusammen mit localization, wobei sich
localization nur zusammen mit design vernünftig benutzen lässt) und für den Anfang völlig ausreicht. Dieser enthält recht viele *.cfg Dateien, die fast alle Konstanten die im Spiel vorkommen bestimmen(z.B. Multiplikatoren, Kameras...). Mehr darüber später.
2.1 Der "design" Ordner
Der Ordner "design" ist, dem Namen zu trotz, der Kern des Spiels. Hier befindet sich fast alles, was keine Textur und kein 3D-Modell ist. Von Skripten über Objekte(sowohl grafisch als auch spieltechnisch) bis hin zu ganzen Szenen.
Die Unterordner sind die folgenden:
1)"actor" enthält .actor Dateien(XML-Dateien die im Spiel vorkommende Vehikel und Menschen beschreiben)
2)"budget" enthält XML-Dateien die ausschließlich wirtschaftliche Faktoren behandeln.
3)"buildings" enthält .class Dateien(XML-Dateien die alle spieltechnischen Faktoren von jedem im Spiel vom User positionierbarem Objekt bestimmen).
4)"citizen" unnützer Ordner.
5)"culture" enthält XML-Dateien, die die 4 Bevölkerungsschichten beschreiben(wobei lowlife die unqualifizierten Arbeiter sind, Allam die qualifizierten("Short name" ist All. Wenn ihr also in .class oder in .layout Dateien auf "all" trifft(wenn es auf Bevölkerungsgruppen bezogen ist), dann sind damit nicht "alle" gemeint, sondern die qualifizierten Arbeitskräfte)suit die Führungskräfte und elite die Spitzenkräfte).
6)"debug" wurde wohl von MC zum Debuggen der Engine von Cities XL benutzt. Alles was er enthält, wird nicht benutzt, er ist also weitestgehend nutzlos.
7)"decoration" enthält .class Dateien, die Bäume, zum kleinen Teil das Terrain und sonstige Props beschreiben
8)"defautavatar" enthält den Standard-Avatar, der jedoch nicht nur nutzlos, sondern zudem auch noch nicht modbar ist.
9)"editor" enthält .class Dateien, die einige Bausteine die in .layout Dateien genutzt werden beschreibt. Es hat keinen Sinn, dies zu modden.
10)"emitter" enthält .class Dateien, ist aber nicht sinnvoll modbar.
11)"gem"enthält ganze 4 .class Dateien mit jeweils einer Zeile nützlichen Code. Wird nur von "citizen" und von "particle“ übertroffen.
12)"particle" enthält einen Unterordner, dieser enthält eine .class, diese enthält 1 Zeile an Code, die ein Partikel in etwa so beschreibt:"Ein Partikel ist wie ein Partikel positionierbar", und das obwohl bis jetzt kein Partikelsystem ins Spiel integriert wurde.
13)"layout" enthält .layout Dateien, die den graphische(und zum Teil auch den spielmechanischen) Teil von Straßen und Gebäuden beschreiben. Sie bringen die verschiedenen .sgbin Modelle zusammen, wodurch sie am Ende wie ein/e echte/s Straße/Gebäude aussehen.
14)"massplacementtool" enthält .class Dateien, die die korrekte Funktionsweise der verschiedenen Zonetypen ermöglichen.
15)"mission" enthält .class Dateien, die für Missionen hätten gebraucht werden können. Dieses Feature wurde leider nicht implementiert, also ist es auch nutzlos, diese zu verändern.
16)"report" enthält die .report Dateien(die mit Notepad leicht öffenbar sind). Diese verweisen auf den jeweiligen Text, der in einem anderen Ordner zu finden ist(dazu später mehr). Die Auswirkungen der anderen Einträge(theme, image, icone und mode(was sich darauf bezieht, ob der Report an ein GEM gebunden ist oder nicht)) wurden leider nicht in CitiesXL implementiert.
17)"resource"enthält .XML Dateien, die zum Teil die Ressourcen beschreiben. Faktisch nicht modbar.
18)"saynete" enthält .saynete Dateien(die mit Notepad leicht öffenbar sind). Diese beschreiben die verschiedenen Animationen und werden von den .actor Dateien genutzt.
19)"script" enthält .lua Dateien(die mit Notepad leicht öffenbar sind). Diese sind mehr als eine Ergänzung zum Hardcode, was aber nicht bedeutet, dass sie nicht modbar sind, ganz im Gegenteil.
20)"tourist" enthält eine .class Datei mit insgesamt 3 Linien Code, die besagen, dass ein Tourist ein "Tourist" ist-ein sehr ungewohnter Sachverhalt.
21)"tutorialsaves" enthält die originalen Spielstände der Tutorials.
2.2 Der "gfx" Ordner
Der Ordner "gfx" enthält alles, was im Spiel mit Grafik zu tun hat.
Die Unterordner sind die folgenden:
1)"animation" enthält nicht modbare .motion Dateien, die die verschiedenen Bewegungen(gehen, schwimmen, tanzen...)darstellen, und von .actor und von .saynete Dateien genutzt werden.
2)"avatar" enthält sowohl XML-Dateien, die die Einflussnahme der verschiedenen Schieberegler auf die Knochen kontrollieren, als auch sgbin-Archive, die das Aussehen von allem, was sich nicht durch Knochen steuern lässt(Haarschnitte, Augenbrauen und Brillen zusammen mit den jeweiligen Texturen) bestimmen.
3)"building" enthält sgbin-Archive, die das Aussehen von vielen Gebäuden bestimmen.
4)"character" enthält sgbin-Archive, die das Aussehen von allen Personen im Spiel bestimmen(hauptsächlich Fußgänger)
5)"editor" enthält sgbin-Archive, die solche nützlichen Dinge beinhalten wie einen grünen Pfeil, einen roten Pfeil und einen Pfeil ohne Farbe, oder sgbin-Archive, die nur ein gelbes Kästchen beinhalten(zum Beispiel "junction.sgbin").
6)"furnitures" enthält .sgbin-Archive, die das Aussehen von Dekoration, Papierkörben und sogar vom Millennium Wheel bestimmen.
7)"furntituresstreet" enthält .sgbin-Archive, die das Aussehen von Straßenschildern(die im Moment nicht genutzt werden), einem Müllcontainer, einem Hydranten, einer Telefonkabine, eines U-Bahneingangs und der Bushaltestelle bestimmen.
8)"landscape" enthält Gras-, Gestein- und Plazatexturen, land-Dateien, die das Aussehen der Karten bestimmen, water Dateien, die das Aussehen des Wassers bestimmen, und XML-Dateien, die die verschiedenen Materialien beschreiben.
9)"objects" enthält sgbin-Archive, die das Aussehen von verschiedenen Objekten bestimmen, die weder in die Kategorie "furniture" noch in die Kategorie "furntiturestreet" gepasst hätten.
10)"particles" enthält .particle Dateien, die wahrscheinlich die verschiedenen Partikel beschreiben. Da im Spiel keine Partikel gebraucht werden, ist auch dieser Ordner nutzlos(Ausnahme: das Auto licht).
11)"placeholder" enthält sgbin-Archive, die das Aussehen der Platzhalter bestimmen. Sie zu modden ist nicht sinnvoll.
12)"planet" enthält mehrere Texturen verschiedenen Typs.
13)"road" enthält sgbin-Archive, die das Aussehen der Straßen, der Brücken und der Tunnel bestimmen.
14)"sky" enthält mehrere XML-Dateien, die das Aussehen des Himmels unter verschiedenen Umständen beschreiben.
15)"trees" enthält alle Bäume in dem von Speedtree benutztem Format.
16)"vehicle" enthält sgbin-Archive, die das Aussehen aller Vehikel bestimmen.
2.2 Der "interface" Ordner
Der Ordner "interface" enthält fast alles, was mit der Benutzeroberfläche zu tun hat.
Die Unterordner sind die folgenden:
1)"bits" enthält gfx-Dateien, die das Aussehen von einigen Ladebildschirmen und von einigen weiteren "Interfaceschnipseln".
2)"cfg" enthält XML-Dateien, die eine unbekannte Funktion haben
3)"ddstexture" enthält dds-Dateien, die das Aussehen von allen Thumbnails bestimmen.
4)"fonts" enthält eine .gfx Datei, die das Aussehen der Fonts, die im Interface benutzt werden, bestimmt.
5)"icons" enthält tga- und XML-Dateien, die das Aussehen von unbenutzten Icons bestimmen
6)"panels" enthält gfx- und lua-Dateien, die das Aussehen der verschiedenen Panels und einige Funktionen derselben bestimmen
7)"screens" enthält lua-Dateien, die bestimmen, was beim Öffnen der verschiedenen Panels geschieht
8)"texture" enthält .tga-Dateien, die nichts bestimmen, da sie nicht genutzt werden.
2.3 Die Anderen Ordner in einer kurzen Übersicht
1)"commercial" enthält sowohl die Texturen, die an den Werbeplakaten gezeigt werden(im .png Format), als auch zwei .XML Dateien, wobei die "pdm.xml" die Auftrittswarscheinlichkeit der verschiedenen Werbeplakate beeinflusst, während die "vehicles.xml" die Auftrittswarscheinlichkeit der Autotypen der Marke Ford und Mini vor und nach dem Bau des jeweiligen Autohauses beeinflusst(bei Mini ist der Name des Autohändlers natürlich "none", also "keiner").
2)"config" enthält mehrere .cfgs, die fast alle Konstanten die im gesamten Spiel genutzt werden definieren.
3)"engine" mag zwar für die Engine wichtig sein, nicht aber für uns.
4)"fonte" enthält die zwei benutzten Fonts, wobei das Format .FNT ein von MC kreiertes Format ist, was im Moment nicht öffenbar ist.
5)"level" enthält die Maps, einen Editor dafür findet ihr im CXS-Forum.
6)"localization" enthält unter "de", "en" und "fr" jeweils die deutschen, englischen und französischen
Texte des Spiels. Das ist auch der Grund, weswegen in .class, .report und in weiteren Dateien statt der echten Texte immer nur "Keys" auftauchen, die in diesen Dateien aufgelöst werden.
7)"planet" enthält die verschiedenen Planeten, wobei im Singleplayer nur Laury benutzt wird.
8)"save" enthält den Speicherstand von Capital City.
9)"shader" enthält .fx Dateien, die C++ Code enthalten. Nicht wirklich modbar.
10)"sound" enthält zahlreiche .wav Dateien, die jedoch allesamt nicht benutzt werden.
3. Kapitel: Die Dateien
Monte Cristo scheint eine ausgeprägte Vorliebe gegenüber dem XML-Format zu haben, da fast alles, was es im Spiel an nicht grafischem Inhalt gibt, im XML-Format oder zumindest in einem XML-ähnlichem Format zur Verfügung steht. Dies kommt uns natürlich zu gute, da es bedeutet, dass wir alles in einem weit verbreiteten und einheitlichen Format haben.
Tipp: Notepad reicht völlig aus, um fast alle Dateien zu öffnen. Wenn es Dateien gibt, die nicht damit geöffnet werden sollten, werde ich darauf hinweisen
3.1 Die Konfigurationsdateien
Die Konfigurationsdateien sind der ideale Startpunkt für einen Modding-Anfänger: sie sind zwar einfach zu erlernen, bieten jedoch trotzdem ein hohes Maß an Kontrolle und viele Möglichkeiten, eigene Inhalte zu implementieren.
Geht nun bitte zum Ordner „data/config“. Hier solltet ihr einige .cfg-Dateien, zwei XML-Dateien und einen Unterordner sehen. Die .cfg-Dateien sind hier auf jeden Fall die wichtigsten Dateien, da eine der XML-Dateien auf das Ski-GEM bezogen ist, während die Andere über die Bedürfnisse der verschiedenen Bevölkerungsgruppen bei verschiedenen Einwohnerzahlen entscheidet. Die Dateien im Unterordner entscheiden darüber, wie ein Objekt bei welcher Kameraentfernung angezeigt wird. In diesem Leitfaden werden die in diesem Ordner vorhandenen XML-Dateien, der Unterordner und die in „gem“ anfangenden Konfigurationsdateien ignoriert.
3.1.1 Der erste Mod
Unser erster Mod wird dem Spiel eine neue Kamera hinzufügen.
Öffne nun die Dateien „camera.cfg“, „cameralist.cfg“ und „cameraex.cfg“
Tipp: Um beim Modden eine bessere Übersicht über die(meist vielen) gleichzeitig geöffneten Dateien zu haben, empfehle ich euch, die Task bar(Die neben dem „Start“ Knopf) auf die linke oder die rechte Seite des Bildschirm zu verschieben. Vor dem Verschieben müsst ihr kontrollieren, ob die Task bar blockiert ist, was ihr durch einen Rechtsklick auf die Task bar und die Kontrolle des Eintrags „Task bar blockieren“ kontrolliert. Wenn neben diesem ein Haken ist, dann klickt bitte auf den Eintrag, woraufhin der Haken verschwinden sollte. Nachdem ihr dies getan habt, klickt die Task bar an, haltet die Maustaste gedrückt und verschiebt die Task bar zum rechten oder zum linken Bildschirmrand. Lasst die linke Maustaste los, sobald sich die Position der Task bar ändert. Nun sollten alle offenen Fenster vertikal aufgelistet sein.
Die Dateien in einer kurzen Übersicht:
1)camera.cfg beinhaltet die allgemeinen Eigenschaften von allen Kameras
2)cameraex.cfg beinhaltet für die Engine wichtige Informationen über jede Kamera(z.B. ob
Schatten angezeigt werden sollen)
3)cameralist.cfg beinhaltet eine geordnete Liste aller Kameras, die das Spiel über die vorhandenen Kameras und deren Reihenfolge informiert. Wenn hier kein Eintrag erfolgt, dann wird die entsprechende Kamera auch nicht geladen.
3.1.1.1 Die camera.cfg
Wie ihr sehen könnt, hat in dieser Datei jede Kamera einen Eintrag in der Konfigurationsdatei, und jeder Kameraeintrag hat wiederum eine gewisse Anzahl an Attributen und an weiteren Einträgen(z.B. SPEED), die wiederum ihre eigenen Attribute haben.
Hier eine kurze Erklärung einiger Attribute:
<Height> ist die Höhe über Grund der Kamera in Metern
<DistanceMin> und <DistanceMax> sind jeweils die minimale und maximale Entfernung der Kamera vom Boden. Wenn diese beiden Werte nicht übereinstimmen, wird die Entfernung einen Zufallswert haben, der zwischen diesen beiden liegt.
<PitchMin> und <PitchMax> sind jeweils die minimale und die maximale Rotation(auf die Y-Achse bezogen) der Kamera. Wenn diese beiden Werte nicht übereinstimmen, dann ist es möglich, durch das Gedrückt halten des Mausrades und der gleichzeitigen Bewegung der Maus nach unten oder nach oben die Neigung der Kamera zu ändern(natürlich nur innerhalb des durch <PitchMin> und <PitchMax> vorgeschriebenen Limits).
<StrafeSpeed> ist die Scrollgeschwindigkeit der jeweiligen Kamera.
<SayneteVisible>, <VehicleVisible> und <PedestrianVisible> geben an, ob in dieser Kamera Szenen, Vehikel und Fußgänger zu sehen sind.
3.1.1.2 Die cameraex.cfg
Auch in dieser Datei hat jede Kamera einen Eintrag in der Konfigurationsdatei, eine gewisse Anzahl an Attributen und weitere Einträge im „Haupteintrag“ der Kamera, die wiederum eigene Attribute haben.
Hier eine kurze Erklärung einiger Attribute:
<FurnitureVisible> geht von 0 bis 4 und entscheidet über die Anzahl an Dekorationsobjekten die in der jeweiligen Kamera einsehbar sind.
<HideTunnelRoads> bestimmt, ob die Straßen, die in Tunneln geführt werden, bei dieser Kamera angezeigt werden sollen.
Die Werte unter <Bus> bestimmen ausschließlich die Icon-Größen der Bus-Icons im Spiel. Wenn ihr diese nicht gerade besonders groß oder besonders klein haben wollt, empfehle ich euch, bei allen Werten einen Mittelwert zwischen den entsprechenden Werten der vorangegangenen und der nächsten Kamera zu benutzen
Was genau alle anderen Attribute beeinflussen ist nicht klar. Es wird deswegen empfohlen, bei der Erstellung einer neuen Kamera bei diesen Attributen auf die Werte der nächstnäheren Kamera zurückzugreifen(ich rate davon ab, Mittelwerte zwischen der vorherigen und der nächsten Kamera zu machen, da dies unerwünschte Nebeneffekte mit sich bringen könnte)
3.1.1.3 Die cameralist.cfg
Die cameralist.cfg gibt dem Spiel die Ordnung der Kameras vor, wenn ihr hier also die 1st
Person-Kamera hinter die Supermappy-Kamera einfügt, dann wird, wenn aus der Supermappy-Kamera raus gezoomt wird, auch tatsächlich die 1st-Person Kamera gezeigt, da das Spiel keine Plausibilitätsprüfung macht - zurecht, da vom Spiel erwartet wird, dass ihr wisst, was ihr macht.
Die Kameraliste ist in mehrere Teile aufgeteilt, wovon im Spiel(wenn ihr keinen Freischaltmod benutzt) 3 benutzt werden: „CAMERA_GAME“, „CAMERA_EARTHVIEW“ und „CAMERA_PHOTO“
Für unseren Mod werden wir ausschließlich „CAMERA_GAME“ benutzen.
3.1.1.3 Kameras hinzufügen.
Es ist natürlich möglich, einen komplett selber geschriebenen neuen Eintrag zu machen, jedoch hat diese Methode zwei große Nachteile: sie dauert länger, und sie ist sehr viel fehleranfälliger.
Deswegen empfehle ich, die Kamera, die sich in der camera.cfg vor der Kamera, die ihr einfügen möchtet befindet auszuwählen und [Strg]+[C] zu drücken, was ihr auch gleich machen solltet.
Nun solltet ihr eine neue Zeile direkt unter der Kamera kreieren, diese rechtsklicken, und im nun erscheinenden Kontextmenü „Einfügen“ auswählen.
In diesem Leitfaden wird davon ausgegangen, dass ihr eine neue Kamera namens „STREET_NEIGHBOUR“ kreiert, und dass die Werte am Ende des Modifizierens dieser Datei zwischen denen der Kamera „STREET“ und der Kamera „NEIGHBOUR“ liegen sollen.
Die zu kopierende Kamera ist hier also „STREET“.
Wenn ihr dies getan habt, sollte unter der originalen Kamera eine weitere Kamera mit dem gleichen Namen und den gleichen Werten sein.
Um Konflikte zu vermeiden, sollten wir als erstes den Namen der neuen Kamera ändern: dies machen wir, indem wir den Namen des Opening Tag(<STREET>) und den des Closing Tag(</STREET>) ändern. In diesem Fall wird davon ausgegangen, dass der neue Opening Tag <STREET_NEIGHBOUR> und der neue Closing Tag </STREET_NEIGHBOUR> ist(Der Name ist jedoch beliebig, solange Opening Tag und Closing Tag übereinstimmen).
Nun sollten die verschiedenen Werte angepasst werden:
<Height> sollte einen Wert zwischen 150 und 200 haben(also in etwa der Mittelwert zwischen der vorherigen und der nächsten Kamera, der jedoch mehr in Richtung der vorherigen geht)
<DistanceMin> und <DistanceMax> sollten übereinstimmen und einen Wert haben, der um zirka 30% höher ist als der von <Height>
<PitchMin> und <PitchMax> sollten Werte von jeweils 0 und 89.9 haben, wodurch garantiert wird, dass der User die Kamera in alle Richtungen rotieren kann.
<Fov> sollte einen Wert von zirka 67.8 haben(also in etwa der Mittelwert zwischen der vorherigen und der nächsten Kamera, der jedoch mehr in Richtung der vorherigen geht)
Die Anderen Werte sollten alles Mittelwerte zwischen den entsprechenden Werten der vorherigen und der nächsten Kamera sein, außer natürlich die Werte die „0“ oder „1“ sind. Diese sollten immer entweder „0“ oder „1“ bleiben, also FALSE oder TRUE
Das war‟s für die camera.cfg.
Für die cameraex.cfg sollte das gleiche gemacht werden(Kamera „STREET“ kopieren und einfügen und den Namen des Opening und Closing Tag auf „STREET_NEIGHBOUR“ abändern(der Name kann auch anders sein, muss aber mit dem bereits in der camera.cfg
benutzten übereinstimmen), wobei die Attribute hier natürlich andere Namen haben(und auch Anderes bewirken)
Alle Werte der Attribute, die sich zwischen <Bus> und </Bus> befinden, sollten Mittelwerte zwischen den Werten der entsprechenden Attribute der vorherigen und der nächsten Kamera sein. Ich empfehle jedoch, keine Dezimalwerte zu benutzen, da dies meistens zu einem Absturz des Spiels führen wird.
Die Werte von <Near>, <Far>, <TopScale>, <QScale>, <EScale>, <DoTSM>, <DoPSSM>, <DoPicking>, <FakePickingDistance> und <SplitFactor> sollten denen der vorherigen Kamera entsprechen.
<FurnitureVisible> darf kein Dezimalwert sein, entscheidet euch also für eine der beiden Einstellungen(je höher, desto mehr Props werden angezeigt werden).
<FurnitureMaxViewDistance> ist die Entfernung ab der keine Props mehr angezeigt werden.
<ShowSimIcons> bestimmt ob die Gebäudesymbole angezeigt werden(Bankrottsymbol, neuer Einwohner/Arbeiter hinzugekommen und andere)
Jetzt fehlt nur noch die cameralist.cfg.
Die cameralist.cfg besteht, wie bereits erwähnt, aus verschiedenen Teilen. Wichtig sind für uns ausschließlich <Group1> und <Group2> von <CAMERA_GAME>.
Fügt nun euren Kameranamen an der richtigen Stelle ein(In unserem Fall wäre das zwischen „STREET“ und „NEIGHBOUR“. Um sicherzugehen, dass ihr ihn nicht falsch schreibt, solltet ihr ihn aus der camera.cfg oder aus der cameraex.cfg kopieren und einfügen.
Wenn ihr nun die Datei zusammenpackt und sie als .patch speichert, solltet ihr im Spiel eine weitere Kamera haben. Da es recht schwierig zu bemerken ist, ob tatsächlich eine neue Kamera da ist, könnt ihr versuchen, bei jeder einzelnen Kamera die Kamera nach oben zu rotieren-wenn es bei einer klappt, dann habt ihr erfolgreich euren ersten Mod fertiggestellt. Glückwunsch!
Achtung: Wenn ihr wirklich einen „neuen“ Kameramod machen möchtet, dann empfehle ich euch, euren Kameramod uns(ich, Oliver und Gobo77) zu geben. Wir werden ihn dann wahrscheinlich in unseren Kameramod einbauen-natürlich mit Eintrag eures Namens in den Anfangspost des Kameramod-Threads
3.1.2 Cheating
Zum Glück(oder leider) ist Cheating in Cities XL sehr einfach: es ist nicht unbedingt nötig, mehrere dutzend Dateien jeweils einzeln zu bearbeiten, nein, es reicht, in einer einzigen Datei ein paar wenige Änderungen vorzunehmen: diese Datei nennt sich „sim.cfg“ und ist faktisch eine der wichtigsten Dateien im Spiel.
Die sim.cfg
Die sim.cfg enthält mehrere Attribute, die das Verhalten des Spiels maßgeblich beeinflussen. Ich werde euch nun die am besten für Cheating benutzbaren aufzählen und erklären:
<percentjoblessmax> ist die Rate an Arbeitslosen, ab der niemand mehr der entsprechenden Bevölkerungsgruppe einzieht. Wenn ihr diese Rate auf 99% stellt, dann werden auch dann neue Bewohner einziehen, wenn fast alle Bewohner arbeitslos sind.
<forcemaxsatisfaction> bewirkt, wenn auf „1“ gesetzt, dass alle Einwohner rundum glücklich sind.
<enablebankruptcy> bewirkt, wenn auf „1“ gesetzt, dass die Firmen nicht mehr bankrott gehen können.
Das war eine kurze Übersicht über die sim.cfg. Die Attribute sind zwar eigentlich viel mehr, jedoch würde es den Rahmen sprengen, hier alle zu erklären. Außerdem sind alle Attribute in dieser Datei kommentiert(wenn auch auf Französisch), was bedeutet, dass ihr auch alleine den Sinn und die Benutzung der restlichen Attribute verstehen könnt-notfalls halt durch ausprobieren.
3.2 Die class-Dateien
Wie wir bereits gesehen haben, sind Konfigurationsdateien zweifellos der beste Einstieg ins Modding von Cities XL. Sie sind außerdem ideal zur Veränderung von globalen Variablen und zur Definierung von Konstanten. Sie sind jedoch nicht dafür geeignet, Werte einzelner Objekte zu ändern - und hier kommen Class-Dateien ins Spiel.
Class-Dateien sind, wie die Konfigurationsdateien, zwar eigentlich nur umbenannte XML-Dateien, besitzen jedoch im Gegensatz zu Konfigurationsdateien ein einheitliches Design und einheitliche Attribute, was nicht nur en Leitfaden kürzer, sondern auch die Erlernung des Dateiformats einfacher macht.
Tipp: Um die Lage aller Gebäude im Dateisystem ausfindig zu machen, empfehle ich, karel53‟s Tabelle zu benutzen. Diese ist in der „Modding“ Sektion des CXS-Forums zu finden
Eine Übersicht über die verschiedenen Attribute
Erst einmal eine Übersicht über alle Attribute:
<View>
<Panel> sollte immer BuildingSelection als Wert haben
<NameKey>, <NameKeySim>, <DescriptionKey>, <Param1Key>, <Value1Key>, <Param2Key>, <Value2Key>, <Param3Key> und <Value3Key> werden im Teil über localization-Dateien behandelt
</View>
<Display>
<Model> hat als Wert den Dateinamen des zu ladende Modells. Die Datei mit dem hier angegebenen Dateinamen wird vom Spiel im Ordner „data/gfx/building“ gesucht.
<Placeholder> hat als Wert den Dateinamen des zu ladenden Placeholders, also ein Modell was geladen wird wenn <Model> nicht gefunden wird. Der Wert von diesem Attribut sollte nicht geändert werden.
<SelectionLayer> bestimmt den Layer, der beim Auswählen des Gebäudes angezeigt wird - in diesem Fall „School_1“
<Thumb> bestimmt das Icon, was im Menü für das Objekt angezeigt wird.
Eine Datei mit dem angegebenen Dateinamen wird im Ordner data/interface/ddstexture/buildings“ gesucht, wobei die Datei im .dds oder im .tga Format vorhanden sein muss. Die Dateiendung muss mit angegeben werden.
</Display>
<Placement>
<Type> kann als Wert „BUILDING“, „PLAZA“, „ROAD“ oder „TERRAFORM“ haben und bestimmt die Weise, in der das Objekt positioniert wird
<Overpickable> sollte als Wert immer 1 haben.
<Merge> sollte als Wert immer 0 haben.
</Placement>
<Terraform>
<Enabled> bestimmt, ob das Gebäude das Gelände unter und um sich terraformen darf.
<UseDefault> sollte als Wert immer 1 haben.
<DigDepth> bestimmt die maximale Tiefe der Grube, die das Gebäude graben darf.
<LevelWidth>, <CutWidth> und <AngleMax> haben eine unbekannte Funktion.
</Terraform>
<LayerDisplay> bestimmt den Layer, der bei der Platzierung des Gebäudes angezeigt wird.
</Placement>
<EntityPosition>
<CollisionShape>
<Dimension> bestimmt die Länge und Breite des Objektes
<Height> bestimmt die Höhe des Objektes
</CollisionShape>
</EntityPosition>
<Layouts>
<LayoutFileX> bestimmt die zu ladende layout-Datei, Mehr darüber später.
</Layouts>
<Tags>Bestimmt die Tags. Je nach Tag-Auswahl wird das Objekt entsprechend im Menü positioniert.
<Entity>
<Type> kann als Wert „BUILDING“, „ROADLINE“ oder <PLAZA> haben.
<Serializable> bestimmt, ob das Objekt serialisierbar ist.
<WithOptional1> bestimmt die erste „Nebeneigenschaft“ des Objektes.
<WithOptional2> bestimmt die zweite „Nebeneigenschaft“ des Objektes
</Entity>
<JobProvider>
<MaxJobPerCulture>
<LowLife> bestimmt die Anzahl an Jobs für die unqualifizierten Arbeitskräfte
<AllAm> bestimmt die Anzahl an Jobs für die qualifizierten Arbeitskräfte
<Suit> bestimmt die Anzahl an Jobs für die Führungskräfte
<Elite> bestimmt die Anzahl an Jobs für die Spitzenkräfte
</MaxJobPerCulture>
<JobAttractivityPerCulture>
<LowLife> bestimmt die Attraktivität der Jobs für die unqualifizierten Arbeitskräfte
<AllAm> bestimmt die Attraktivität der Jobs für die qualifizierten Arbeitskräfte
<Suit> bestimmt die Attraktivität der Jobs für die Führungskräfte
<Elite> bestimmt die Attraktivität der Jobs für die Spitzenkräfte
</JobAttractivityPerCulture>
</JobProvider>
<Layer>
<ShapeX>
<LayerName> bestimmt den Namen des vom Gebäude beeinflussten Layer
<Radius> bestimmt den Radius, auf den die Änderung Einfluss nehmen sollte
<InfluenceMin> bestimmt den minimalen Einfluss des Gebäudes auf den Layer
<InfluenceMax> bestimmt den maximalen Einfluss des Gebäudes auf den Layer
<Type> bestimmt, wie der Layer sich ausbreiten soll
<GroupID> hat einen unbekannten Effekt, es ist jedoch ratsam, den Wert nicht zu verändern
</ShapeX>
</Layer>
<BudgetAgent>
<CitizenProvider> hat einen unbekannten Effekt
<MaxMonthlyCost> bestimmt die maximalen monatlichen Kosten
<UpkeepCost> bestimmt die Unterhaltungskosten des Gebäudes
<IsCityLink> bestimmt, ob das Gebäude ein CityLink ist
<IsPublicBuilding> bestimmt, ob das Gebäude ein öffentliches Gebäude ist
<BudgetExpenseCategory>bestimmt, in welche Kategorie die verursachten Kosten fallen
</BudgetAgent>
<ResourceAgent>
<MaxProduction>
<ProductionX>
<ResourceName> Name der produzierten Ressource
<ResourceNumber> bestimmt die maximale Anzahl an Ressourcen, die produziert werden können
</ProductionX>
</MaxProduction>
<MaxRequirement>
<RequirementX>
<ResourceName> Name der benötigten Ressource
<ResourceNumber> bestimmt die maximale Anzahl an Ressource, die verbraucht werden können
<RequirementX>
</MaxRequirement>
</ResourceAgent>
<Construction>
<IsDestroyable>bestimmt, ob das Gebäude zerstörbar ist
<IsZoneConstruction>bestimmt, ob das Gebäude in Zonen gebaut werden kann
<PlacementType>bestimmt, wie das Gebäude gebaut werden soll
</Construction>
<Conditions>
Wird hier nicht erklärt, da in dieser Sektion sehr viele verschiedene Attribute benutzt werden können.
</Conditions>
Hinweis: Hier wurden nicht alle Attribute eingetragen, da dies leider den Rahmen sprengen würde.
Versucht nun selber, folgendes zu tun:
1)Verringert den Effekt des Gebäudes
2)Verringert die Anzahl an eingestellten unqualifizierten Arbeitern
Die Lösung findet ihr auf der letzten Seite dieses Leitfadens.
3.2 layout-Dateien
Wir haben nun gesehen, wie sowohl globale Variablen als auch Werte einzelner Objekte geändert werden können. Es wird nun Zeit zu sehen, wie wir das Aussehen des Umfelds von Objekten ändern können.
Dies wird durch layout-Dateien gemacht. Diese Dateien sind zum Glück noch einheitlicher aufgebaut als .class Dateien.
3.2.1 Lampen neben einem Gebäude positionieren.
Wir werden nun versuchen, eine Lampe neben einem Gebäude zu positionieren, wobei in diesem Leitfaden das „Gesundheitszentrum“ benutzt wird, was die niedrigste Stufe der Gesundheitseinrichtungen darstellt.
Wie ihr vielleicht schon im Spiel bemerkt habt, hat das Gesundheitszentrum zwar einen Weg, der vom Eingang bis zur Straße führt, dieser wird jedoch nur von einer Lampe beleuchtet.
Öffnet nun die Datei „b_hea01_t1_base.layout“ im Ordner „data/design/layout/b_service“
Tipp: wenn ihr mal nicht wisst, wo ihr eine bestimme layout-Datei findet, schaut euch einfach das Attribut „<LayoutFile1>“an.
Eine layout-Datei besteht aus vielen verschiedenen <LayoutEntry> Einträgen, die jeweils ein Objekt in der Szene darstellen.
Hier ist ein kurze Übersicht über die verschiedenen Attribute, die ein solcher Eintrag üblicherweise hat:
<LayoutEntry>
<ID> bestimmt die Unique ID des Objektes. Diese ist zwar beliebig, darf jedoch mit keiner ID von einem anderen Objekt in der gleichen Datei übereinstimmen
<Type> bestimmt den Typ des Objektes. Ich empfehle, fast immer FURNITURE zu benutzen.
<PrototypeFile> ist die .class Datei, die das zu verwende Modell bestimmt
<Position> bestimmt die Position des Objektes
<Rotation> bestimmt die Rotation des Objektes
</LayoutEntry>
Um nun eine neue Straßenlampe zu erstellen, müssen wir einen neuen <LayoutEntry> erschaffen. Dies macht ihr am besten, indem ihr einen bereits bestehenden Eintrag kopiert und direkt unter dem bereits bestehenden einfügt.
Danach solltet ihr zuallererst die ID ändern.
„Type“ sollte „Furniture“ sein, und das PrototypeFile sollte das der Straßenlampe sein, also „data\design\decoration\furniture\bobo\f_bob_streetlight02.class“.
„Position“ sollte auf „-4.32560034,-12.14140034, 0.004272460006“ gesetzt werden(ihr könnt es natürlich ändern, wenn ihr eine andere Position bevorzugt).
Wenn ihr nun die Datei packt, das Spiel startet und ein neues Gesundheitszentrum baut, solltet ihr auf dem Gesundheitszentrum neben dem Weg eine Straßenlampe sehen. Glückwunsch!
.de, .fr und .en-Dateien
Diese Dateien werden auch Localization-Dateien genannt, da sie die Texte des Spiels bestimmen und es somit lokalisieren.
In Cities XL werden für alle Texte Keys benutzt, damit nicht in jeder Datei der Text in drei verschiedene Sprachen erscheint, was die Datei nur unübersichtlich machen würde.
Diese Keys sind folgendermaßen aufgebaut:
CLASS_KEYNAME_TYP
Class steht für die Klasse des Objektes, also B_(Building), R_(Road), H_(House), D_(Decoration) und LDM_(Landmark).
Keyname steht für den Keynamen, also den(verkürzten) Namen des Objektes.
Typ steht für den Typen des Textes, also _TTL(Title), _TXT(Text) und _DES(Description)
In der aufrufenden Datei muss außerdem vor dem Keynamen immer ein „&“ stehen, während in den Lokalisationsdateien „#FIELD_ID“ dem Key vorangesetzt werden muss.
Verwirrt? Hier ist ein Beispiel:
In der aufrufenden Datei:
<Title>&CLASS_KEYNAME_TTL</Title> <Text>&CLASS_KEYNAME_TXT</Text> <Description>&CLASS_KEYNAME_DES</Description>
In der Lokalisationsdatei:
#FIELD_ID CLASS_KEYNAME_TTL
Dies ist der Titel
#FIELD_ID CLASS_KEYNAME_TXT
Dies ist der Text
#FIELD_ID CLASS_KEYNAME_DES
Dies ist die Beschreibung
Lösung
Lösung der Aufgabe auf Seite 12:
1)<InfluenceMin> und <InfluenceMax> müssen verringert werden
2)<LowLife> unter <JobProvider> und <MaxJobPerCulture> muss verringert werden.
Schlusswort
Dies ist die erste Version des kurzen Leitfadens zum Modding von Cities XL, und ich hoffe, es hat euch gefallen, obwohl natürlich sicherlich noch ein paar Fehler drin sind. Mir zumindest hat es Spaß gemacht, und ich hoffe, dass das selbe für euch gilt.
Wenn ihr Verbesserungsvorschläge habt, dann zögert nicht, einen Post im entsprechendem Thread zu verfassen.
.sgbin Dateien
Sind Dateien die die Textur und höchstwarscheinlich auch das Modell der jeweiligen Gebäude bestimmen. Da die Prozesse diese zu entpacken (ist ein manueller Vorgang) und das Verändern der Texturen sehr aufwenig ist, wird auf diese hier nicht näher eingegangen. Bei besonderem Interesse, bitte einen CXL-Modder kontaktieren.
Copyright-Anmerkungen.
Dieses Werk wird euch unter folgenden Bedingungen zur Verfügung gestellt:
1) Es ist untersagt, dieses Werk ohne eine ausdrückliche schriftliche Genehmigung von Seiten des Autors zu verändern
2) Es ist nicht untersagt, dieses Werk zu vervielfältigen
3) Es ist nicht untersagt, dieses Werk oder Kopien des selben in jeglicher Form zu verbreiten.
©2010, haltendehand