missing displayName or language is missing
Prinzipiel steht es ja da, es gibt keine Namesvariable für das Fahrzeug, oder sie ist leer, das spricht für eine fehlende oder fehlerhafte String Datei.
Gibt es im Log noch weitere Details dazu (Script Fehler, oder ähnliches)?
ModManager gs file in wrong location: userdata/addons/eis_os_mod_manager_v058/
Die Datei gehört in den addons-Ordner im Hauptverzeichnis des Spiels (wenn er nicht existiert, kann er einfach erstellt werden):
Installation von Modifikationen - Cities in Motion Wiki
Wenn die Installation des MM funktioniert hat, sind auch erstmal alle Mods deaktiviert und müssen im MM Fenster aktiviert werden.
[ModManager] Hook "united_transportsystems": ERROR: Can't find if ($grid.getGridObject("mono_basic")) { in addons/tokyo/scripts/game.script
[ModManager] Hook "united_transportsystems": ERROR: Can't find if ($grid.getGridObject("trolley-04")) { in addons/stpetersburg/scripts/game.script
[ModManager] Hook "united_transportsystems": ERROR: Can't find if ($grid.getGridObject("trolley-01")) { in addons/usa/scripts/game.script[ModManager] Hook "united_transportsystems": ERROR: Can't find all if (!.visible && .type == $selectedType) $visible = false; in metro/ui/linepanel/linepanel.script
[ModManager] Hook "united_transportsystems": ERROR: Can't find all if (.type == $selectedType) { in metro/ui/linepanel/linepanel.script
Hast du irgendwelche Mods, die die hier aufgeführten Dateien betreffen ("addons/tokyo/scripts/game.script", "addons/stpetersburg/scripts/game.script", "addons/usa/scripts/game.script" und "metro/ui/linepanel/linepanel.script")?
Als ersten Schritt würde ich mal schauen, ob du diese Dateien irgendwo außerhalb der entsprechenden .gs-Dateien findest.
Was mich allerdings etwas wundert, ist die Anzahl der nicht gefundenen Textabschnitte, eine andere Erklärung als die oben genannte fällt mir aber im Moment nicht ein.
Gibt es eine Lösung?
Möglicherweise 
Dazu brauchen wir aber etwas mehr Infos, vor allem deine log_metro.txt würde uns weiter helfen.
Ein bekanntes Problem wird in den Beiträgen direkt über deinem angesprochen.
Also im Allgemeinen laufen auch ohne Mods große bis mittelgroße Karten auf den meisten Sytemen nicht mehr unbedingt flüssig, wenn man ein großes Streckennetz hat (liegt hauptsächlich am Rechenaufwand für den Prozessor).
Allerdings kann der Effekt durch Mods natürlich verstärkt werden, wobei Fahrzeug und Gebäudemods wohl eher wenig Einfluss haben.
Um zu Testen ob es an den Mods liegt (und wenn ja, ob es an einem bestimmten liegt), kannst du mit dem ModManager einfach mal alle Mods deaktivieren und dann eine neue Karte starten.
Error: File "metro/sounds/trm/Tram2_movement.wav" not found!
Da fehlt wohl der Reality Sound Mod (oder ist falsch installiert), wenn ich mich richtig erinnere sollte der die fehlende Datei beinhalten.
Ich habe einen kleinen Fehler gefunden, er wurde ausgelöst, als ich unter Info auf API geklickt habe:
Error: File "addons/eis_os_mod_manager_v058/scripts/modmanager_public_api_v1.script" not found!
Error: Runtime error in "addons/eis_os_mod_manager_v058/scripts/modmanager_win_info.script" at line 372: Internal error!
fappend($filename, "API Version "+$vers+"\n");
fappend($filename, $delim);
$lines = read_lines(MAIN.$modmanager.$dir_modmanager_scripts + $apifilename); <<<<<<<<< ERROR
foreach ($lines) {
$line = current;
if (substr($line, 0, 2) == "//") {
Der Pfad zur Datei müsste eigentlich so aussehen: "addons/eis_os_mod_manager_v058/scripts/api/modmanager_public_api_v1.script"
Ich wollte aber noch warten, ob Merk an den Spezifikationen noch was ändert oder eben nicht
Wenn nichts ungewöhnliches mehr passiert, habe ich vor die Spezifikationen nur zu erweitern und bestehende Einträge nicht mehr zu verändern.
Sobald der Blender Importer/Exporter halbwegs läuft werde ich mich mal wieder mit dem Fahrzeug Manager beschäftigen.
Zum Thema Support für fremde Mods:
Ich halte es für am sinnvollsten ein Verzeichnis zu definieren, in dem der FM nach weiteren .vehinfo-Dateien sucht und diese dann genauso nutzt wie die für die Standardfahrzeuge.
Also erstmal solltest du die Datei löschen/leeren und dann den Fehler nochmal reproduzieren.
Ich habe nämlich keine Lust mich durch 180.000 Zeilen zu lesen 
Allerdings würde mich auch mal interessieren, warum CiM bei machen Leuten das log nicht bei jedem Start leert.
Ich würde es vom Kontext abhängig machen, wenn es zum Besipiel um die S-Bahn (Fahrzeuge) einer bestimmten Stadt geht, kann man es meiner Meinung nach als Eigenname sehen und muss es daher nicht übersetzen.
Wenn es eher als allgemeine Beschreibung der Zuggattung gedacht ist, passt wahrscheinlich "suburban train" am besten.
Verstehe ich das richtig, daß du die .object und .material Dateien direkt in Blender importierst und exportierst?
Genau, da das .obj-Format nicht alle für die Animation benötigten Informationen unterstützt, hätte man entweder einen zusätzlichen Dateityp (wie die Pfad-Dateien) einführen, oder ein komplett anderes Übergangsformat nutzen müssen.
In beiden Fällen würde das aber zu großen Änderungen an den gs_tools führen, weshalb ich mich dafür entscheiden habe, gleich einen neuen Importer/Exporter für Blender zu schreiben (Ich glaube immi hat das bei seinem Versuch auch so gemacht).
Ich kanns kaum erwarten, meinen Fahrzeugen Türen zu verpassen
Du kannst ja auch mal versuchen herauszufinden, mit welchen Materialeinstellungen in Blender man die Einträge in der .material-Datei identifizieren kann, das würde den Fortschritt beschleunigen
Es gibt weitere Erfolge zu vermelden!
Ich habe es geschafft die .object, .skeleton und .animation Dateien der Tram-01 erfolgreich in Blender zu importieren und wieder zu exportieren, ohne dass die Animation verloren gegangen ist.
Außerdem ist es mir gelungen für eines meiner Fahrzeuge testweise eine einfache Türanimation (nur Translationen, keine Rotationen) zu erstellen (mit ein paar Nachbearbeitungen im Hex-Bereich).
To-Do-Liste für den Importer/Exporter:
Als Abschluss gibt es hier mal wieder alle bekannten Informationen zu den Dateien/Dateiteilen, die für die Animationen relevant sind:
.object
CHUNK_WEIGHTS =: unsigned short groupslots; // Maximale Anzahl an Vertexgruppen in denen ein Vertex enthalten sein kann, normalerweise 4
short reserved; // ungenutzt, immer 0x00
struct gsWeightData * groupslots * Numberofvertices
struct gsWeightData { // ehemals gs_vertex_extra2
unsigned short index; // Index der Vertexgruppe
short reserved; // ungenutzt, immer 0x00
float weight; // Einfluss der Vertexgruppe auf den Vertex (sollte zwischen 0.0 und 1.0 liegen), bei leeren Slots daher immer 0.0
};.skeleton
CHUNK_BONE_OBJ_REF =: char[32] object_name
struct gs_bone {
char[32] name;
uint32_t n; // index of parent bone ( -1 if none)
float pos[3] // location
float scale[3]; // naheliegende Vermutung wäre: scale (aber ungetestet)
float rot[4]; // rotation
} __attribute__((packed));.animation
FILETYPE_GS_ANIMATION =: char[32] name
UINT32 NumberOfAnimatedBones
float unbekannt // Zeit für jeden Animationsschritt in ms? Hängt mit den Einträgen für this.doorOpenStart/Len, etc. zusammen
<CHUNK_BONE_ANIMATION> * NumberOfAnimatedBones
CHUNK_BONE_ANIMATION =: char[32] name // Name des Bones für den diese Animation gilt
UINT32 NumKeyframes // Anzahl der Animationschritte für diesen Bone
<CHUNK_KEYFRAME> * NumKeyframes
CHUNK_KEYFRAME =: float Pos[3]; // location (absolut, nicht relativ zum Ausgangswert)
float u[3]; // vermutlich scale
float Quat[4]; // rotationAber höchstens ein paar Sekunden
Trotzdem haben wir beide weniger als 5 Minuten gebraucht.
Das ist das Straßenbahnnetz aus Darmstadt, hatten wir hier auch schonmal
Diese müsste der gs-Importer nun wieder zusammensetzen.
Ich denke es ist besser, einen Exporter zu schreiben, der direkt aus Blender in das CiM-Format konvertiert.
Mit einem Importer für CiM-Objekte habe ich schonmal angefangen, die meistens Sachen kann er auch schon korrekt importieren.
Bei den Animationen kann man die Werte für die Position aber wohl nicht so ohne weiteres übernehmen, da sonst z.B. die Türen bei der tram05 viel zu weit laufen:
Da das vielleicht auch anderen Leuten weiterhilft, antworte ich mal hier und nicht per PN.
Du hast einen kleinen Fehler im $coupleopt-Eintrag. Wenn der Eintrag sich auf das Fahrzeug bezieht, in dessen Script er steht, gibt es die Variable "self" um dem FM zu sagen, dass das Fahrzeug schon existiert und nicht mehr erstellt werden muss.
So sieht der eintrag im Moment aus (hier beim bus80_v2):
$coupleopt[] = map[
"id","bus80gv2",
"trailers", [["bus80gvh", false]],
"description", MAIN.$strings.$vehicle_bus80g2,
"base_vehicle", "bus80gv1"
];So sollte er aussehen, die Einträge "id" und "trailers" sind nicht nötig (und werden vom FM sowieso ignoriert, wenn "self" auf true gesetzt ist), da das Fahrzeug ja schon geladen wurde, der Eintrag "description" ist hier auch optional, da der angegebene Wert dem Standardwert entspricht (this.displayName):
$coupleopt[] = map[
"self", true,
"description", MAIN.$strings.$vehicle_bus80g2,
"base_vehicle", "bus80gv1"
];
Der Fahrzeugmanager erstellt eine eigene Liste dafür, welche Fahrzeuge im Fenster direkt angezeigt werden.
Dazu wird die ursprüngliche Liste des Spiels abgearbeitet und bei jedem dort eingetragenen Fahrzeug nach dem $coupleopt-Eintrag gesucht.
Gibt es keinen solchen Eintrag wird das Fahrzeug direkt in die FM-Liste übernommen, ansonsten werden die enthaltenen Daten ausgelesen.
Dort wird zuerst bestimmt bei welchem Fahrzeug die Variante angeziegt werden soll ("base_vehicle"), wenn es für dieses Fahrzeug schon einen Eintrag in der FM-Liste gibt, werden die weiteren Informationen dort hinzugefügt, sonst wird ein neuer Eintrag erzeugt.
Wenn sich kein Eintrag auf das Fahrzeug selbst bezieht (Eintrag "self" nicht vorhanden oder auf false gesetzt), wird für das Fahrzeug noch ein zusätzlicher Eintrag in der FM-Liste erzeugt.
Genau da lag auch das Problem mit den Busen, der FM hat den $coupleopt-Eintrag ausgelesen und das darin beschriebene Fahrzeug dem angegeben Basisfahrzeug zugewiesen.
Da der Eintrag "self" aber gefehlt hat, erzeugt der FM danach nochmal einen eigenen Eintrag für das Fahrzeug und damit auch einen eigenen Button im Kauffenster.
Allerdings werden die Varianten weiter als eigenes Fahrzeug angezeigt.
Die Fahrzeugvarianten sind also sowohl über die Liste als auch über einen eigenen Button auswählbar?
Das sollte eigentlich nicht so sein, wie du schon richtig erkannt hast widerspricht das dem ursprünglichen Ziel des FM, das Kaufmenü wieder etwas übersichtlicher zu machen.
Könntest du mir die entsprechende(n) Datei(en) mal per PN schicken, damit ich mir das genauer ansehen kann?
Im Repository ist ein kleiner Fehler, die ID des FM ist "z_vehiclemanager" und nicht "vehiclemanager" (damit er möglichst zuletzt geladen wird).
Das führt im Moment dazu, dass der MM nicht erkennt ob der FM schon installiert ist (sollte sonst aber wohl keine Auswirkungen haben).
Z-Sortierung macht immer mal wieder Probleme in CIM, in MM 0.5.4 wird es wieder ein Update deswegen geben. Wenn du auf das Element klickst, ein bringtofront() * ausführen könnte helfen.
Danke für den Hinweis, da der Fehler ziemlich willkürlich aufzutreten scheint, habe ich schon befürchtet, dass es an CiM liegt und nicht an mir , mal sehen ob ich etwas in der Richtung "bringtofront()" finde.
Allerdings verstehe ich nicht ganz, wie das Spiel die grundlegende Baumstruktur durcheinanderbringen kann. Die Droplisten sind ja Unterelemente des Kauffensters und sollten also eigentlich immer erst nach diesem gezeichnet werden, oder nicht?
Kann aber gerne den FM mit anbieten, wenn Merk das recht wäre (solange er kein eigenes Repository erstellen bzw verwalten möchte).
Ich habe zwar auf längere Sicht vor selbst ein Repository zu erstellen (wenn mal ein paar meiner Mods fertig sind ), aber im Moment können wir das gerne so machen.
Vielleicht gibt es vor Weihnachten auch noch ein größeres Update.
Im Moment habe ich ein Problem damit, dass die Droplisten manchmal nicht richtig angezeigt werden (hinter dem Kaufenster und nicht davor, wodurch man nichts mehr auswählen kann) und ich nicht wirklich weiß woran es liegt.
Das ist die Metro (oder auch Tunnelbana) Stockholm.
Es darf aber gerne auch jemand anderes ein neues Rätsel stellen.
Wieso müssen immer die gleichen ein Rätsel einstellen?
Weil immer die gleichen richtig raten.
Und die Regeln besagen, dass derjenige, der das Rätsel richtig beantwortet das nächste stellen darf.
