Modifizierbarkeit von CiM2

immi

Zitat von eis_os

Ein Problem liegt in den Flags, wir wissen nicht was man als Flags wirklich nutzen muss, CO bestimmt auch nicht und die Unity Entwickler werden es uns bestimmt nicht sagen.

da wir aber keine neuen Strukturen erschaffen wollen, brauchen wir ja einfach nur die Definitionen übernehmen, die in den uns vorliegenden Bundles genutzt wird. samt flags.
und wenn CO was an den Daten ändert, braucht das Programm halt ein Update

Zitat von eis_os

-edit-
Die Schablonen müssen ja nicht geändert werden, sie dienen nur dem BundleCodec ein valides CIM2 Objekt zu kreieren. Trenne reine Daten und Struktur ...

ja gut, würde ja reichen wenn man die Struktur in irgendner Headerdatei hinterlegt. Zumindest für CiM2
aber wenn du einen generischen AssetBundle Packer schreiben willst, dann macht ist das mit den externen Definitionen schon irgendwo Sinn.

eis_os

Ein Bundle kann man scheinbar zu einem Assets Datei "konvertieren" wenn man die Bundle Daten bis zu AssetBundleInfo entfernt, dann kann binary2text aus Unity auch Informationen zu einem Bundle ausgeben.

Als Ergebnis für X01:

Spoiler anzeigen

Code

External References
path(1): "customassetbundle-gameshared" GUID: 00000000000000000000000000000000 Type: 0
path(2): "customassetbundle-globalshared" GUID: 00000000000000000000000000000000 Type: 0
path(3): "library/unity default resources" GUID: 0000000000000000e000000000000000 Type: 0




ID: -2120305263 (ClassID: 1) GameObject
	m_Component  (vector)
		size 1 (SInt32)
		data  (pair)
			first 4 (SInt32)
			second (file 0 path 1141001652) (PPtr<Component>)


	m_Layer 12 (UInt32)
	m_Name "door-bone02" (string)
	m_Tag 0 (UInt16)
	m_IsActive 0 (UInt8)

Alles anzeigen

Spoiler anzeigen

Code

ID: 1 (ClassID: 142)     0: AssetBundle [size: 93, children: 6 pathID: 1]
    1: 	m_Name "" (string)
    5: 	m_PreloadTable  (vector) [size: 12, children: 1]
    7: 		size 3316 (SInt32)
		data (file 3 path 6) (PPtr<Object>)


---- snip ----

		data (file 0 path -1072017998) (PPtr<Object>)
		data (file 0 path 298665249) (PPtr<Object>)


   11: 	m_Container  (map) [size: 25, children: 1]
   13: 		size 154 (SInt32)
		data  (pair) [size: 21, children: 2]
   15: 			first "broken smoke" (string)
   19: 			second  (AssetInfo) [size: 16, children: 3]
   20: 				preloadIndex 1013 (int)
   21: 				preloadSize 9 (int)
   22: 				asset (file 1 path 445868571) (PPtr<Object>)
		data  (pair) [size: 21, children: 2]
   15: 			first "building-interior-large-windows 1" (string)
   19: 			second  (AssetInfo) [size: 16, children: 3]
   20: 				preloadIndex 3266 (int)
   21: 				preloadSize 1 (int)
   22: 				asset (file 1 path -717083797) (PPtr<Object>)
		data  (pair) [size: 21, children: 2]
   15: 			first "bus" (string)
   19: 			second  (AssetInfo) [size: 16, children: 3]
   20: 				preloadIndex 866 (int)
   21: 				preloadSize 104 (int)
   22: 				asset (file 1 path -702316403) (PPtr<Object>)
		data  (pair) [size: 21, children: 2]
   15: 			first "bus 04" (string)
   19: 			second  (AssetInfo) [size: 16, children: 3]
   20: 				preloadIndex 2946 (int)
   21: 				preloadSize 138 (int)
   22: 				asset (file 0 path -1047677433) (PPtr<Object>)
		data  (pair) [size: 21, children: 2]

Alles anzeigen

Die External References scheinen bis jetzt wohl irgendwo untergehen...

ArkenbergeJoe

Zitat von eis_os

.....
PS: Du sollst nicht an den Daten herum basteln, Du kannst die Bundles sowieso nicht verteilen, außerdem sind diese viel zu groß. Für Stats soll es ja einen Aufsatz von CO geben. Mir geht es primär darum neue Objekte zu erstellen.

Doch, wenn ich reinkomme, schaue ich mir die Strukturen an. Programmierung der Tools überlasse ich euch, aber beim Erstellen von Objekten sollte ich schon wissen, was da rein darf oder nicht. In welchem Format diese gespeichert werden müssen, welche Texturbeziehungen es gibt, usw. Bundles verteile ich eh nicht, mache ich nur für mich....

Zitat

Da grade die Hex-IDs erwähnt wurden, das ist auch noch ne Untersuchung
wert: Müssen die programmweit eindeutig sein? oder (hoffentlich) nur
innerhalb des Bundle? Da in den Assetverweise immer extra angezeigt wird
wenn es sich um externe Verweise handelt, hoff ich mal auf letzteres.

Wäre nicht schön, wurde aber damals schon bei SimCity4 gelöst. Es gibt bekanntlich beim NAM nur ein einziges Team. Eben wegen der eindeutigen Hex-ID's.

eis_os

Das müsste theoretisch die externen Referenzen Darstellen: Bei GUIDs wird bei Unity scheinbar das obere Nibble mit dem Unteren getauscht, keine Ahnung warum.
Kommt direkt hinter AssetIndexTable

Code

#define struct_bundle_AssetExternalReferenceEntry(_) \
	_(field)(filepos, _filepos) \
	_(field)(u8, unknown) \
	_(array)(u8, GUID, 16) \
	_(field)(u32, type) \
	_(field)(string, name)
STRUCT_DEFINE(bundle_AssetExternalReferenceEntry, struct_bundle_AssetExternalReferenceEntry)

#define struct_AssetExternalReferenceTable(_) \
	_(field)(u32, num_entries) \
	_(hidden)(struct bundle_AssetExternalReferenceEntry* children)
STRUCT_DEFINE(bundle_AssetExternalReferenceTable, struct_AssetExternalReferenceTable)

Alles anzeigen

Die zur zeitige BundleCodec Version hat einen Fehler, beim Versuch eines schon existierenden Verzeichnis einen neuen Namen zu finden gibt es eine Endlosschleife...

immi

Zitat von eis_os

Ein Bundle kann man scheinbar zu einem Assets Datei "konvertieren" wenn man die Bundle Daten bis zu AssetBundleInfo entfernt, dann kann binary2text aus Unity auch Informationen zu einem Bundle ausgeben.
[...]
Das müsste theoretisch die externen Referenzen Darstellen: [...]

oha, netter Fund :). hat mich schon irre gemacht wie zum geier die externen FileIDs aufgelöst werden :p

bin auch einen (kleinen) Schritt weiter: die reinen Vertexdaten zu importieren funktioniert, aber das ist ja auch der einfach Teil

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

//edit
Klamann
uh, bicubic interpolation - damit kann ich so gar nicht dienen
was die SRTM Daten angeht, hilft das hier vielleicht weiter: Digital Elevation Data - with SRTM voids filled using accurate topographic mapping
Da steht jedenfalls das dort die Lücken im ursprünglichen Datensatz mit anderen Methoden gefüllt worden sind.

**mediziner**

Sabber :dribble:
Ich kanns kaum erwarten mit euren Tools zu spielen!

eis_os

Nunja, die Vertex Daten hatte ich ja schon. Bis jetzt konnte ich zeitlich nicht viel weiterarbeiten, die erste Größenangabe in AsstetBundle macht noch sorgen da Sie mitten in AssetExternalReferenceEntry zeigt und das unbestimmt irgendwo hin. Auch immer anders in verschiedenen Dateien.

Assets Dateien haben keine ObjektInfo Daten, das extrahiert meine Version jetzt erst einmal als bin Dateien. Aber durch die Unity Hilfe konnte ich BundleCodec beibringen welche IDs zu welcher Art von Objekt führt ohne auf die Objekt Struktur zu setzen. Die YAML Ids sind die selben wie in den Assets.

Soviel von meiner Seite, der Code ist noch sehr Work in Progress.

immi

step2

Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

sieht man hier nicht, weil sich der Fehler einfach über "Recalculate Normals" beheben lässt, aber irgendwo läuft noch was verkehrt mit den Normalvektoren, die kommen teilw. verkehrt an. oder da sind nen paar Dreiecke falsch gewickelt, hmm ... //fixed
und wenn ich die UnitySnippets von eis_os von weiter oben richtig deute, sind im rest der daten irgendwelche tangenten. google führt mich da zu "tangent space normal mapping". muss mich da erstmal belesen, wie das im Detail funktioniert und wie ich sowas aus Blender rauskriege. google spuckt dazu erstmal jede Menge Hinweise darauf aus, dass Blender diese Tangenten _nicht_ exportieren kann ...

eis_os

Hmm, schreibst Du jetzt deine eigenes Tool von Grund auf und kann ich BundleCodec in die Tonne werfen, wäre schade um den Parser...

-edit-
Hab mal ne neue Bundlecodec Version hoch geladen, die zeigen soll wohin die Reisen eigentlich gehen sollte. Erstellen funktioniert noch nicht, da nicht alle Daten eingelesen werden und die nötigen Kalkulationen gemacht werden.

Source Daten kompilieren mit: C99, -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -U__STRICT_ANSI__ per mingw gcc

immi

ist immer noch mein python script. nur dass ichs jetzt innerhalb von Blender starte und weiterhin nur die Richtung bundle Datein in Einzelteile zu zerlegen + import des Modells in Blender.

immi

Zitat von eis_os

Bis jetzt konnte ich zeitlich nicht viel weiterarbeiten, die erste Größenangabe in AsstetBundle macht noch sorgen da Sie mitten in AssetExternalReferenceEntry zeigt und das unbestimmt irgendwo hin. Auch immer anders in verschiedenen Dateien.

Ja, diese eine Angabe ist echt rätselhaft. Hab da auch gerade ne ganze Weile dran rumgepuzzelt ohne irgendne Erleuchtung zu erlangen ...

eis_os

Mein BundleCodec baut gerade die X01 Datei wieder zusammen aus den json Daten und den bin-Dateien.
Die BundleData Bereich nutzt scheinbar eine Ausrichtung auf 8. (quad word) Ohne eine Ausrichtung gab es einen massiven Binär unterschied, jetzt ist es nicht mehr so schlimm.
D.h. der Dateikopf scheint für die X01 Bundle noch falsch, aber die restlichen Daten stehen wieder an der richtigen Stelle.

-edit-

size0 könnte das hier sein:
b_AssetHeaderInfo->size0 = posData-b_AssetHeaderInfo->formatTable->_filepos;

Oder in Worten: Size0 in AssetBundleInfo ist gleich Position der AssetBundleData minus Position der AssetFormatTable, bzw. Einfach die Position der Nutzdaten.

-edit2-
So, die UI.bundle hat einen kaputten Header, die size0 Angabe stimmt für Roads.bundle nicht wegen ein paar bytes
Bei Editor.bundle bekomme ich auch kein binär identisches Ergebnis

-edit3-
Habe den Quellcode hochgeladen, wer es selber kompilieren möchte...

Unkown

Wenn das dann funktioniert? Wäre es dann vieleicht möglich die Fahrzeuge aus dem Ersten Teil inden Zweiten zu übertragen? (import/export)(1:1)
Ich vermisse doch ein paar... vorallem das im zweiten so überhaupt keine Historischen-fahrzeuge vorhanden sind.

[Post verschoben in DLC WÜnsche]
mediziner: Sorry.

**mediziner**

Ich muss leider ermahnen etwas mehr beim Thema zu bleiben! Bitte hier keine Fahrzeugwünsche etc.

Eine 1:1 Konvertierung wird nicht möglich sein, da u.a. zusätzliche Texturen benötigt werden. Auch ist zu bedenken, daß die Fahrzeuge aus dem ersten Teil nicht konvertiert angeboten werden können. Allerdings dürfte eine Konvertierung mit (teilweise aufwändiger) zusätzlicher Handarbeit von CiM2 -> CiM1 in nicht allzu fernen Zukunft möglich werden. Aber auch hier wird es keine konvertierten Modelle als Mod geben.

In beide Richtungen könnten allerdings Modder die Modelle nachbauen. Ich vermute das es (sofern möglich) zuerst existierende Mods für CiM1 in CiM2 schaffen werden.

ArkenbergeJoe

Dass es nicht 1:1 geht, hatte ich bereits erwartet. Daher behalte ich ja auch alle Roh-Dateien (Kraftwerk in Blender).
Eine Konvertierung von CIM1-Objekten aus dem Spiel ist allerdings rechtlich nicht erlaubt. Also wird das repaintete rosa/grüne Eckhaus nicht dabei sein.

**mediziner**

Hier ein aktuelles Statement zum Thema Modding aus dem Originalforum

Zitat von co_martsu

Hi ***,
Unfortunately we don't have the opportunity to start working on a tool to import objects to the game at the moment.
Cities in Motion 1 was built with our in-house engine, which was easy for modders to customize. We changed to Unity for the multiplayer support and better performances for CIM2. The situation changed for modding so that we would have to develop a separate tool for importing objects. We've made all the modding tools that are possible at the moment (map and scenario editors and rule set) and hope you enjoy those!
I'm looking forward to seeing mods for Cities in Motion 2 like there were for the first one!

Im naher Zukunft wird also nicht an Convertierungstools gearbeitet. Sie müssten aufgrund der Unity-Engine ein eigenes Tool entwickeln. Aber er freut sich trotzdem auf Mods wie im ersten Teil.
Etwas widersprüchlich :bubblegum:

Link zum Originalthread: http://forum.paradoxplaza.com/forum/showthre…=1#post15513511

eis_os

Nunja, mein letzter Stand ist, ich bekomme die DDS Tetxuren exportiert, die ARGB und RGBA Daten sind einfach falsch, einmal gespiegelt und dann stimmt die Kanäle nicht, versuche ich die Kanäle anders im DDS Header zu definieren bekommt Paint.net Probleme, es scheint nur ARGB zu verstehen, keine sonder Formate, NVidia Textur Viewer verdaut es, trotzdem falsche Farben und falsche Transparenz Da ich seit 3 Wochen kein CIM2 mehr gestartet habe, frag ich mich langsam ob der Aufwand gerechtfertigt ist. Da Mediziner ja die Raw Daten die meine BundleCodec Dev Version konvertieren konnte, frag ich mich wo das Problem liegt

rovapasi

eis_os - Auf jeden Fall gebührt Dir unser aller Dank für die großartige Arbeit. Ohne Dich gäbe es nicht mal die Hoffnung, dass sich an der Situation rund um Mods was ändert.

eis_os

Immi ist ja auch noch da...

**mediziner**

Zitat von eis_os

Da Mediziner ja die Raw Daten die meine BundleCodec Dev Version konvertieren konnte, frag ich mich wo das Problem liegt

Falschfarben beruht auf Falscher Byte-Reihenfolge bzw. auch auf falscher Kompressionseinstellungen im Header. Hatte ich auch mächtig mit zu kämpfen. Die Bilder müssen auf dem Kopf stehen.
Ist scheinbar so gewollt, aus welchem Grund auch immer.
DDS-Header

Code

typedef struct {
  DWORD           dwSize;
  DWORD           dwFlags;
  DWORD           dwHeight;
  DWORD           dwWidth;
  DWORD           dwPitchOrLinearSize;
  DWORD           dwDepth;
  DWORD           dwMipMapCount;
  DWORD           dwReserved1[11];
  DDS_PIXELFORMAT ddspf;
  DWORD           dwCaps;
  DWORD           dwCaps2;
  DWORD           dwCaps3;
  DWORD           dwCaps4;
  DWORD           dwReserved2;
} DDS_HEADER;

Alles anzeigen

Jetzt mitmachen!