darf ich denn mal fragen, wie man dies wieder aktiviert?
Klar. So muss das dann aussehen (also ohne <!-- vorne und --> hinten
<objectChange node="r_arm" rotationActive="0 0 0" rotationInactive="-80 0 0"/>
<objectChange node="l_arm" rotationActive="0 0 0" rotationInactive="-80 0 0"/>
Und wie gesagt: für "r_arm" und "l_arm" musst Du entweder die nodes der vorderen Unterlenker eintragen oder ein entsprechendes i3d-Mapping ergänzen.
Hast Du mal versucht, den auskommentierten Code:
<!-- <objectChange node="r_arm" rotationActive="0 0 0" rotationInactive="-80 0 0"/>
<objectChange node="l_arm" rotationActive="0 0 0" rotationInactive="-80 0 0"/> -->
wieder zu aktivieren? Der sorgt ja eigentlich für die Klappung, ist aber aktuell inaktiv.
Ansonsten sind vielleicht irgendwelche nodes falsch, so dass die rotation woanders sucht. Dazu braucht man aber das Modell.
Die nodes r_arm und l_arm brauchen dann aber ein id3-Mapping oder Du musst die nodes direkt hinschreiben.
Moin, ohne die .xml wird das nix mit der Fehlersuche. Sind die baseMaterials richtig definiert? Sind die richtigen Shaders (Ls19 oder LS17support) vorhanden? Wurden überhaupt in Blender oder Maya die entsprechenden ColorMats zugewiesen?
Das wird ganz bestimmt an einer falschen gewichts verteilung liegen. diese musst du anpassen damit er sich besser verhält.
Nicht ganz auszuschließen, aber ich habe inzwischen Schlüter aus jedem LS konvertiert. Probleme mit der Gewichtsverteilung habe ich dabei noch nicht gehabt.
Wie Hoffi bereits geschrieben hat, sucht das Spiel die Textur für den Steuerknopf im Ordner "Downloads" und nicht im mods-Ordner. Du hast den Steuerknopf offenbar nicht richtig in den mod eingebaut oder den Pfad im mod nicht richtig hinterlegt. Also mod entpacken, Steuerknopf importieren und Pfad überpüfen. Wenn der Steuerknopf im mod korrekt importiert und in der richtigen TG sitzt, genügt es, den Pfad anzupassen. Dazu die i3d mit einem Editor öffnen und den Pfad überschreiben. Der muss auf die Texturdatei in dem mod verweisen.
Leider kann man auf den Bildern nicht sehen, ob beim Einschlagen die Felgen noch zentriert an der Nabe sitzen. So wie es hier aussieht, sitzen die Räder an der falschen Node, nämlich an einer, die beim Einlenken außermittig "rutscht".
Meinst Du den Import des Modells selbst oder den Import in die Map? In der Map hilft es, die Straße ein bisschen höher zu legen.
Moin, ich habe mir das Teil mal angeschaut und muss Dir leider sagen, dass das ein bisschen mehr Arbeit ist.
Zunächst mal hat sich meine erste Vermutung mit den collies bestätigt. Wenn Du das Rigid Body bei "quadtrac_crawler_component3/4/5/6" rausnimmst, bleiben die crawlers schon mal dran. Dann erst sieht man, dass die vorderen Crawler an der falschen node hängen, weil sie nicht einlenken. Die Maschine fährt natürlich trotzdem eine Kurve. Da Du die Crawler in das Modell importiert hast, werden sie immer mit geladen und sind damit sichtbar; auch wenn Du wheels konfigurierst. Das ist so sicher nicht gewünscht. Das Hauptproblem ist aber, wie schon zweitens vermutet, dass Du in der .xml i3d-Mappings hast, die nicht zum Modell passen. Das führt z.B. dazu, dass die hinteren tracks nicht richtig auf den Laufrollen sitzen. Da musst Du mal die Einträge vorn und hinten vergleichen. Da ich den Teilespender nicht habe, konnte ich das nicht checken. Sollte sich aber auch ohne finden lassen. Ich habe auch Indices gefunden, die sich links auf "crawlers" und rechts auf "wheels" beziehen. Das muss identisch sein.
Ich hoffe, dass ich mit diesen Ansatzpunkten ein Stück weiterhelfen konnte.
Ohne den mod zu haben (dies ist keine verkappte Anfrage, sondern die Feststellung einer Tatsache 
) kann man hier keine Ursachenforschung betreiben. Was man in der .xml sieht ist extrem komplex. Neben den ganzen configs hast Du auch jede Menge objectChanges verbaut, was Probleme verursachen kann. Dann sieht man bei den wheels
"repr="frontDumperLeftVis" driveNode="frontWheelJointLeft"", während bei den crawlers folgendes steht:
repr="crawlerFrontLeft" driveNode="wheelTracFrontLeft". Das muss aber auf den Trecker bezogen sein und kann nicht differieren.
Gemäß i3d-Mapping verweist frontDumperLeftVis auf den Index node="0>0|0|0|0|0|0", die crawlerFrontLeft" aber auf node="0>0|0|3|2|0. Das kann nicht funktionieren.
Warum bei den crawlers jeweils 2 Einträge für alle vier Anbaupunkte existieren, erschließt sich mir aus der Ferne auch nicht.
Außerdem hast Du bei den Crawlers in den dazugehörigen objectChanges die Bezüge der wheels noch drin.
Bei den speedRotatingParts hast Du Indices direkt eingetragen. Die kann man ohne die i3d natürlich gar nicht aus der Ferne prüfen.
Schau Dir mal an, wie viele unterschiedliche Einträge mit Bezug auf wheels Du in den i3d-Mappings hast. Da ist einiges bei dem ganzen copy and paste durcheinander geraten.
Du hast in der .log stehen: "Invalid wheel index '5' for speedRotatingPart 'vehicle.speedRotatingParts.speedRotatingPart(2) ..." Das sieht mir nach Indexsalat aus. Wahrscheinlich sind durch die Spenderteile die Indices durcheinander geraten, weil nicht genau identisch. Da würde ich alles einmal durchgehen und vergleichen, also .i3d vs. .xml.
Wegen des Runterfallens war ich gedanklich bei den collies. Vielleicht liegt es aber eben auch daran, dass keine Andockstelle gefunden wird, weil die i3d-Mappings nicht mehr passen oder Indices fehlen. Wenn man Teile importiert passiert das sehr schnell. Man sieht ja auch die Tracks neben den Laufrollen, d.h. die wissen offenbar gar nicht, wo sie sind.
Also wenn ich mir das Foto so anschaue, dann sehe ich nur 2 Möglichkeiten: Irgendeine colli, die dazwischenfunkt oder aber eine falsche node, an die die Tracks so chaotisch anzudocken versuchen. Beides habe ich auch schon oft fabriziert. 
Hast Du collies in den Tracks? Dann werden sie "abgestoßen". Wenn man fremde Teile in einen Mod integriert, müssen die Collies der importierten Teile raus.
Der Hash ist der Primärschlüssel zum Vergleichen, ob zwei mods identisch sind. Der Hash ändert sich z.B. beim zippen. Wenn Du also den fraglichen mod neu gepackt hast oder zum Bearbeiten ent- und wiede neu ge-packt hast, dann hast Du einen neuen Hash und die mods sind nicht mehr identisch für das Spiel. Ihr müsst Eure .zip-mods entweder austauschen oder alle an der gleichen Stelle herunterladen und nicht mehr verändern.
Richtig. Einfach mit einem Editor öffnen und ändern in 53. Da passiert nichts. Müsst Ihr natürlich alle gleich haben. Vielleicht habt Ihr unterschiedliche Versionen des LS und es funktioniert deshalb bei den anderen auch noch in der alten Version.
Na Du hattest doch nach der modDesc Version gefragt. 😉
Die 53 sollte funktionieren. Da Du scheinbar über Steam spielst, ist dort natürlich auch immer eine potenzielle Fehlerquelle. Da bin ich leider raus, aber ich erinnere mich rudimentär an Beiträge, wonach es Probleme mit Steam in Hintergrund und mit der Speichersynchronisation (an/aus) oder auch mit dem Cloudspeicher gab. Vielleicht kann da jemand ansetzen oder Du und Deine Freunde vergleichen mal ihre diesbezüglichen Einstellungen.
Noch 2 Ideen: Sind die mods vielleicht neu dazugekommen und beim Spielstart noch nicht ausgewählt/aktiviert? Ist die modDesc Version aktuell?
Ah. Etwas anderer Name. Dann findet man es mit Strg-F natürlich nicht. Im .zip-Format sind die mods aber, oder?
In der log findet sich von den beiden mods gar keine Spur. Hast Du sicher die gleichen Speicherorte für alle Deine mods?
Stimmt, aber solche mods würden auch im Single Player nicht geladen werden. Welche mods werden denn als nicht geladen angezeigt? In der log steht davon nichts.
