= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Bei dieser Ticketbox: ist das so, dass man die Elektronik anmacht und diese direkt hochgefahren ist.
...was völlig unrealistisch ist. 
Ein Rechner braucht nun mal Zeit zum Hochfahren. Und da das hier ein Supportthread ist, für Fehler und Probleme, gebe ich da keine Anleitung für.
Einfach gesagt: ja.
Du kannst aber sog. animparent-Einträge unter die ganzen o3d-Datei setzen und das erste Objekt mit einem mesh_ident-Eintrag versehen. Somit bedarf es nur einem Eintrag der Daueranimation beim Mutterobjekt (mesh_ident). Die Tochterobjekte (animparent) orientieren sich dann daran.
In Notepad kannst du das mit Suchen&Ersetzen ganz einfach verwirklichen. Am besten kopierst du dir alle Einträge des EvendPC's mal in eine extra Textdatei.
Dann drückst du Strg+H und trägst folgendes ein:
Suchen nach: .o3d
Ersetzen durch: .o3d\n\n[animparent]\nEvendPC
Bitte Suchmodus beachten und entsprechend auswählen!
Und beim allerersten Objekt ersetzt du dann (manuell) das "animparent" mit "mesh_ident". Fertig. Dann kanst du die Einträge wieder in deine Modell-Datei packen.
Eine Runde Schnellbus mit dem SchnellBus.
Setra S 319 NF · Ruhrau
Hmm... sicher, dass du auch diese Hofdatei verwendest? Ein Blick in die "normale" Hamburger-Hofdatei verrät folgendes:
Da sind beim Altonaer-Ziel Tabstopps. Diese wertet OMSI anscheinend als normales Zeichen. Da dies aber in der Font-Datei (*.oft) nicht definiert sind, wird eben das erste Zeichen aus dieser Datei als Ersatz angezeigt. Und das ist bei dieser Matrixschrift das große "A".
Warum ich nun frage, ob du auch wirklich diese Hof-Datei nutzt? Nun, die "HamburgLi20_TFC Linienpack.hof" hat das bei mehreren Zielen, u.a. Rathausmarkt, Reeperbahn, Bardowick, Alsterdorf. Die originale Hofdatei hat das nur bei Altona.
indem sie aufgehen und direkt wieder zu und wieder auf.
Klingt so, als würde der Türtaster dauerhaft gedrückt gehalten werden.
Wenn man das ne ganze Weile macht, ist der Vorrat der Druckluft schneller aufgebraucht, als diese nachgespeist werden kann.
Hast du evtl. irgendwelche Bedienteile an deinem Computer angeschlossen - außer Tastatur & Maus?
Das Wort -> Boundingbox <- verweist bereits auf einen Artikel. Da kann man sich das gerne durchlesen und ändern. Ist nicht schwer. Dennoch ist es kein Fehler und wird vom Entwickler auch nicht geändert. Diese Diskussion gab es nämlich bereits:
Erzi schrieb am 11.12.2024 (Beitrag #1.844):
[...] Weil was bringt es, wenn ich die Boundingbox 2 Zentimeter anhebe und nach einen Update wieder Beschwerden kommen, dass es immer noch Kracht.
Ich von meiner Seite habe jedenfalls zum Betatest meistens OMSI in Verbindung mit BBS, dem zufolge auch mit eingeschalteten Kollisionen, auf vielen verschiedenen Karten gespielt und konnte in dieser Zeit keine Kollisionen mit Haltestellen oder Bodenwellen feststellen.
Ich bin den MAN letztens auch erst eine Runde gefahren und ja, man dötzt an wenigen Bordsteinen an, was mit anderen Bussen nicht passiert. Wenn man seinen Fahrstil entsprechend anpasst, läuft die restliche Tour ohne Probleme.
Ich hab's oben erklärt, welche Möglichkeiten es gibt.
Du kannst den newanim-Eintrag entsprechend abändern, sodass OMSI den Rotationspunkt an eine feste Stelle setzt. Das kannst du dir in Blender auch ganz einfach anzeigen lassen - Klick an die Stelle und rechts im Flyout (Taste N) stehen die Werte bei "3D Cursor".
Zwecks den Türtastern, das ist ein wenig umfangreicher.
Zusammengefasst:
Du musst die Taster in Blender erstmal gerade machen. Was ich damit meine:
So sieht das aus, wenn du den Taster importierst:
Und so sollte es dann aussehen:
oder
oder
oder ...
Am einfachsten geht das, wenn du den Drehpunkt in die Mitte verlagerst:
Strg+Shift+Alt+C => Origin to Geometry
Dann merkst du dir (oder schreibst dir das auf) die Werte bei Rotation im rechten Flyout:
Dann appliest du das (Strg+A => Rotation oder Leertaste => "Apply Rotation")...
...und trägst die Werte wieder ein, nur umgekehrt (plus wird zu minus und minus wird zu plus):
Dann kannst du den Taster wieder exportieren und er wird sich richtig bewegen.
Naja... die Fahrertür rotiert sich.
Vielleicht ist es so verständlicher:
Links der Originalzustand, rechts der Zustand nach dem exportieren.
Der rote Punkt ist der Objektursprung. Rechts ist der bei 0/0/0.
Wenn es sich um eine einfache Bewegung entlang der x-/y-/z-Achse handelt, dann spielt natürlich der Objektursprung keine Rolle... dann sollte die Animation aber weiterhin funktionieren.
Um welches Objekt und welche Bewegung geht es denn genau?
Das betrifft sicherlich eine Rotation, oder?
Dafür bedarf es einen Rotationspunkt. Dieser kann auf 2 Art & Weisen festgelegt werden:
Festgelegte Koordinaten werden in der Modell-Datei direkt beim Animationseintrag angegeben:
Es kann aber auch hingegen ein/der Ursprungspunkt aus Blender genutzt werden:
Dieser wird leider automatisch - wenn du das Objekt in Blender importierst - immer an die Koordinate 0/0/0 gelegt. Du musst den also händisch wieder an die richtige Stelle setzen. Schwierig (aber nicht unmöglich) wird es dann, wenn sich die Rotationsachse nicht in 0° oder 90° befindet.
Nein, dieses kleine scharze Ding hat das nicht zu verantworten. Hier siehst du den Wagenkasten und das orangene ist die definierte Boundingbox:
Was genau meinst du damit? Es wurde schon mal erklärt, dass der NLC gegenüber anderen Bussen einfach niedriger gebaut ist. Die Boundingbox hatte ich mir von diversen Varianten angeschaut - die passt perfekt.
Ja wie gesagt, das "Backface Culling" hat keinerlei Auswirkung auf den Export.
Was war denn das Problem, wenn du den Haken bei X-File: z up weglässt? Das Objekt war überbelichtet oder...?
Guckst du hier:
Ein Blick in die bus-Datei verrät, es werden passengercabin_C2_E6_Gelenk_UE_main.cfg und passengercabin_C2_E6_Gelenk_UE_trail.cfg genutzt.
Und der Ersteller hat das sogar wunderschön unterteilt...
...sodass man alle Einträge darunter entfernen kann.
Eine Fläche (Plane) ist immer nur von einer Seite sichtbar. Sowohl in Blender, als auch in OMSI.
In Blender ist das aber standardmäßig so, dass du die Plane's von beiden Seiten zu 100% siehst. Mit der Backface-Option wird das umgangen und richtig dargestellt.
Für den Export spielt das übrigens keine Rolle. Das ist nur für Blender eine Hilfestellung, um Objekte richtig in OMSI einzubinden.
Wenn du N drückst, öffnest sich rechts ein Flyout:
Die sind nicht zur Hälfte unsichtbar, sondern die einzelnen Flächen sind nur jeweils gedreht und somit von der falschen Seite sichtbar.
Deine Frage hat keinen wirklichen Zusammenhang. "Fontdateien" - also die Fonts selber - befinden sich im gleichnamigen Ordner. Die definieren jedes einzelne Zeichen und sind nicht fest für einen Bus definiert. Das ist wie ein Buffet, da kann sich jedes Fahrzeug bedienen, sofern vorhanden.
Wenn es speziell um eine Matrix geht, dann ist im Matrixscript selbst (*.osc) die Font definiert, welche verwendet werden soll.
Normalerweise brauchst du also nur diese Einträge ändern. Die stehen normalerweise ganz simpel in Anführungszeichen dort irgendwo drin. Das bereits geschriebene Script bastelt sich daraus dann den Rest.
Natürlich sollte man darauf achten, dass die Schriftgröße gleich bleibt. Eine 16px Anzeige kann zwar auch 26px Schriften anzeigen, jedoch unvollständig.
Wenn du sowas vor hast, musst du die Matrixobjekte (*.o3d) mit tauschen.
Den V1.4 hab ich sogar getrennt vom v2 soundpack
In wie fern getrennt? Getrennte Ordner? Die ganzen Facelift-Busse liegen alle im gleichen Ordner MB_O530_Facelift. Wenn du den Ordner umbenennst, musst du dies auch in der AI-Liste korrigieren.
179 06:44:49 - - Error: The file "" could not be loaded!
180 06:44:49 - - Error: The file "" could not be loaded!
181 06:44:49 - - Warning: Invalid Object: "
182 06:44:49 - - Error: You want to create vehicle - it is invalid!
[...]
[...]
185 06:44:49 - - Error: You want to create vehicle - it is invalid!Und generell würde ich mal deine AI-Liste überprüfen. Da scheinen sich ein paar Leerzeilen eingeschlichen zu haben.