Beiträge von Chrizzly92

Zitat von Maerkertram

Zitat von Sean1578_99

Abgesehen davon wird das "via" kleingeschrieben nur als Hinweis.😅

Ja, aber auch Nein. Eine Standard-Hofdatei ist kompatibel möglichst allen Bussen und mit einer solchen entstand der Screenshot. Für die Standard-Busse aus Omsi werden Zieltexte als 2x16 Großbuchstaben übergeben. Im Vorbild war das 20 Jahre später beim MAN DL nicht anders.

Nun wird sowohl in Omsi als auch in der Realität interpretiert, dass in jedem Wort der erste Buchstabe groß und der Rest kleingeschrieben werden soll. Die BVG hat dann pro Wort Ausnahmen definiert, also z. B. dass das Wort "via" immer kleingeschrieben werden soll. In Omsi kann man das sowas darstellen, indem jeder Bus eine eigene Hof-Datei bekommt, was aber für unerfahrene Modder ein Hindernis darstellt.

Die Scripte im Vorbild kommen übrigens schnell an ihre Grenzen. Wie soll z. B. das Wort "AM" dargestellt werden? "Platz am Wilden Eber" und "Am Waldfriedhof" ... der MAN DL konnte nie beide gleichzeitig korrekt schildern.

Alles anzeigen

nah. das geht in OMSI auch ohne eigene Hofdateien. Man könnte - beispielsweise - auf den string " VIA " prüfen, in dem man die Zieltexte Zeichen für zeichen weiterrückt und prüft, ob die 5 zeichen " VIA " entsprechen. wenn nicht, ein zeichen weiter rücken, bis weniger als 5 zeichen übrig bleiben.
dann schneidet man den bereich aus dem String raus und fügt ihn klein wieder ein.
Genauso kann man auch Prüfen, ob z.bsp. in einem der beiden Terminus-Strings die ersten zeichen "Am " sind, dann macht man nix, wenn aber irgendwo zwischen drin " AM " auftaucht, macht man das wie oben und ersetzt es durch Kleinbuchstaben.
Im grunde ist das nichts anderes, als anstatt einer Liniennummer ein Sonderzeichen zu schildern. Wenn XYZ, ersetze mit ABC.

Als Crowbar Lösung, wenn man nicht scripten kann, kann man auch einfach ein

(L.$.Terminus_String) "AM WALDFRIEDHOF" $=
{if}
    "Am Waldfriedhof" (S.$.Terminus_String)
{endif}

Für jedes Betroffenes Ziel ins Matrix-Script des Fahrzeuges implementieren.

Edit: und bevor hier das Argument kommt "dann passiert das bei allen Hofdateien" - Nein, das kann man auch für die Berliner hofdatei(en) im speziellen abfangen, indem man via L.$.yard den Hofnamen abgleicht.
Wo ein Wille, da ein Weg.

Findest du es nicht ganz schön Frech, hier nach Support zu Fragen, ohne das Add-on gekauft zu haben? Und WENN du es dir schon besorgst ohne dafür zu zahlen, dann lad dir gefälligst eine aktuelle Version runter.

Tacketork!

Nein, eine Voith-Version ist nicht geplant. Wenn du passende Soundaufnahmen von E-Türen besorgen kannst und deren Verwendung in einem Payware-Projekt kein Problem ist, könnte man über eine Implementierung für diese Nachdenken.
Wie so oft bei solchen "Oldtimern" scheitert es fast immer an der Verfügbarkeit von Vorbildfahrzeugen.

Mach ich, Volker muss sich nur melden. Allerdings wird er nicht nach fairen Regeln spielen wollen, dementsprechend würde das scheitern, bevor man Anfängt.

Wir wissen beide, dass ich recht habe, nur mit dem Unterschied, dass ich eben nichts schönrede. Du magst es dir nicht vorstellen, aber teile der "Entwickler", völlig unabhängig vom Publisher, sind untereinander stark connected. Mit dem "Insiderwissen" ist es umso vernichtender, solche Beiträge wie die von dir zu lesen.

Zitat von Perotinus

So wurde z.B. in den drei Jahre alten Ruhr-Solaris einfach ein Ticketautomat gesetzt, womit er dann im Hochpreisaddon Düsseldorf nochmal vertickt wurde...

Absolut korrekt und genauso zu kritisieren. Nicht ohne Grund habe ich die entsprechenden Karten nie selbst gespielt und wenn mich jemand nach einer Empfehlung fragen würde, würde das o.g. Add-on keinesfalls Platz finden.

Ich bin in der Lage, sowas selbst zu reflektieren und solche Negativbeispiele sollten doch Grundlage genug sein, es eben zukünftig NICHT so zu machen.

entweder du exportierst alle modelle neu, oder du musst die materialeinstellungen (diffuse, specular etc.) per hand so einstellen, das es passt.

2.79 unterstützt von Haus aus keinen direct-X import, nur den export. Für den Import benötigst du ein drittanbieterplugin:

https://github.com/spamandeggs/directX_blender

Zitat von omsi_sw

Es ist ein Streckenaddon. Bei Eurotrucksimulatormap-DLCs erwartet auch niemand, dass automatisch ein neuer LKW mit dabei sein muss.

Ich übersetz das mal in direkte Sprache:
Man hat es verkackt, ordentliche, geeignete Modelle zu entwickeln/besorgen und hat sich auf dieser Basis für eine Shrinkflation entschieden. Weniger Inhalte für den gleichen Preis - oder kommt die Karte dann für 7,99€?

Ich quatsch mal mit Aerosoft - da knall ich ne andere Anzeige in meine DLC und re-release die einfach erneut mit bisschen Rabatt für die, die das "Original" schon haben.
If it sounds stupid but it works, it ain't stupid. hat schon die Kajot-Kiste gezeigt.

Zitat von Theproloser

Busse sind nur ZUGABE. Es geht im Endeffekt nur um die Karte. Ich Frage mich auch gerade, wo warst ihr Kritiker alle gewesen, als bei X10 noch nur die Standard M+R MAN als Ki durch die Gegend gegondelt sind, für den Zeitraum in dem die Karte gespielt hat war das aber komplett falsch und unpassend gewesen. Da hat sich niemand drüber aufgeregt.

Doch, auch damals gab es solche Kommentare. Zudem ist das Thema nicht direkt vergleichbar, weil damals der DL als neues, individuelles, noch nicht vernünftig verfügbares Fahrzeug neu zum OMSI-Pool dazu kam. Bei einem KARTENADDON, um das noch mal hervor zu heben.

thats another "issue": those settings are hidden behind the "scaleability" stuff in UE5. most games just default to e.g. (off, low, high, ultra) which is NO AA, FXAA, TAA and then the most sophisticated Methods. UE then scales effects accordingly. i think TheBus does it the same way, so you'd need to select high or ultra Anti Aliasing to "fix" this issue.

Zitat von Thomas U.

Aber dafür können die Addon-Entwickler natürlich nichts, das muss im Spiel selbst berichtigt werden. Ich glaube aber nicht dran, zieht sich diese "realistische" Grafik doch schon seit dem FernbusSim durch die TML-Spiele.

sofern TML das nicht explizit unterbindet (das ist natürlich vorstellbar) Hat der Add-on Entwickler(!) sehr wohl vollen Zugriff auf die Shadereinstellungen oder kann diese - wenn sie "vorgegeben sind" mittels Post-Processing Volumes überschreiben.
Dass Add-ons so aussehen ist also entweder Ursache einer toxischen Entwicklungsumgebung oder der Inkompetenz der Add-on Entwickler geschuldet.

Ich habe zum Beispiel das Temporal Anti-Aliasing mit meinem BusSim18 Urbino deaktiviert, damit die Ghostingeffekte nicht erzwungen werden. Das hat reihenweise die Leute abgefucked, dafür waren die Displays endlich lesbar. Das ist ja das schöne an der UE - wenn nicht explizit unterbunden, steht dir der ganze Baukasten zur Verfügung.

Zitat von LT586

I don't know wether it's me but the bus doesn't look like the graphics in these videos. It could be UE5's poor implementation of Anti Aliasing, but what recommended settings are to have it look like it did when it first launched. These are grainy and look terrible

You have to use TemporalAA, best paired with FrameGen - so you probably need to set the AA Method to "high" or "ultra" or some shit like that.
To explain this behaviour: Shaders are built in a way that the image "flickers" a pixel to the left, next frame a pixel to the right. then, both images are combined to "smear" the images togther. this will give you excellent image quality while standing still, but once there are fast movements involved, its unbearable to use TAA or similar anti aliasing methods.
Most shaders in the UE are built around TAA though, so grainyness, flickering and other issues are a normal behaviour, especially combined with badly implemented lighting solutions.
this is the biggest issue with this engine currently imho and i hate it.

Zitat von Marco Wolfgang Behrendt

Ich habe bei diesem Bus ein Problem Im Fenster zeichnet sich immer ein komisches ab Könnt ihr mir da bitte weiterhelfen Das Muster seht ihr im Bild

Das ist ein Moddingfehler. die Fenstertextur wurde ausgetauscht. Entweder prer Repaint, ggf. im Bus selbst, aber auch im Standardcontent von OMSI wäre möglich, falls der Bus darauf referenziert.

Zitat von amiachim

Mir fiel auf, daß bei dem SL Standard die Haltewunschmeldeleuchte im Dash nur dann gecancelt wird, wenn auch die Vordertür geöffnet wird. Hat das noch jemand?

MAN_SG_tuer_constfile.txt

[const]
frontdoorkillsstoprequest
0

spiel damit mal rum.

wenn die bordsteine sauber gebaut sind und aus quads bestehen, kannst du die Funktion "Follow acitve quads"benutzen.
Vorraussetzungen:
Es müssen quads sein
Die Edges müssen verbunden sein
du brauchst mindestens ein sauber gemapptes quad.

dann einfach alle selektieren, die du mappen willst, mit dem gemappten mesh als aktives mesh und follow active quads ausführen.
Aber achtung: mappingfehler addieren sich über jedes Mesh hinweg - das referenzmesh sollte also aufjedenfall ein sauberes, quadratisches mapping aufweisen.

Naja, in einem BUS-System reicht ein Master für mehrere Slavegeräte. Ich meine lt. VDV300 sind standardmäßig bis zu 32 Geräte einzeln adressierbar - wenn es um den reinen Empfang von Telegrammen geht oder custom Datensätze verwendet werden, sind sicherlich auch mehr möglich.

Es geht ja auch über das IBIS Utility, nur nicht über die OMSI Software. ich bin mir also ziemlich sicher, dass dort das Problem liegt - sei es in der Umsetzung der Telegramme oder des seriellen Interfaces. Wenns am Wandler läge, würde es ja auch mit diesem Tool nicht funktionieren.

Nö.

Grundsätzlich ist es aber so, dass manche Anzeigen toleranter als andere sind, was Datensätze betrifft, die nicht ganz der Norm entsprechen.
Bei einem DS009 kann ich meiner Innenanzeige von Lawo ALLES füttern.
Ein
"v0<CR><Prüfsumme>"
funktioniert genauso problemlos wie ein , "vXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<CR><Prüfsumme>"
obwohl DS009 lt. VDV300 exakt 16 Zeichen enthalten darf. Beide Telegramme sind also "illegal", funktionieren dennoch. Richtig wäre aussschließlich "v16C<CR><Prüfsumme>". Genauso gibts aber auch Anzeiger, die eben nicht funktionieren, wenn das Timing oder die Telegramme nicht perfekt sind.

Es wird sich um eine inkompatibilität im Tool handeln schätze ich. Um das genauer rauszufinden, müsste man nen Serial-Sniffer basteln oder nen Logic Analyzer nehmen und mal an den TX pin vom Wandler hängen, die Telegramme abfangen und dann mit denen aus dem IBIS-Utility vergleichen. Vielleicht gibts da auch software für, die das direkt am PC "abfängt".

Edit: P.S. wenn ich schon wieder sehe, wie da bauteile von der Platine abgerissen sind und das Ding einfach in der Luft baumelt, wundert es mich, dass dir die Bude noch nicht abgefackelt ist.

du wirst ggf. in den Einstellungen von OMSI die Objektkomplexität angepasst haben - aktiv oder ausversehen. Die Objekte waren schon immer da, nur bei dir wurden sie aufgrund der Einstellungen nicht angezeigt.

schick mal die *.x Datei rüber. entweder stimmt der scale nicht oder die Materialeinstellungen werden falsch gesetzt.

Zitat von Lazarus

Mich hätten die anderen Add-Ons durchaus mal interessiert, wo ähnliche Situationen bemängelt worden sind.

S315NF display bug, wenn man zu schnell den Motor startet - zum beispiel.

Jo, ich spiels dann halt nicht. Thema erledigt. Bei anderen Add-ons werden ähnliche Situationen als massiver Bug deklariert aber mir soll es letztendlich egal sein. Schade drum, aber nach der Diskussion ist auch einfach die Luft fürs Add-on raus.

die variablen gibst du auch durch die drehgestelle durch?
wenn du das "Kabel" unterbrichst, dann kommt das Signal ja gar nicht an.