Modifizierbarkeit von CiM2

    Damit da keiner auf falsche Gedanken kommt hab ich die Daten entfernt.


    Zurzeit schreibe ich die Dateiroutinen auch jedes mal in den Versionen um. Nächster Bug den ich entfernt habe, BundleCodec dachte das Array Char Strings null terminiert waren, dem ist aber eigentlich nicht so.


    Mittlerweile fügt es zu den Bin Daten auch die Internen Namen (m_Name bzw. m_Id falls vorhanden) in den Dateinamen.
    Leider ist es immer noch sehr unübersichtlich. Als nächstes stehen externe Namen für die Format Tabellen an und externe Tabellen für die assets Dateien.


    Das Text Format ist eigentlich Geschichte, theoretisch schreibt BundleCodec nun fast valides JSON, werde dieses wohl bald auf ein valides JSON Format umstellen. Wobei dann Hex Werte in Strings konvertiert werden müssen. Für fast alle Sprachen gibt es ja JSON Pakete bzw. man kann auch Parser selber schreiben. Muss dann noch die Offsets als Kommentare hinzufügen. Es es jedenfalls in C viel einfacher VAR* vname = var_get_child(vparent, "m_Name"); zu schreiben als jedes mal eine Switch Anweisung zu bauen. Natürlich braucht BundleCodec etwas mehr Speicher und Zeit aber es ist einfacher.


    BundleCodec Export funktioniert nun etwa so: Konvertiere die Header Daten in das interne VAR Format, schreibe Sie in JSON, dann die Typen Daten.
    Extrahiere jeden Datei Eintrag in einen Buffer, schreibe die Bin Datei, konvertiere den Buffer mit Hilfe einer Formattabelle in mein internes VAR Format. Für Textur und Audio schaue in die VAR Daten und extrahiere die Daten, füge einen Verweis hinein.


    Vorteil der ganzen Sache soll sein, egal welche Unity Version genutzt wird, sollten die Daten immer wieder in ein Bundle konvertierbar sein. Es ist auch unerheblich ob ein Objekt erweitert wird. Nachteil ist, man brauch für jeden Typen den man extrahieren möchte in das JSON Format eine passende Format Tabelle, ohne Sie bekommt man nur die Bin Daten. Die kann man ggf. mit nem Hex Editor basteln.



    Importieren soll dann so funktionieren:
    JSON lesen wenn vorhanden, sonst bin Datei. JSON zu VAR, Konverter sieht eine zusätzliche Datei in den VAR Daten, als Beispiel DDS Datei wird geladen, VAR Daten angepasst und zurück geschrieben, VAR wird zu BIN mithilfe der Format Tabelle, Bin Datei wird in das Bundle verpackt.

    Zitat von eis_os

    Damit da keiner auf falsche Gedanken kommt hab ich die Daten entfernt.


    uhm, häh? Falsche Gedanken wie etwa dein Tool tatsächlich zu benutzten? :X Kommt der Download irgendwann wieder?
    ich hoffe dass heißt nicht, dass bei du bei jeder Stimmungsschwankung dein Tool vom Netz nimmst?
    dann schreib ich lieber mein eigenes Tool.


    Zitat von eis_os


    BundleCodec Export funktioniert nun etwa so: Konvertiere die Header Daten in das interne VAR Format, schreibe Sie in JSON, dann die Typen Daten.
    Extrahiere jeden Datei Eintrag in einen Buffer, schreibe die Bin Datei, konvertiere den Buffer mit Hilfe einer Formattabelle in mein internes VAR Format. Für Textur und Audio schaue in die VAR Daten und extrahiere die Daten, füge einen Verweis hinein.


    hört sich gut an. Für die Meshdaten reicht die BinDatei auch völlig aus. Abgesehen von Debugzwecken ist die Textdarstellung für Meshes relativ sinnfrei. Keiner wird seine Modelle im Texteditor basteln ;)
    Die Version des bundlecodecs die ich habe, schreibt nur den reinen Vertex Daten buffer als externen "blob", die restlichen Angaben gab es als Text, drum hatte ich die bisher nicht als grundlage für den Blender import genommen.

    Von meiner Seite eher nicht, wenn ich mich mit CIM2 befasse, Spiele ich gerade die Kampagne, keine Ahnung wie es andere machen aber bis jetzt dauert der Aufbau eines gewissen Kapitalpolsters immer Ewig auch auf schnellsten Spielmodus, Resultat keine Zeit an BundleCodec zu arbeiten ;(

    ich hänge grad im neuen Crusader Kings Erweiterungspack fest :)


    ich werd zwar weiter an den bundles puzzeln, wenn ich in der Stimmung dazu bin, aber es hat im Moment definitiv keine Priorität für mich.
    Angesichts der prinzipiellen Unfreundlichkeit des Formats gegenüber UserContent kann man durchaus die Sinnhaftigkeit der investierten Zeit in Frage stellen, wie eis_os weiter oben schonmal angedeutet hat.


    *shrug* vielleicht sollte man doch nochmal zu CiM1 zurückkehren und sehen ob da nicht noch ein paar coole Sachen möglich sind

    Der Quellcode von CIM1 wäre schön um es zu erweitern :D


    Die Abhängigkeiten der Sehenswürdigkeiten:
    x12.svg


    Hier kann man vielleicht den Aufbau besser erblicken: (Negative IDs sind "eigene" Objekte von CIM2)
    0xFFFFFFFB Definiert dieses "CIM2 BundlePaket" es beinhaltete DataStores ->
    0xFFFFFFFF Datastore ->
    0xFFFFFFFE CIM2 Objekt Container (DLC ID, Strassenanbindung, LODs) ->
    [Lod Daten], 0xFFFFFFFD Generated Data, GameObject


    0xFFFFFFFD Generated Data = Kollisionsdaten (automatisch erstellt durch CIM2 Build Scripts?)
    GameObject -> MeshRenderer, MeshFilter, Transform


    Transform
    MeshFilter -> Mesh
    MeshRenderer -> Material


    Material ->
    Texture2D, Texture2D, Texture2D (Textur, NormalMap...)


    Die LOD Varianten sind direkte Verbindungen zu einem Mesh per LOD und einem Material per LOD.
    Hierbei ist zu beachten das CIM2 scheinbar ein eigenes LOD Management benutzt, da die Verbindung von einer CIM2 eigener Klasse zu den LOD Daten geht.
    Ich vermute daher das die LOD Daten eine Art Aufsatz von CO sind. Ich kenne mich aber mit Unity3D nicht aus um da näheres zu sagen. Vielleicht werden die LOD Daten sogar beim bauen des Projekts automatisch durch ein Editor Script im Unity 3D Editor erstellt.


    PS: Dabei ist das noch nicht alles es gibt da noch die MenuDaten und MonoScript Referenzen die meistens einfach auf die Assembly-CSharp Verweisen (Das eigentliche Spiel im .Net Assembly, wird durch den Player (CIM2.exe) geladen)

    Wo eigentlich gibt es ein Sydney-Opernhaus? Etwa nur in der Datei, um sie später auch mal freikaufen zu können? Oder auch das burj-al-arab? Dann wird wohl das alles codiert sein.... :pinch:
    Beim Modding sollte man wohl doch auf CIM1 zurückkehren. Vielleicht kann man da auch noch einen Sonnenuntergang und Nachthimmel reinscripten...

    Zitat von ArkenbergeJoe

    Genau so sehe ich es auch. Und deswegen ist es gar nicht gewollt, das darin herumgescriptet wird. Also AUS für Modding !! :sure:


    machen wir uns doch nix vor. jegliches Game und jegliches DLC landet irgendwo frei verfügbar im Netz. Und jeder der google bedienen kann, wird das auch in irgendeinem Piratengewässer finden. Ob Modding möglich ist oder nicht, ist da völlig belanglos.

    Also die DLC Daten sind ja alle auf der Platte, die BundleDaten zu ändern ist zwar naheliegender aber das eigentliche Spiel zu modifizieren wäre der einfachere Weg.
    Natürlich möchte ich bei der ersten Variante nicht direkt Vorschub leisten. (Da BundleCodec die Offsets ausgeben kann, wäre das mit einem Hexeditor schnell bewerkstelligt)

    Zitat von mediziner

    Ich hoffe, ich motiviere euch ein wenig, wenn ich mal zeige, was theoretisch bereits geht. Fahren wir also mal mit Werbung herum


    praktisch scheints ja auch zu funktionieren :). theoretisch geht noch viel mehr :p


    ich nehm aber mal an, dass du nur die Textur eines existierenden Fahrzeuges übermalt hast ?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden