Beiträge von Chrizzly92

das ist einfach kacke programmiert. wirkt so, als wäre das irgendwie "zusammengepfuscht".

nehmen wir die scriptzeile mal stück für stück außeinander:

(L.L.Route) (M.V.GetRouteIndex) 0 "" "DEBUG" (M.V.GetRouteBusstopIdent) 0 (M.V.GetTTBusstopName) $= &&

Das Macro (M.V.GetRouteBusstopIdent) erwartet den aktuellen Routenindex und die aktuelle Haltestelle. Hier wird aus (L.L.Route) die aktuelle Route im Drucker ausgelesen, damit wird aus der Hofdatei der Routenindex geholt, 0 ist dann die 0. Haltestelle, also die erste in der aktuellen Route.

dannach wird aus dem aktuell aktivem Fahrplan die nullte Haltestelle geholt.
Im Stringstack steht jetzt quasi "", "DEBUG", Das Ergebnis von GetRouteBusstopIdent und von GetTTBusstopName. Mit $= werden die obersten beiden Stackwerte verglichen. Im Stringstack steht dannach noch "" und "DEBUG" drin, wobei "" keinen Inhalt besitzt und ignoriert werden kann. die Zeile oben kann man also mMn. folgendermaßen einkürzen:

(L.L.Route) (M.V.GetRouteIndex) 0 (M.V.GetRouteBusstopIdent) 0 (M.V.GetTTBusstopName) $= &&

Jetzt kann es natürlich sein, dass weiter unten im Script Debug nochmal zur Verwendung kommt, ohne mir das aber im großen ganzen anzusehen macht das auf den ersten Blick keinen Sinn.

die beiden "" setzen einfach "keine Zeichen" in den Stringstack. Das wurde bestimmt gemacht, weil irgendwo weiter unten "Reststrings" mit $+ Verbunden wurden und dann irgendwelche komischen Stringkombinationen aufgetaucht sind.
"ABC" "DEF" $+ ergibt dann einen String "ABCDEF"; "" "DEF" $+ ergibt halt "DEF". Anstatt hier also die Logik anzupassen, scheint man einfach leerstrings in den Stack geschoben zu haben um Programmierfehler weiter unten im Script auszubügeln.

Ein Vergleich mit dem String "DEBUG" kann auch noch aus der Entwicklung stammen. man könnte so halt auch einen festen String mit z.bsp. der Hofdatei abgleichen.

"Debug" 0 (M.V.GetTTBusstopName) $=
wäre Beispielsweise True, wenn die erste Haltestelle im Fahrplan "Debug" heißt.
Genau kann ich dir hier nicht helfen, ich hab das Add-on nicht. Grundsätzlich handelt es sich hier aber nicht um OMSI-Spezialfunktionen oder so. Entweder schlecht gescriptet oder man muss sich mal das gesamtscript genauer anschauen.

Ja in die Nightly hab ich nur kurz reingeschaut. Ich hatte aufjedenfall so um die 10 FPS mehr in allen Situationen, genauer hab ich das aber noch nicht analysiert gehabt. Aber wäre auch schlimm, wenns bei angekündigten Verbesserungen eben diese nicht gäbe. Was mir aber aufviel war, dass trotz besseren Nutzung der Hardware keine Lineare Leistungsverbesserung warzunehmen war. Bei einem Sprung von 60% Auslastung auf 100% Auslastung erwarte ich auch 40% mehr Dampf, vorallem wenn sonst keine Features oder Effekte hinzukommen.

Edit: Linear ist natürlich bisschen übetrieben, aber ein paar Frames mehr ist nun auch kein Weltensprung.

Die GPU-Auslastung steigt im Beta-Branch tatsächlich an, auch die Performance ist besser. das hab ich so aber auch geschrieben.

"mit der aktuellsten Nightly-Build gab es tatsächlich optimierungen, die zu einer besseren Performance führen. Dafür ist aber auch die Prozessor- und Grafikkartenauslastung gestiegen. Das ist nen Schritt in die Richtige Richtung, aber immernoch nicht ausreichend."

Du hast vermutlich mit dem Nightly-Build getestet. Die Screenshots oben sind allerdings mit der aktuellen "offiziellen" Version entstanden.

Ich habe mich bewusst für eine reproduzierbare Situation entschieden. Ich bin um 12 Uhr mit einer GT6N beim EInstiegspunkt Bopser gestartet. die Kamera zeigt immer nach vorn, so hat man halt auch immer den identischen vergleich. Natürlich spawnen nicht alle Leute oder Autos gleich, darauf hab ich aber keinen EInfluss.

die Texturen laden zumindest auf meiner Maschine im Stand nur sehr langsam nach. z.T. musste ich über 60 Sekunden warten, bis LOTUS das Dashboard scharf dargestellt hat.

Zitat von hans-johnson

LOTUS is a simulator for the future, I believe that when it is finished (maybe in 100 years), all computers can run it smoothly. 8)

Well, many maps are not very lag, but the problem of unstable FPS is more serious.

nope. the game doesnt behave like crytek games - it wont scale in a linear fashion with increased computing power. at least not yet. You cant run omsi with 200 frames either, even though the hardware is way faster compared to its release year.

Zitat von Lµkas

Das kann ja durchaus gewollt sein. Wenn genug Speicher da ist, kann man beispielsweise noch länger Objekte im Speicher halten, an denen man zB schon vorbeigefahren ist oder weiter vorladen. Bei größeren Karten würde dann der Speicher schneller geleert.

richtig. Was da ist, soll auch vollumfänglich genutzt werden können.

Zitat von Jamonalk

Muss noch einige Fotos aus dem Performance Fenster machen und werde dann noch Mal ne Feedbackmeldung den beiden geben. Im Vergleich zu den meisten anderen Rechnern die da so mit LOTUS kämpfen ist meiner eher schwach von daher dürfte auch der sehr relevant sein.

Das ist Schlussendlich auch nur Hilfreich um zu erkennen, was auf den verschiedenen Systemen zum Flaschenhals führt. Das reduzieren oder ändern der Einstellungen ist im Endeffekt nur ein Workaround um das Hauptproblem - LOTUS selbst ist der Flaschenhals. Solang die Hardware nicht zu 100% ausgelastet wird, Ist der Spielcode selbst nunmal der limitierende Faktor.
Ab einem bestimmten Punkt bringt halt ne schnellere Grafikkarte oder ein besserer Prozessor nichts mehr. Man sollte erwarten können, dass die Hardware auf dem letzten Loch pfeift, das tut sie aber nicht. Es muss sich also keiner die Frage stellen, ob der PC denn genug Leistung hat - denn schnellere Rechner erreichen ebenfalls keine besseren Framerates.

Bei allen Einstellungen auf maximum (Tu es nicht!!!) erreiche ich Mittags, 12 Uhr, mit einem GT6N auf Diorama, EInstiegspunkt Bopser, ca. 40 FPS. Schwankt natürlich zwischen 35 und 45. Prozessorauslastung bei 35%, Grafikkartenauslastung bei 60% - das ganze auf der aktuellsten LOTUS-Version mit aktivem "Performanceverbesserungen".

Nun habe ich reduziert auf beste Grafik:

Nun auf Ausgeglichen:

Nun auf erste Effekte:

und nun auf beste Performance:

Was fällt auf?

Die Prozessorauslastung bleibt, abgesehen von leichten Schwankungen über alle Grafikeinstellungen hinweg, identisch.

Die Framerate bleibt - abgesehen von leichten Schwankungen über alle Grafikeinstellungen hinweg, identisch. Beim Schritt zu "erste Effekte" fällt die Framerate um ein paar Frames, das sind dann wohl die angesprochenen 15%, die die Schatten an Leistung benötigen. DIe Auslastung des Prozessors bleibt dabei gleich, die Auslastung der Grafikkarte bleibt gleich, die Framerate fällt!

Lediglich die Grafikkarte hat etwas mehr zu tun, wenn man die Einstellungen hochschraubt. Aber auch hier sind wir weit von der maximalen Auslastung weg.

Die Grafikeinstellungen haben also nur bedingt Einfluss auf die Performance, den meisten Unterschied machen hier die Schatten. Alles andere ist vernachlässigbar, wenn die Hardware gut ist. (1070ti, i7 8700k). Reduzieren kann Sinn machen, wenn die Hardware tatsächlich langsamer ist als der LOTUS-Kern könnte - für alle anderen macht es absolut keinen Unterschied. Und das oben ist schon der best case, auf Workshopkarten siehts dann noch schlimmer aus.

mit der aktuellsten Nightly-Build gab es tatsächlich optimierungen, die zu einer besseren Performance führen. Dafür ist aber auch die Prozessor- und Grafikkartenauslastung gestiegen. Das ist nen Schritt in die Richtige Richtung, aber immernoch nicht ausreichend.

De facto limitiert hier der LOTUS kern, egal was ich einstelle. Ich erreiche mit minimalsten Einstellungen nur ein paar Frames mehr als mit maximalen Einstellungen.

Zitat von Jamonalk

Finde trotzdem gut dass sie es jetzt im Angriff nehmen weil 40 FPs währen so must have. Alles darüber ist Nice to have. Aber nicht notwendig. Und diese aber stabil ohne Drops nach unten.

Im Hinblick auf VR ist das kein must have, das ist lächerlich. Stabile und vorallem ruhige 60 FPS ist das minimum, was man als Titel, der VR-möglichkeiten bewirbt, für die breite Masse bringen muss. In Kombination mit der Bewegungsinterpolation kommt man so auf 120 FPS aufm VR-Headset, was ich als dauerhaft spielbar bezeichnen würde, wenngleich das keine optimale Lösung ist. besser wären natürlich echte 90 FPS oder noch besser 120FPS, aber das halte ich für absolut unrealistisch, wenn man sich den aktuellen Stand anschaut.

Jede Performanceverbesserung ist natürlich ne feine Sache, nichtdestotrotz ist das bisher nichts weiter als ein Tropfen auf den heißen Stein.

wenn diese Variable nicht schon in einer Varlist stünde, würde OMSI eine Fehlermeldung auswerfen. Das ist aber nicht der Fall. die CTI lässt sich regulär nutzen wie jede andere auch.

bau dir doch zwei fahrzeugvarianten - eines, das du als KI einsetzt und eins, was du zum selbstfahren nutzt. aus der KI-Variante entfernst du dann die spiegel. dann kannst du das fahrzeug zwar nichtmehr übernehmen, an- und ausschalten von spiegeln je nachdem wo du sitzt ist aber nicht möglich.

Warum überhaupt solche Vorgaben machen? Einfach alle möglichen Settings Stück für Stück in einen Grafikreiter a la "Erweitert" überführen und die Community selbst damit rumspielen lassen. Casuals können dann immernoch Presets wählen, alle anderen haben dann zumindest die Möglichkeit, sachen wie TAA unabhängig anderer Einstellungen zu deaktivieren, ohne in den Config-Dateien rumzuspielen.

ja, in dem fall wirds rein von den maßen her kein Bus sein.

Nein. Der Wert definiert quasi eine Bounding-Box um das Fahrzeug herum. ist diese innerhalb der "Fahrerkamera", wird das Fahrzeug angezeigt.
zwischen dem ersten und 4. EIntrag, dem zweiten und fünftem Eintrag als auch dem dritten und sechsten Eintrag ziehst du quasi eine Linie;

[VFDmaxmin]

-1.5

-6

-0.5

1.5

6

4.5

erstellt also eine Boundingbox, welche 3m Breit, 12m lang und 5m hoch ist.

Das ist ohne Moddingtools oder rumspielen in den *.pak-Dateien nicht möglich.

Das Ding ist unterm Strich ein 5-Zeilen langes Programm, abgesehen von Einstiegs/Ausstiegspunkten und so Sachen die OMSI halt braucht. Das Plugin checkt quasi ob deine DUS-Version up2date ist.

Naja, Funktionen Wegsperren kannst du einem Käufer auch nicht einfach so, solang es zum offiziellen Spielumfang gehört und in der EULA nicht anders geregelt ist. Was wäre denn aber, Wenn ich jetzt die Werbungen von damals aus dem Stadtbus auf so ein Wechsel-Rollband-Werbe-Ding am Straßenrand mappe und dann als Objekt rausbringe? Das Verletzt auch keine Copyrights oder so und ich wäre mir ziemlich sicher, dass das Objekt schneller aus dem Workshop verschwindet als du gucken kannst. Oder das ganze erst als normales Objekt veröffentliche und dann via Internettexturen (sofern es sowas wieder gibt) austausche? Wenn halt leute durch einen Like eines Postings ausgeschlossen werden, ist der Weg zu weiteren Maßnahmen auch nichtmehr weit und nur weil der Inhalt eines Workshop-Items nicht allen gefällt, gibt das dann automatisch das Recht das potentiell zu entfernen?

jup, ist das DUS Plugin. Warum da jetzt der Scanner anschlägt kann ich allerdings nicht beantworten.

Wiki

gib dir bitte selbst etwas Mühe. Das sind alles Grundsatzfragen die du dir nach 10 Minuten aufwand in der offiziellen Wiki durchlesen kannst.

hmn, zum aktuellen zeitpunkt leider nicht. in welchem intervall hast du getestet? der hoster war bisher eigentlich stets zuverlässig.

irgendeine Unterscheidung musste bei Bremen ja getätigt werden, um auch das Fahren nach Linie und Route weiterhin zu ermöglichen. Mit der Eingabe der Kursnummer wechselt das Ding automatisch in den "Fahrplanmodus" - Linie, nächste Haltestelle und co. wird dann quasi aus dem aktiven Fahrplan geladen und nichtmehr über Linie und Route aus der Hofdatei geholt. Das sollte aber, wie a2g schon gesagt hat, Grundsätzlich auch auf allen anderen karten Funktionieren. wichtig ist nur, den Fahrplan vorher ausgewählt zu haben.
ich würd sogar sagen das Fahren nach Fahrplan ist die am leichtesten Umzusetzende Variante, auch mit Hinblick auf die Haltestellenweiterschaltung. Manche Dinge wie Verspätungsanzeige sind ja sowieso nur mit aktivem Fahrplan möglich. Sowas kann ja als Patch ggf. noch folgen, das Ding ausm NLC hat sowieso noch einige Fehler die ausgemerzt werden sollten.

DIe Ursache kenne ich auch nicht, hab das Problem aber auch ab und an gehabt, vorallem mit 2.49b, in späteren Versionen eher weniger. Ist ja auch egal solang es eine Lösung für gibt.

Eine Ursache kann ich dir nicht nennen, sehr wohl aber eine Lösung:

Du setzt dir einen neuen Cube im Objektmodus (Shift+A ->Mesh -> Cube bzw. unten im Fenster Add -> Mesh -> Cube), selektierst dann im Objektmodus erst dein problematisches Mesh, dann zusätzlich den Cube und drückt STRG+J um sie zu verbinden. Dadurch übernimmt dein Mesh die Standardsettings vom Cube. Im Editmodus löschst du dann den Cube einfach raus und exportierst dein Mesh erneut. Dann sollte das auch der Converter fressen.

dann stellt der 3d objekt converter die Materialien falsch ein. Da kann ich dir leider nicht weiterhelfen. ich empfehle, das ganze als *.x-Datei zu exportieren und dann den X zu o3d converter aus den SDK Tools zu verwenden. Dann werden auch die Materialeinstellungen passend für OMSI gesetzt.