= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! GIF geht nicht, nein.
night-texturen funktionieren ähnlich dem Prinzip von Bamp. du nimmst dafür einfach die variable "licht1" und fügst folgenden Eintrag in die Model.cfg unter dem [mesh] eintrag deines Modells ein:
[matl_change]
Dein_Texturname.jpg
0
light1
[matl_item]
[matl_nightmap]
Dein_Texturname_leuchtend.jpgbesitzt dein Modell nun mehrere Texturen, fügst du den o.g. Code nochmals ein und änderst entsprechend die namen der Textur und der Leuchttextur.
Ich muss aber auch sagen, dass The Bus schon eine gute Tiefe hat, mittlerweile. Klar, nicht vergleichbar mit OMSI. Aber das ist auch teilweise der Engine geschuldet, denn einen eigenen Bus (samt allen Details) ist nunmal in der Unreal schon komplex...aber gewisse Punkte wie Sound dürften auch nochmals ein Stück besser sein...
Ich hab das nie gelernt und bin mir zu 100% sicher, dass meine, in 2 Stunden zusammengeklöppelte Gelenkbusphysik, qualitativ die von TML bei weitem übersteigt.
Die Busphysik in OMSI ist zudem auch eingekauft (Open Dynamics) und ist quasi eine simple Line-Trace Physik, bei der - quasi - ein "Strahl" an jedem Rad vom oberen Punkt der Aufhängung nach unten geschossen wird. Bei diesem Strahl wird die Entfernung gemessen, bis dieser ein Objekt/Spline/was auch immer mit Kollision trifft. Ist dieser Wert größer als das soll, wird das Fahrzeug abgesenkt, ist es kleiner als der Sollwert, wird es angehoben. Das führt auch zu dem "aufschaukeln" bei niedrigen Framerates, weil die Intervalle der Berechnung immer länger und damit ungenauer werden. Das ist übrigens auch der Weg, den Nvidia's PhysX geht und so auch nativ in der UE umsetzbar ist.
Ich bin es leid, dass hier immer das Argument "Unreal Engine" vorgeschoben wird. Aber muss ja unrealistisch sein, weil sie ja schon "unreal" im Namen hat. 
Eine OMSI-like Physik ist in der UE innerhalb weniger Stunden umgesetzt. Das könnte jeder Dulli sogar in Blueprint mit ein wenig Youtube Tutorial und Recherche, wer C++ beherrscht braucht eventuell ein paar Stunden länger, aber es ist auch dort zügig Umsetzbar.
Natürlich muss man, wenn die physikalische Grundlage steht, hier noch die Fahrzeuglogik (korrekt!) Scripten. Da scheitert es schlicht an Fachwissen und Interesse, nicht daran, das TML das nicht könnte. Die OMSI Physik wäre ohne die Pionierarbeit von Marcel und Rüdiger, die Getriebe und Motor in vielen Details umgesetzt haben, auch nicht so gut, wie sie von uns Empfunden wird.
Es ist aber einfacher, das UE Wheeled-Vehicle Template zu nehmen, was man vermutlich schon seit dem Fernbus mitschleppt, auf C++-Ebene halbherzig anzupassen und dann nie wieder anzufassen.
Eine Gewisse Spieltiefe bringt das Spiel mit, keine Frage - aber wenn es "Der BUS" heißt, und das Hauptaugenmerk des Spieles nicht überzeugt, wird hier am Thema Vorbei entwickelt und/oder der falsche Begriff für das Spiel verwendet.
soweit ich weiß hat Chrizzly eig ein update mit dieser variante geplant nur halt ist besagtes update nie gekommen.
So stimmt das nicht ganz. ich hatte mal in einer Nacht- und Nebelaktion das Außenmesh zusammengefriemelt, ja. Es wäre grundsätzlich auch schnell gemacht, das ganze als Update oder eigenes DLC zu veröffentlichen. Um meinem eigenen Qualitätsstandard zu entsprechen, würde das aber auch einen Rework der Stadtbusfamilie selbst bedeuten und zudem fehlen mir wichtige Referenzen, was den restlichen Aufbau angeht. abgesehen von der Fensterkante sind nämlich auch Innenraum, z.T. Podeste und Fahrerkanzel, womöglich Türen und weitere Dinge unterschiedlich. So einfach ist es also nicht, das ganze mal eben in einer vernünftigen Simulationstiefe und ordentlich aussehend umzusetzen.
Als Zusammenfassung für das Thema des Threads habe ich eine übersichtliche Liste aller Busse erstellt, die (meiner Meinung nach) noch für OMSI 2 als AddOns wünschenswert wären (in der linken Spalte die Modelle, in der rechten ggf. die Varianten):
um SL202, SG2x2, SÜ242 und eventuell SM1x2 kümmere ich mich aktuell.
Lebt das Projekt noch?
Eventuell sollte man dort noch nen kleinen Hinweis Verankern, wie sich die Achsenrotationen in OMSI Verhalten, um das Objekt entsprechend zu drehen.
Es wird ja standardmäßig über die x-Achse rotiert, dreht man den Ursprung mittels origin_rot_z um 90°, also quasi um die Hochachse um 90° gedreht, wird das Objekt dann beispielsweise Standardmäßig über die längsachse animiert. Bei Daueranimationen vorallem in Verwendung mit anim_trans relevant, damit man es, je nach originaler Objektausrichtung, auch in die richtige Richtung verschiebt.
Hab jetzt nicht in den Animationen-Eintrag geschaut ob dazu schon ein Hinweis existiert, aber im Rahmen der Daueranimationen sollte das meiner Meinung nach erwähnt werden.
entpacke mal den Inhalt von diesem Archiv in dein OMSI 2/Scripts/ Ordner und ersetze die dort vorhandenen Dateien.
Wenn dieses Problem global auftritt, wurden die AI-Car-Scripts modifiziert. das archiv enthält die originale aus der Vanilla OMSI Installation.
Wenn du z.B. nur zwei Optionen hast, kannst du die Zahl 3 auch einfach durch 2 ersetzen. Dann wird entsprechend so gezählt: 0, 1, 0, 1,...
Das geht noch kürzer - ! invertiert ja grundsätzlich, d.h. ein Trigger mit dem Inhalt
(L.L.Deine_Variable) ! (S.L.Deine_Variable) wechselt immer zwischen 0 und 1, weil der Wert jeweils invertiert wird.
on OMSI her auch nicht.
das stimmt so nur bedingt. Zumindest der Standard X zu o3d Converter heult rum, wenn die Datei zu groß wird. Das lässt sich nur mit 3rd-party Exportern umgehen. 
Bus: MAN SL2x2 (W.I.P)
Karte: Grundorf
Wenn erstes: Das ist nur ein Displaying-Fehler.
Ne, das ist ein Mappingfehler. der Alpha-Bereich hin zur Scheibe ist zu knapp gewählt bzw. die Faces bis zum Rand der Textur gemappt.
erstell doch mal nen testscript mit
"String123" (S.$.Dest1)
"String123" (S.$.Dest2)
"String123" (S.$.Dest3) etc.
und PRÜFE, ob das funktioniert.
Wenn man etwas debuggen will und hilfe im Forum suchst, solltest du das auch schrittweise sinnvoll durchführen, und nicht davon ausgehen dass es funktioniert, nur weil eine beschreibbare variante funktioniert.
Also Grundsätzlich finde ich die Art des Scriptens suboptimal (Textfelder einfach mehrfach überschreiben, wenn ein vorheriges Ergebnis nicht (mehr) valide ist) aber grundsätzlich kann ich da jetzt rein vom syntax nichts kritisches erkennen. Was sagt das Logfile? Hast du wirklich alle Textfelder mal geprüft, ob sie sich per Script beschreiben lassen? Ist der Font in Ordnung?
Maßgeblich für die Ladezeit beim Starten sind die Internettexturen und die Fonts. viele Fonts -> lange Ladezeiten. viele *.itx - lange Ladezeiten.
Hallo zusammen,
ist in nächster Zeit noch ein Bugfix für den mitgelieferten MAN geplant? Einige Bugs, die ich vor sehr langer Zeit schonmal gemeldet habe, sind leider immer noch vorhanden. Die Räder werden im Display bei aktiver Feststellbremse nicht ausgemalt und man kann Gänge einlegen, ohne die Bremse zu betätigen.
Ich hab das Fahrzeug zwar in OMSI importiert und gescriptet, Bugfixes wird es von meiner Seite aus unterschiedlichen Gründen allerdings nicht geben. Eventuell findet sich ja jemand im Hause Halycon, der sich dem Ding nochmal annimmt.
KI-generierte Welt klingt zwar interessant, aber die KI, die mir auf Mausklick die Linie 1234 von Hohenwulsch nach Hintertupfingen nachbaut, möchte ich erstmal sehen. Für Fantasiekarten wäre das vielleicht denkbar, aber hier liegt doch auch der Reiz beim kreativen Bauen.
als vollständigen Ersatz in einer Simulation ist das natürlich nicht zu gebrauchen, aber um beispielsweise plausible Vegetation zu generieren, schon eher. Ich sehe das realistischerweise bei Sachen wie einem Fluss, der entsprechend ordentlich begrünt wird, als "Lückenfüller" für Seitenstraßen und so weiter. Das würde in der Entwicklung so einiges erleichtern.
Tatsächlich kam ein Update, welches aber NICHTMEHR von Janine gepostet wurde, sondern von Marcel selbst. Janine hat seit Anfang des Jahres keine Beiträge mehr gepostet.
Diese Tatsache ist aber grundsätzlich als Vorteil zu Werten, auch wenn der Zug für LOTUS mMn. abgefahren ist (haha) - Viele Leute haben ja kein Problem mit LOTUS oder Marcel, sondern mit Janine - und das wegbleiben dieser kann für die Community nur Vorteilhaft sein.
Alles anzeigenNaja an sich kannst du Sounds schon repaintabhängig machen. Bedarf nur einen kleinen Umweg.
Du musst in der cti-Datei einen neuen setvar-Eintrag reinschreiben, der einen Wert enthält - bspw.:
Und dann musst du herausfinden, wo der entsprechende Soundtrigger steht; also in welchem Script. Türsounds finden sich in der Regel im Türscript.
Wenn du den Trigger gefunden hast, musst du diesen nur noch in eine Bedingung schreiben:
Code: NACHHER(L.L.tuersound) 0 = {if} (T.L.Mein_Soundtrigger) {else} (L.L.tuersound) 1 = {if} (T.L.Mein_Soundtrigger_2) {endif} {endif}Das kann natürlich auch beliebig erweitert werden.
geht sogar noch leichter - dem Soundtrigger in der Sound.cfg duplizieren, einen [conditionsingle]-tag hinzufügen und so einfach mit der Variable steuern, welcher Soundtrigger jeweils ausgelöst wird.
Bus: MAN SG 2x2 (Privat)
Map: Grundorf
4-stellige Linien werden von diesem Fahrzeug nicht unterstützt.
ent-BVG-isiert.
Frech!
