Beiträge von IREgio612

Hast du auch den Zahlenwert unter dem Wort [stringvarlist] angepasst?

100 18:59:37 -  -     Warning:       Spline type "Splines\ADDON_Berlin_Spandau_M&Z\Zane\gw_heerstr.sli" could not be loaded!
101 18:59:37 -  -     Warning:       Spline type "Splines\ADDON_Berlin_Spandau_M&Z\Zane\radweg_heerstr.sli" could not be loaded!

111 18:59:39 -  -     Warning:       Spline type "Splines\ADDON_Berlin_Spandau_M&Z\Zane\str_2spur_12m_SeeburgerWeg1.sli" could not be loaded!

127 18:59:40 -  -     Warning:       Spline type "Splines\ADDON_Berlin_Spandau_M&Z\Zane\str_2spur_6m_Leubnitzer.sli" could not be loaded!
128 18:59:40 -  -     Warning:       Spline type "Splines\ADDON_Berlin_Spandau_M&Z\Zane\str_2spur_9m_Reclamweg1.sli" could not be loaded!
129 18:59:40 -  -     Warning:       Spline type "Splines\ADDON_Berlin_Spandau_M&Z\Zane\str_2spur_12m_Sandstr.sli" could not be loaded!

Dir fehlen mehrere Splines aus diesem Pack:

Bitte nochmal installieren...

Du trägst jeweils an letzter Stelle (unter dem 0.04) eine bmp-Textur ein, welche sich im Texture-Ordner des Fahrzeugs befindet. Diese beinhaltet in weißer Farbe den Lichtschein. Beispiel:

Ich kann es nur nachsimulieren. Und bei einigen Bussen stimmt zudem die Skalierung der Frontanzeige nicht ganz (s. Bild) und selbst da passt es rein.

Dann einfach den Melden-Button (nutzen und dein Anliegen dort reinschreiben.

Der Button ganz links

Wohlgemerkt ist das immer noch das der falsche Bereich. Aber lass das doch die Sorge von der Moderation bzw. den Admins sein. Die verschieben den dann schon an die richtige Stelle.

Zitat von Senator B

In eine solche Lawo-LED mit 16px Höhe würde so ein Ziel in Realität m. E. gar nicht passen.

Geht alles

Hier leider nur der Ausschnitt aus dem Zielverzeichnis

Suchmodus nicht richtig ausgewählt

Ich hab das extra mit erwähnt + Bild. Das ist die Auswahl unten von "Normal" zu "Erweitert".

Zitat von Lorenzowds2006

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.

Zitat von B3R71N K1Dz

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:

[newanim]
origin_rot // origin_trans
x
y
z
...

Es kann aber auch hingegen ein/der Ursprungspunkt aus Blender genutzt werden:

[newanim]
origin_from_mesh
...

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...?