Beiträge von Chrizzly92

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    Hier wird Seitens der Entwickler überhaupt nicht externen Anwendungen gearbeitet sondern mit Dynamic Link Library, welche keinen Einfluss auf die Performance haben. Eigentlich auch nichts neues, kam bei Düsseldorf auch schon zum Einsatz, nur wurde dort keine Verifizierung mit Steam gefordert.

    Die Verifizierung via Steam wäre mit Sicherheit für den Funktionsumfang nicht notwendig gewesen. Das Plugin aus DUS ist wesentlich weniger invasiv und hat selbst wenn man das Add-on illegal Verteilt keinen Einfluss. Einzig und allein die Illegalen Kopien funktionieren irgendwann nicht mehr.
    Im Übrigen kann eine DLL sehr wohl Einfluss auf die Performance haben. Und was ist wenn die Registrierungsseite in einigen Jahren nichtmehr online sein sollte?

    920 20:53:04 - - Error: Dateizugriff verweigert: AMUAV.CNAVO.MV.E


    hast vermutlich durch eine Mod oder so die Zugriffsrechte verändert und OMSI kann die Datei nicht lesen. Bitte mal OMSI komplett neu Installieren (vorher z.bsp. den OMSI 2 Ordner umbenennen und dann über Steam alles neu beziehen) und schauen obs geht. dann kannst du stück für stück die alten dateien wieder installieren.

    Bei diesem Bullshit den du schreibst krieg ich echt kotzreiz. Der Vergleich ist einfach absolut dumm.

    Wenn Du absolut keine Ahnung von programmieren hast solltest du dich zurückhalten mit solchen dämlichen Aussagen. Wenn es kein großes Problem wär und man es innerhalb kürzester Zeit fixen könnte hätte man es schon längst getan anstatt die Interims-Optionen einzubauen. Wie gesagt, es gibt bedeutend wichtigere Dinge um die sich gekümmert werden muss als etwas zu fixen wofür es einen Workaround gibt.

    Und es wird zu einem kleineren Problem wenn man diesen Bug über den Entwicklungszeitraum mitschleppt? Aber schön, dass du so ehrlich bist - denn das Zeigt, dass es Konzeptionierungsschwächen im Spielkern gibt. "Ihr" wisst dementsprechend selbst nicht woran das liegt und habt deswegen Interimsoptionen eingebaut oder der Fehler ist konzeptionell so tief verankert, dass er nicht so einfach behoben werden kann. Bevor man also Leuten "keine Ahnung vom Programmieren" vorwirft, sollte man eventuell eine solide Codebasis bereitstellen. Wer im Glashaus sitzt...


    Stimmt, es ist natürlich die Aufgabe von den Betatestern sich alle möglichen Monitor-Größen zu kaufen und alle möglichen Auflösungen zu testen!

    Traurig das man mit allen mitteln versucht alles ins schlechte zu ziehen, wer anstatt Bugs zu melden lieber nur rum heult und es darauf schiebt es sei die Aufgabe der Betatester sowas zu testen scheint echt nicht der hellste zu sein.

    Die Auflösung lässt sich doch über Windows einstellen, unabhängig vom Bildschirm. Aber du hast recht, das ist natürlich Mühselig, einfacher ist es doch die Auflösung über die Grafikeinstellungen des Spieles zu definieren. Sorry, ich vergaß, das geht in LOTUS ja nicht. ¯\_(ツ)_/¯

    Die Source-Engine hat damit aber auch Probleme, zumindest vor 1-2 Jahren war das so. LOTUS steht da also nicht allein da. Aber klar, in Zeiten wo quasi jedes Mainboard nen Anschluss für nen Bildschirm und fast jeder Prozessor ne APU hat, sollte das zu keinen Problemen mehr führen.

    Ich hätte die Fahrgäste auch gern mal getestet, bei mir ist LOTUS allerdings unspielbar.

    warum nicht? Es ist doch richtig und wichtig pro und contra abzuwägen, vorallem für zukünftige Projekte. Seit wann ist überall diese "naja ist halt so" Einstellung modern? Bin vermutlich als Ossi hier einer der wenigen die nicht diese larifari Einstellung haben.

    "Wir erhöhen die Steuern um 20%" "Naja ist halt so, haben sich dazu entschieden dann soll es so sein, steht mir auch nicht zu drüber zu Urteilen." Klar, im Falle von LOTUS ändert eine Diskussion darüber nix aber alles überall einfach "wegzuignorieren", "es leid zu sein" ist doch wohl auch keine Lösung. Dann kann man auch einfach gleich jegliche Kommunikation unterbinden, sich nen Joint anzünden und auf alles scheißen.


    Das ist überhaupt kein Argument, um auf eine eigene Engine zu setzen. Das ist vielmehr ein Ausblick, warum es sinnvoll sein kann.

    Ich glaub wir reden aneinander vorbei. :D


    Das Ding mit der eigenen Engine verstehe ich bis heute immernoch nicht,[...]


    Im Endeffekt gar nicht blöd, weil du an keine Limitierung gebunden bist. [...]


    und das ist man beispielsweise bei der UE4 auch nicht. Spurcecode und co. verfügbar, man kann sie auf die eigenen Ansprüche anpassen. Das Rad neu erfinden ist nicht immer notwendig.

    Zu sagen, ne eigene Engine ist gar nicht blöd weil du keine Limitierungen hast ist sehr wohl nen altbackenes Argument. Bei SCS macht die eigene Engine auch nur Sinn, weil Sie seit Ewigkeiten in Entwicklung ist und vorallem gepflegt wird, in einer vernünftigen und Zukunftsorientierten Sprache (C++). Iirc wurde die SCS Inhouse Engine seit irgendeinem 18 Wheels of Steel genutzt und das ist bestimmt 15 Jahre her, dazu kommt die Zeit der Entwicklung vor Veröffentlichung. Das ganze als Ein-Mann-Team zum stemmen in so kurzer Zeit kann mMn. nichts werden.
    Klar, wenn du nen großes Studio hast macht eine eigene Engine Sinn, schon allein weil bei vielen freien Engines Gebühren anfallen. Oriolus würd ich aber nicht als großes Studio bezeichnen wo genug Kapazitäten für die Entwicklung bereitstehen.


    Edit: 2006 war das. Also 14 Jahre + Entwicklung vorm Release.

    Im Endeffekt gar nicht blöd, weil du an keine Limitierung gebunden bist. Du kannst das ganze grenzenlos erweitern und immer neue Dinge implementieren, ohne irgendwann halt machen zu müssen. Die Idee dahinter kann ich nachvollziehen und finde ich auch gut, jedoch scheitert so ein Prozess oftmals an fehlender Optimierung. Eine etablierte Engine mag zwar auch hier und da Performanceprobleme haben, aber eine eigene Engine erfordert viel mehr Anpassung und Optimierung, als andere - die dann auch dieser Entwickler ausbügeln muss.


    Ich bin halt der Meinung: Bevor man Gameplay bastelt, sollte die eigene Engine optimiert und angepasst sein. Hinterher wird die Chose nur noch ein Krampf.


    Das ist aber auch nen altbackenes Argument. Für die UE4 ist beispielsweise der Sourcecode öffentlich zugängig und lässt sich von jedem der Will entsprechend anpassen und optimieren.

    Komisch, im Logfile steht nichts auffälliges. Und ich habe so etwas auch noch nie erlebt.

    doch da steht was Auffälliges, Zeile 253:


    Code
    01:26:50 -  -   Error:           Fehler: im Befehl "(C.L.antrieb_getr_autoSwUpMaxSpd4)" (vehicles\London Citybus 200\\script\C200_main_AI.osc) <SC_ErrorInCommand_constantinvalid>


    Das kann durchaus ursächlich für den Fehler sein.

    Und wie Chrizzly sagt, man muss die verwendete Bildschirmauflösung in Verhältnis zur Textur bzw. Objektgröße sehen. Otto-Normaluser fährt wahrscheinlich immer noch in FullHD, Rest verteilt sich wohl auf 1440p und 4K. Jetzt nehmen wir mal an jemand mit 1920x1080 hat auf seinem Bus eine 4K Textur für die Außenwerbung. Wie viel Unterschied würde er also sehen wenn der Bus vor der Nase ist im Vergleich zu einer 2K Textur? Wohlgemerkt vor der Nase, über weiter weg möchte ich garnicht reden;-)

    Aber auch für niedrigere Bildschirmauflösungen machen hochaufgelöste Texturen sinn - und zwar dann, wenn man bei einem Bus mal an die Front ranzoomt um Logos vom Verkehrsunternehmen oder sowas zu sehen. Lochfolie auf Scheiben ist dafür auch ein gutes Beispiel.

    Trotzdem sind diese mittlerweile der Standard und Grafikengines sollten solche Grössen ohne weiteres aushalten.

    Naja... wenns um Häuser geht seh ich das ja vielleicht noch ein. Aber nicht bei Gullideckeln oder sowas kleineres. Das nimmst du so gar nicht war. Allgemein, und das ist meine Meinung, ist der Unterschied zwischen 4k und 8k nicht ausreichend groß, was die 4fache Texturgröße nachvollziehen lassen.

    du hast zwar Grundsätzlich recht, das ist dennoch nicht die Schuld von Viewapp. selbst Wenn sie einen Gullideckel in 8K texturieren, liegts an der Engine, hier die passende LOD-Stufe zu schalten. Nehmen wir an, eine Hausfassade hat eine 2k-Textur gemappt. Schaue ich diese mit einem Full-HD bildschirm an, erreiche ich mit einer 4K textur keine bessere optik. stelle ich mich nun näher an das Gebäude, um - übertrieben gesagt - das klingelschild zu lesen, wäre diese 2k- Textur dann nur noch wischiwaschi pixelbrei. Liegt die Textur in 8K vor, so kann LOTUS doch bei der Vorbeifahrt einfach die 2K Textur darstellen, zoomt man ans gebäude ran oder läuft irgendwann im Egomodus vorbei, werden die LOD Stufen durchgeschalten und gut ist. Das setzt natürlich vorraus, dass das Pipelining der Texturen vernünftig programmiert wurde und LOTUS sich nicht beim Laden verschluckt.

    Das ist ein weiterer Kritikpunkt am TramSim. Ich persönlich hätte es schöner gefunden, zwischen zwei Modi zu unterscheiden:

    Selbiges zu implementieren halte ich für nicht besonders aufwendig - wie erwähnt taten das TML-Studios auch bereits. Ich kann mir vorstellen, dass man in der Hinsicht auf den Wunsch der community eingeht, den ich schon öfters las.


    In wie weit TramSim und TheBus durch ihre Engine voneinander profitieren können, kann ich nicht beurteilen.

    Chrizzly92, du hast doch meines Wissens nach ein bisschen Erfahrung mit Blueprints und dergleichen. Kannst du, falls du Zeit und Lust hast, erläutern, ob dies theoretisch sinnvoll oder realistisch ist? Voraussetzung wäre natürlich auch das jeweilige Interesse des Entwickler(studio)s.

    Ich nehme an, das wirds auch noch geben. Aktuell gibts ja nur ein Fahrzeug und eine Strecke - nach einmal fahren gäbe es kein Ziel und die langzeitmotivation wäre dahin. So hat man ein Ziel vernünftig an den Haltestellen zu halten, den Fahrplan einzuhalten und ordentlich zu fahren, um Punkte zu sammeln und weitere Features freizuspielen. Mit Modding, DLC's und co. wirds mMn. auch eine Sandbox geben.


    Rein vom Aufwand her sollte das kein Ding sein. Ich weiß nicht ob UI und Spiellogik in C oder Blueprint geschrieben wurden, hätte ich ein ähnliches System über Blueprint implementiert, wäre es ein leichtes einfach einen branch einzubauen a la "Sandbox?" Ja -> deaktiviere den Schnickschnack oder halt nein-> zähle punkte.

    Achja, die Aussage dass stabile 30 besser sind als schwankende 60 sollte niemanden dazu animieren da die Framerate zu locken. Das schafft nämlich auch längere Zeiten zwischen den Frames, wo zum Beispiel das Nachladen und vieles andere passiert, und das bremst man unter Umständen dann aus... Aber da sind wir schon inder OMSI-Esotherik drin;-D

    Tatsächlich ists aber in OMSI genau andersrum. liegt aber auch daran, dass OMSI sehr CPU-Lastig ist. begrenzt du die Framerate auf 30 FPS, hast du in OMSI spürbar weniger und schwächere Ruckler, weil mehr "overhead" für andere Berechnungen frei bleibt. :-)

    Du wirst auch keine RTX 3090 drinhaben sondern irgendwas, was halt "gerade so" für LOTUS ausreicht, da zum aktuellen Zeitpunkt deine Karte schneller ist als der Spielkern. Für die Optimierung des Spieles würde sprechen, dass sie dauerhaft auf 100% läuft, da LOTUS dann mehr Bilder bereitstellen würde als die Grafikkarte schafft. (natürlich nur wenn VSync deaktiviert)
    Eine 80-90% Auslastung ist dementsprechend mit einer 10-20% Auslastung gleichzusetzen.

    Nein, nur eine GTX 980. Perfekt optimiert ist LOTUS da definitiv noch nicht. Aber anfangs wurde die Grafikkarte bei mir nur zu ca. 50% beansprucht. Insofern merke ich da durchaus ein paar Veränderungen... Aber meine Einstellungen sind natürlich entsprechend der Leistung meines Rechners nicht auf'm Maximum, weshalb der Vergleich zu deiner Auslastung eh ein wenig hinkt.

    hat ja auch keiner das Gegenteil behauptet. Als die Spiegel implementiert wurden, war ich positiv überrascht wie gut das noch läuft. zugegeben, die GT6n hat auch nicht viele und viel zum Rendern gabs noch nicht, aber immerhin.
    Wenn LOTUS mehr braucht als dein Rechner zur Verfügung stellt, machts natürlich Sinn, die Einstellungen runterzuschrauben. Wenn die Hardware aber noch nicht ausgelastet wie in meinem Fall sehe ich es aber nicht ein die EInstellungen zu reduzieren, denn dann liegts nicht an der Hardware die limitiert sondern am Spiel.

    Das Problem hierbei ist das schon oben angesprochene Content-System. Die LOTUS-Entwickler können einem Entwickler jederzeit den Gar aus machen anhand der Content-ID. Eine alternative Plattform für LOTUS-Mods oder ein unabhängiger Vertrieb von AddOns wird also kaum möglich sein weil es am Ende dazu führen könnte, dass man das Spiel + evtl. AddOns ganz verliert wenn man sich auf solches Terrain begibt. Ob das jetzt gut ist (keine Copyright-Probleme mehr) oder schlecht (künstliche Beschränkung der Vielfalt, insb. für die internationale Community) sei an dieser Stelle mal dahingestellt.

    Das ist per EULA zudem untersagt. Einziger Vertriebsweg geht über Oriolus, alles andere ist Freeware oder nicht erlaubt. Es ist ein Leichtes, entsprechende Pakete per Update zu markieren und die Ausführung zu verbieten.


    TramSim hat seit seinem Release Probleme die einzelnen Teile des Flexity zusammen zu halten. Das ist für ein fertiges Spiel zum Vollpreis meiner Meinung nach keine gute Entwicklung.

    Nun, man kann das TramSim natürlich ankreiden. Ich möchte hier aber erwähnen, dass im Letzten Spiel von Marcel eine Gelenkphysik integriert wurde, die bei weitem nicht besser ist. Gibt genug Screenshots, die komplett Zerissene Fahrzeuge in OMSI zeigen - und ich brauch nur mal ne in LOTUS ne Weiche unter mir stellen und schon zerreißt meine Tram.
    Der große Unterschied ist hier folgender: bei Tramsim wird - zumindest gefühlt - geschaut, wo probleme liegen und diese werden behoben. LOTUS schleppt seit JAHREN!!!! Probleme wie das Settingsmenü mit, welches das Spiel freezed oder Probleme wie Hier , welche zwar über Workarounds zu funktionieren scheinen, aber im Endeffekt auch nur das Symptom unterdrückt und nicht die Ursache behebt.
    Fehlerhafte Spiele sind kein Problem - solang man die Probleme Zeitnah behebt, vorallem dann wenn es Gamebraker sind.



    Der Unterschied ist einfach der, dass TramSim die völlig fertige Unreal-Engine von Epic Games verwendet und LOTUS komplett von null mit eigener Engine entwickelt wird.

    Habe mit der (vergleichbaren) Unity-Engine ein relativ vollständige 3D-Spielwelt innerhalb von 1 Woche erstellt, was ohne fertige Engine das 10-50x an Zeit in Anspruch genommen hätte.

    Das kann mir als potentieller Spieler doch aber komplett egal sein? Für den Mathelehrer ist es egal, ob du deine Prüfung mit nem schönen Casio oder TI Grafikrechner bearbeitest oder dir nach open source plänen einen eigenen zusammenbastelst, solange das Ergebnis stimmt. Da kannst dann allerdings nicht sagen; "Herr Lehrer, ich muss meinen Rechner noch zusammenbasteln", während alle anderen schon ihre Prüfung abgegeben haben.


    Dies beweist letztlich, dass die Engine der limitierende Faktor ist und nicht der PC. Man könnte OMSI auch auf einem Supercomputer spielen, die Performance wäre keinen Deut besser. Ähnliches hat Chrizzly92 (korrigiere mich wenn ich falsch liege) bei einem frühen Stand von LOTUS beobachten können (seine Worte waren in etwa "Die Grafikkarte zeigt sich völlig unbeeindruckt, ist nur geringfügig ausgelastet, aber das Spiel pfeift aus dem letzten Loch als ob gar nichts mehr ginge") - aber was nicht ist, kann ja noch werden.

    Fairerweise muss ich hierzu erwähnen, dass ich diesen "Test" seit Release der ersten EA Version durchführe und von Anfang an ALLE Effekte, Slider, Einstellungen oder Werte auf das Maximum gesetzt habe, um sowohl die Hardware maximalst auszulasten und auch immer mit den gleichen Einstellungen testen kann. Es läuft mit Sicherheit besser wenn man die Einstellungen runter schraubt. Ein Titel aus 2018 sollte aber mMn. auf Oberklassehardware aus diesem Zeitraum auch mit den höchsten Einstellungen vernünftiglaufen. (GTX1070ti, i7 8700k, 64gb ram)

    Unter diesen Bedingungen langweilt sich tatsächlich ein Großteil meines Prozessors. von 12 logischen Threads kann ich bis auf 4 alle deaktivieren, ohne dass sich die Framerate ändert. Die Threads werden immerhin auf 4 logische Prozessoren verteilt. Die Auslastung meiner GTX1070ti auf Diorama unter "tu es nicht " lag zwischen 40 und 60%.
    Mit schwächerer Hardware wird man natürlich irgendwann einen Flaschenhals bilden, zum letzten Testzeitpunkt (als die Fahrzeug-KI implementiert wurde) war meine Hardware aber nicht voll Ausgelastet, dementsprechend limitiert sich die Engine noch selbst. Natürlich nicht absichtlich, aber die Grafikkarte kann halt kein Bild Rendern, wenn die Daten dafür noch nicht bereit sind.
    Das sieht man auch als Außenstehender oft in Youtube-Videos oder Bugmeldungen. LOD Stufen die nicht geladen werden, Fahrzeuge bleiben durchsichtig und und und - das sind alles Probleme, die durch eine Überforderung der Engine entstehen. Da nützt es nix, den besten Rechner zu haben, die Probleme treten trotzdem auf. Features, die nicht nutzbar sind, kann man auch gleich weglassen.

    Dazu muss ich sagen, dass sich das - zumindest bei mir - doch schon deutlich geändert hat. Meine Grafikkarte wird i.d.R. durchaus zu 80-90% ausgelastet.

    Generell läuft der LOTUS bei mir auch bei höheren Einstellungen ziemlich performant und besser als der OMSI. Wie allerdings oben schon erwähnt wurde, verhält sich das halt leider bei jedem anders.

    Du wirst auch keine RTX 3090 drinhaben sondern irgendwas, was halt "gerade so" für LOTUS ausreicht, da zum aktuellen Zeitpunkt deine Karte schneller ist als der Spielkern. Für die Optimierung des Spieles würde sprechen, dass sie dauerhaft auf 100% läuft, da LOTUS dann mehr Bilder bereitstellen würde als die Grafikkarte schafft. (natürlich nur wenn VSync deaktiviert)
    Eine 80-90% Auslastung ist dementsprechend mit einer 10-20% Auslastung gleichzusetzen.

    Das ist aber genau der Punkt wo ich denke das man mit dem Autor des Fahrzeuges kommunizieren kann. Ich glaube kaum das kein Modder etwas gegen so einen Mod für sein Fahrzeug hat (und wenn dann dürfte man den Mod ja sowieso nicht veröffentlichen).

    Ähm - warum wird dann nicht gleich die Möglichkeit implementiert, grundsätzlich jedes Mesh austauschen zu können? da generiert das content tool halt einfach eine "Wagenkasten.l3d", die man mit einem eigenen Container austauschen kann.
    Dass das Modding in der Form beschränkt wird und nur das explizit möglich ist, was der Entwickler erlaubt, ist so gewollt. Es gäbe genug Ansätze 100% modding zu ermöglichen ohne extra nachzufragen. Wenn also ein Entwickler nur bestimmte Sachen zulässt, wird er sicherlich nicht auf Nachfrage nachreichen.



    Edit: Framerate ist übrigens nicht alles. Klar sind 60 FPS schön, besser wären aber 30, dafür ohne Nachlader und Microruckler, um einen sauberen Spielfluss zu simulieren, vorallem im Hinblick auf VR. selbst wenn auf manchen Karten also Stellenweise 60 FPS erreicht werden, fühlt sich das Spiel noch lange nicht flüssig an und einiges an rechenintensiver Simulation fehlt ja auch noch. wurstbrot , deine Karte im Multiplayer mit einem Spielerfahrzeug mehr wird dir direkt ein anderes Erlebnis bieten.

    Solang du modifizierte Dateien nutzt, egal in welcher Form, kann ich dir leider nicht weiterhelfen. Wie oben schonmal erwähnt hat man in OMSI zu viele Variablen, die Fehler verursachen können - daran ist dann aber nicht das Add-on schuld.
    Teste das ganze mal auf einer sauberen Installation - am besten so, wie omsi_sw es beschrieben hat. Dann brauchst du dir auch keine Gedanken machen, dass eventuelle Änderungen deine anderen Modifikationen verändern. Sollte der Fehler dann immernoch auftreten, können wir eventuell weiter schauen. Der Fehler tritt nur lokal bei dir auf - also schließe bitte nicht deine eigenen Anpassungen oder Mods aus, Ursächlich zu sein. Wie gesagt - ein Fremdrepaint aus der Karte Liestal hat dafür gesorgt, dass die MAN Stadtbusfamilie nichtmehr spielbar war - wie sollen wir als Entwickler so was ausschließen können?