Beiträge von Chrizzly92

nah du bekommst ne Meldung dass der Key zurückgezogen wurde, unabhängig davon ob es installiert ist oder nicht.

Zitat von Axel Blaze

Ich habe seit dieser Woche einen neuen Pc und habe alles neu Installiert. Seitdem sieht es bei allen MAN Bussen es so aus wie auf dem Bild im Anhang

das sieht mir dannach aus als ob hier versionen durcheinandergemischt wurden. Entweder du nutzt eine illegale kopie, hast nicht alles neu installiert oder irgendein Freewarebus oder sowas liefert veraltete Zeichensätze mit. Die Lösung: über Steam OMSI auf Fehler überprüfen lassen, dannach sollte es wieder funktionieren.

Und so einen Key raushauen bricht der Krone nun wirklich keinen Zacken ab. Ich bräuchte nur bei Aerosoft nachfragen und bekomme kurz darauf ein paar Keys. Jeder, der bei meinen Projekten mitgewirkt hat und sei es nur ein Sound-sample gewesen, hat mindestens einen Key zum fertigen Produkt erhalten - und das läuft bei anderen Projekten i.d.R. auch so. Wenn du da als Moderator und ggf. Teammitglied keinen bekommst oder der Key zurückgezogen wird, lässt das schon wirklich seeeeehr tief blicken. Du warst Janine zum Schluss also - nach Abzügen - nichtmal die 15€ Wert. lol.

Zitat von PingPong

Naja, das Problem liegt aber eher an OMSI und nicht bei den Entwicklern. Die einzige Möglichkeit ist tatsächlich der Verzicht einzelner Stehplätze, damit diese nicht die Exit-Points blockieren. Ohne Stehplätze wäre aber auch blöd, ist ja kein Überlandbus.

Zitat von Perotinus

Alternative wäre die Exit-Points weiter nach innen zu verlegen, was allerdings zur Folge hat, dass die Leute dann beim Aussteigen kurz im Bus-Boden versinken. Ich weiß garnicht mehr, wie das damals bei den SD 200 gelöst war.

ich habe beides in München gemacht und das Problem tritt trotzdem hier und da auf. Interessanterweise ist das bei den Standardfahrzeugen nicht so präsent. woran das nun genau liegt weiß ich leider nicht. Ich muss mir wohl mal die Mühe machen die Pfade aus den standardbussen punkt für punkt und verknüpfung für verknüpfung rauszuschreiben und mir das mal genauer anzuschauen.
Alternativ kann man auch zwei pfade setzen, einen ausstieg weiter innen und einen einstieg weiter außen. das führ dann aber wieder zu anderen problemen.

Zitat von Berlin&Brandenburg

Aber irgendwie hat die Umfrage für mich Geschmäckle. Seit fast einem Jahr gab es schon keine Abstimmungen mehr - nun rückt die GamesCom-Ersatzveranstaltung näher und es sind neue Simulationen angekündigt - und schwupps ist plötzlich eine von Janines Umfragen da, die suggerieren soll, dass LOTUS ja demnächst sooo viele neue Features erhalten wird und allem Drum und Dran... Naja. Sollen sie erstmal liefern. Schnell und gut wäre wichtig.

Naja, fairerweise muss man auch sagen dass jetzt vermutlich die "Patch-Sommerpause" vorbei ist und die Arbeiten weiter gehen müssen. Dein Gedankengang gefällt mir aber wesentlich besser.

Zitat von Chaoslokführer

Ich habe heut die MAN Busse noch einmal auf anderen Maps getestet und muss anmerken das der Ki-Verkehr kein bisschen auf die Lichthupe reagiert. Ist das bisher wirklich noch keinem aufgefallen?

ich selbst spiele omsi kaum noch, weil es aktuell an interessanten Karten fehlt. BRT wird wohl die erste Karte seit Aachen die ich mir mal wieder anschauen werde. Lichthupe nutze ich aber so oder so nie. Braucht man auf gut gebauten Karten auch so gut wie nie. Dass die KI das nicht erkennt liegt vermutlich daran, dass OMSI vorgeschriebene Variablen für solche Sachen nutzt, das Script von mir aber über die Zeit immer weiterentwickelt wurde. Da ist die Funktion wohl ausversehen flöten gegangen. das werde ich für einen kommenden Patch im Auge behalten.

Zitat von Chaoslokführer

Servus, ich bekomme bei den Münchener Bussen noch folgende 2 Errormeldungen. Kann ich diese ignorieren bzw. die beiden Zeilen im Script löschen oder ist der Bus danach als Ki-Bus nicht mehr einsetzbar?

Error: Fehler: im Befehl "(M.L.AI_frame)" (vehicles\Muenchen_MAN_LC\\script\MVG_LC_Main_12_3_Zug.osc) ist der Macroname ungültig!

Error: Fehler: im Befehl "(M.L.AI_init)" (vehicles\Muenchen_MAN_LC\\script\MVG_LC_Main_12_3_Zug.osc) ist der Macroname ungültig!

Das haste dir wohl durch Mods oder sowas selbst zerschossen. Bitte über Steam reparieren.

Du kannst ja beim DUS Urbino über das Init die Sonderzeichen schildern. Da wurden halt nur keine M-Linien hinterlegt, weil die ja bei Düsseldorf auch so funktionieren. Es ist also nicht so, dass die Funktionalität weggefallen ist, sie wurde eher "verlagert". Die Fahrzeuge sind weitestgehend mapübergreifend fahrbar.

Ja, du kannst innerhalb der einzelnen Kacheldateien im Mapordner deiner Karte (z.bsp. tile_0_0.map) die entsprechenden Einträge entfernen oder ersetzen. Je nach Kartengröße ist das aber nicht ganz trivial und recht Zeitintensiv und vorallem Nervenraubend. Dazu einfach die entsprechende Datei mit einem Editor deiner Wahl öffnen, die nichtmehr vorhandene Datei suchen und den kompletten Bereich entfernen.

Das macht er nicht, weil er nur dann Antwortet, wenn er was findet über das er Meckern kann. Nimm meine Antwort als Beispiel - ich hab erklärt, warum die Standardlösung nicht möglich ist. Auf die Frage, wie er es denn gelöst hätte, kam nix und wird auch nix kommen. Er hängt sich an einem kleinen Fehler meinerseits auf (Kurs/Route) und auf meinen Hinweis, dass die M&R Lösung realistisch nicht möglich ist kommt halt ein "mach ihn überhaupt erstmal realistisch". Sachlichkeit und diskussion auf Augenhöhe - fehlanzeige.
Immerhin hat er ja einen Lösungsweg aufgezeigt, das muss man positiv erwähnen.

Pardon - ich meine natürlich Linie+Route. Bin leider nicht so "im Game drin" wie viele hier. Busse sind nicht mein leben, kann also vorkommen dass ich da mal zwei Fachbegriffe durcheinanderwürfel.

MIt dem Init hast du natürlich recht, auch wenn du das Düsseldorfer selbst wohl nie in Aktion gesehen hast und nur das nachplapperst was du anderweitig liest.
Im übrigen werde ich zukünftig nichtmehr auf deine whataboutism Antworten reagieren, das ist mir schlichtweg zu dumm. Wenn du meine Argumente sachlich diskutieren willst, ist das kein Problem, für alles andere ist mir meine Zeit zu schade.

Steven3233 nimmst du quasi hier in der Webdisk den gleichen Platz ein wie ich damals im OMSI-Forum? Stunk machen einfach nur des Stunkes wegen? Ich glaub dann muss ich mal ähnliche Konsequenzen für dich anregen. Dass du aber ja nur meckern kannst ist ja mittlerweile bekannt, dementsprechend sehe ich mal über deine unfreundliche und unsachliche Art hinweg und erkläre hier gern für dich und andere, Warum diese Problematik existiert.

Vorab sei gesagt, dass es keine Pflicht gibt, irgendeinem Standard zu folgen. Und wenn ich das machen würde, regt man sich dann drüber auf, dass nur kopiert wurde. Entweder man geht seinen eigenen Weg oder man bleibt beim Standardumfang.

Grundsätzlich achte ich allerdings stark auf eine Kompatibilität meiner Fahrzeuge. Für diese sind - abgesehen von Sonderfunktionen - beispielsweise nie spezielle Hofdateien von Nöten. Beim MAN Stadtbus habe ich sogar auf kompatibilität mit der universellen Hofdatei geachtet!
Das Fahrzeug wurde allerdings explizit für das Düsseldorf Add-on entwickelt und ist dort problemlos einsetzbar. Darum gehst bei einem Karten+Bus DLC. Auch die Metrolinien lassen sich dort schildern. Für viele Andere Karten besteht die Möglichkeit, über den Copiloten das Ziel zu verändern und beispielsweise eine SB-, E-, SEV oder X-Linien zu schildern, genauso wie bei der Standard M&R Matrix. Das ist auch der Grund, warum ich eben NICHT auf die vordefinierten Sonderzeichen gesetzt habe. das ist quasi ein Relikt aus den 90'ern und moderne Bordcomputer besitzen andere Möglichkeiten zur Manipulierung der Zielanzeige. Im Übrigen bietet die "Standardlösung" weit weniger Möglichkeiten als mein Ansatz es tut. Auch bin ich nicht auf 99 Sonderziele limitiert, ich kann tausende Implementieren wenn ich das möchte. Auch eine echte Freitextmatrix wäre Umsetzbar. Das ist mit dem M&R Ansatz nicht möglich. Richtig ist allerdings, dass dort aktuell keine freien M-Linien möglich sind, da das für DUS bisher nicht gebraucht und dementsprechend nicht umgesetzt wurde. Das werde ich im kommenden Patch dementsprechend nachreichen.

Im übrigen habe ich weder mit Kevins Karte noch mit seinem MINI-DLC etwas am Hut. Auch fahre oder interessiere ich mich nicht für das MINI-DLC. Mich begeistert die Technik und der Modellbau, nicht aber Düsseldorf. Dementsprechend wurde das Fahrzeug meinerseits auch nicht auf Kompatibilität auf einer Karte geprüft, die ich selbst nicht habe. Auch ist das MINI-DLC nicht bestandteil des DUS Addons, auch wenn es mit diesem kombinierbar ist. Ich sehe mich also hier auch nicht in einer Position, wo ich mein Fahrzeug hätte betatesten müsste oder sicherstellen muss, dass ein DLC eines Dritten damit kompatibel ist.

Abschließend sei noch gesagt, dass allein Aufgrund der Kombination von Linie+Kurs, wie es auch in echt ist, die Möglichkeit, Sonderzeichen über die letzten beiden Ziffern der Linie einzugeben, sowieso weggefallen ist. Wie stellst du dir also vor, Sonderzeichen im M&R Style zu schildern? Das ist realistisch mit dem Copilot nun mal gar nicht möglich!

wenn du uns nun material zukommen lässt, in welchem Erkennbar ist, was dort überall steht, was die einzelnen buttons machen und was die untermenüs der buttons machen setzte ich mich sofort an die Umsetzung.

das ist halt schon wieder so ein richtiger Megabrain Kommentar, der mich richtig hart motiviert, an einem Update zu arbeiten.
Grundsätzlich muss man hier erstmal erwähnen, dass der DUS-Copilot noch gar nicht final ist. Wenn du also Material hast, wie es denn sein sollte, nehme ich das gern entgegen, um deinem Wunsch, ein Update für das Fahrzeug zu erstellen, gerecht zu werden. Als Ossi aus Dresden habe ich leider nicht die Möglichkeit, nen bekannten Fahrer in Düsseldorf in seiner Pause zu nerven, um mal eben Vorbildfotos des Fahrzeuges zu erstellen. Du scheinst es ja besser zu wissen, also teile uns doch mit wie es sein muss! Aber nicht hier, machs im DUS-Thread.

Zitat von Lµkas

Stimmt nicht ganz, in LOTUS ist der Kerncontent OpenSource, öffentlich für Jeden. Also selbe Geschichte wie bei OMSI. (ausgenommen halt Workshop&Payware-Entwickler - wobei ich glaube, dass viele ihre Sachen für LOTUS auch offenlegen werden, ähnlich wie es ja bei Cities:Skylines auch ist. Da gibt's teils riesen GitHub-Projekte...)

Naja, das Standardscript als Basis zu haben macht daraus aber noch lange kein funktionsfähiges Modell. In OMSI konnte man einfach mal mit den variablen rumspielen oder - der klassiker - nen haltewunschsummer hinzufügen. das geht in LOTUS eben nichtmehr. Bis man also was "vorzeigbares" hat, haben viele schon wieder aufgegeben.

Zitat von Lµkas

Ein kleines Beispiel: Ihr kennt ja alle das Oberflächensystem von OMSI (0 für Asphalt, 1 für Beton usw.). Das beschränkt einen in der Hinsicht, dass man nur vorgegebene Konstanten hat, die man nutzen muss. Eine mögliche Alternative dazu wäre, jeglichen Untergrund selbst definieren zu können, z.B. anhand von Härte, Griffigkeit usw. Wenn ich jetzt aber zu jeder Asphalt-Textur noch den Reibungskoeffizienten bei verschiedenen Gummi-Sorten und immer in der Unterteilung trocken und nass angeben müsste... - wo kämen wir da hin? Sicherlich gäbe es dann vordefinierte Werte, die man nutzen könnte, aber das alles mit so viel Overhead, dass die meisten das System als "zu kompliziert" betrachten würden.

Grundsätzlich richtig, Aber dafür kann es doch Presets geben. Neben den vordefinierten Varianten könnte es ja auch noch die Auswahlfläche "Custom" geben, wo man entsprechend eigene Werte hinterlegen kann. Programmierseitig wäre das kein massiver Mehraufwand, würde aber nach hinten raus die Möglichkeiten deutlich verbessern. Alles kann, nichts muss.

der zweite visible-wert hat immer Priorität, weil die OMSI-Sachen immer von oben nach unten abgearbeitet werden. das kann je nach Anwendungsfall funktionieren, muss es aber nicht.

Perotinus , Ich empfehle in so einem Fall (und mach es auch selbst so), ein kleines Script zu schreiben, um den Visible-Eintrag zu steuern.

(L.L.VariableA) 
(L.L.VariableB) &&
{if}
    1 (S.L.Visible_Variable)
{else}
    0 (S.L.Visible_Variable)
{endif}

Wenn beide Variablen aktiv, setzt er die visible-variable auf 1, sonst null. das geht natürlich auch mit "oder" oder kombinationen, die ungleich sein sollen.

(L.L.VariableA) 
(L.L.VariableB) ||
{if}
    1 (S.L.Visible_Variable)
{else}
    0 (S.L.Visible_Variable)
{endif}

in dem fall nur aktiv, wenn mindesteins eine von beiden aktiv

(L.L.VariableA) 0 =
(L.L.VariableB) 1 = &&
{if}
    1 (S.L.Visible_Variable)
{else}
    0 (S.L.Visible_Variable)
{endif}

oder hier nur aktiv, wenn VariableA nicht aktiv und Variable B aktiv.

Das ganze einfach irgendwo in einem frame-marco eintragen und fertig.

Für die Profis hier ließe sich so ein script auch noch abkürzen:

(L.L.VariableA) (L.L.VariableB) && (S.L.Visible_Variable)

da für OMSI alles, was größer 0 ist, "true" ist und 0 "false", lässt sich das script oben auch noch abkürzen. der operator (und, oder, kleiner gleich, größer gleich etc.) gibt ja 1 und 0 aus wenn true oder false, was direkt wieder als Wert für die Visible-Variable genommen werden kann. spart die {if}-Schleife ein, ist aber schwieriger zu verstehen und zu lesen.

dieses "auf der Physik rumgereite" ist wirklich langsam ausgelutscht. Das ist schon lange kein Verkaufsargument oder Alleinstellungsmerkmal mehr für LOTUS. Ja, die Physik aus dem Hause M&R War bisher besser als in anderen Entwicklungen im bereich Simulation. Das wars aber auch! LOTUS bietet keine direkte Kontrolle über das Fahrzeugverhalten, alles folgt einer vordefinierten "Physik". Klasse! nen Objekt entlang eines Pfades zu animieren hab ich ohne tiefere Programmierkenntnisse in der UE4 innerhalb weniger Tage umgesetzt. Inklusive diesem übertriebenen Sinuslauf. Das ist alles simple Mathematik, ab und zu auch mal was komplexeres wie Vektorrechnung (z. Bsp. zur Bestimmung der Winkel der Fahrzeugteile zueinander) Das ist alles nun wirklich keine Kunst. Die Physik vom Bus wurde eventuell nicht selbst entwickelt sondern eingekauft. war auch in OMSI nicht anders, dort wurde die open dynamics engine genutzt. Und wer weiß, eventuell hat man sich dort auch Arbeit gespart und eine fertige Fahrzeugphysik "nur" auf die eigenen Anwendungsbereiche angepasst. Wieviel der so hoch-gepriesenen Fahrzeugphysik ist also das Werk von Marcel?

Eine Kunst ist es allerdings, die Physik den Content-Devs im Editor komplett offen zu legen. Der LOTUS Ansatz mag für 0815 Fahrzeuge funktionieren, bei komplexeren Konstellationen sieht das anders aus. Ich nenne hier immer gern den KT4D von Kartoffelphantom, welcher aktuell nicht korrekt umsetzbar ist. Tatra hat bei OMSI beispielsweise die fehlende Kontrolle über die Differentiale gestört. Sobald in LOTUS mehrere Wagenteile physikalisch voneinander abhängig sind, funktioniert das System nicht mehr bedingungslos und da draußen wirds noch genügend Fahrzeuge geben, die eben nicht "kompromisslos realistisch" abgebildet werden können. Und selbst wenn man aus Programmiersicht versucht, alle Eventualitäten abzudecken, kommt jemand um die ecke der aufzeigt, dass es eben nicht geht.

Solang man also mit "Vorgaben" arbeitet, ist man eingeschränkt. War bei OMSI auch nicht anders - der Einstieg an allen Türen kam auch nur mit dem Wien Add-on iirc und ist nicht Bugfrei. Die Erkennung, ob jemand sitzt brauchte Darius in Hamburg. Gelenkphysik kam mit OMSI 2. Doppelgelenkphysik wieder für Darius. Nie wurde das Spiel effektiv für die Community erweitert, das passierte nur weil es für Payware gebraucht wurde. Und "workarounds" oder Abstriche bei der Funktionalität, die ja beispielsweise in OMSI immer so negativ betrachtet wurden wenns um Straßenbahnen oder Züge ging, sollten in LOTUS nun wahrlich keine Verwendung finden. Inwiefern ist man also in OMSI oder LOTUS freier als in anderen Spielen? Die Grundlage war nur schon solide und es ist recht einfach, darauf aufzubauen. Aber selbst das ist beim Containersystem in LOTUS nicht mehr möglich. Selbst in Payware - und da schließe ich mich keinesfalls aus - stecken verdammt viele Scriptschnipsel die wiederverwendet wurden. Das macht das Modding halt einfach und den Einstieg leichter.

Konsequent wäre es, ALLES frei definierbar zu machen. Wie Bei Lego. Du brauchst nur die Achse auf der Schiene, alles andere baust halt selbst. Ob das jetzt nen Zug mit Jakobsdrehgestellen ist, normale Drehgestelle oder irgendwas spezielles. Völlig egal, alles ist Möglich. Dazu benötigt es aber frei definierbare physikalische Verbindungen mit 6 Freiheitsgraden, bei denen jeder Freiheitsgrad manipuliert werden kann. Fertig. Dann baut man nen KT4D halt "physikalisch" und nicht mathematisch nach.

Nachteil: Kostet halt Rechenleistung, ist selbst schwer zu implementieren und eine gute, fertige Physikengine kostet Geld.

Ein Spielkern ist das, was die Inhaltentwickler draus machen. Nur weil die Fernbusvehicles nen beschissenes Getriebe haben, liegt das nicht am Spiel. Nur weil beim BS18 selbst die Gelenkfahrzeuge Mittelmotoren haben, die Gelenke beschissen aussehen und mitgelenkte Achsen starr sind, liegt das nicht am Spiel. Das liegt an den Leuten, die ebendies im Spiel implementieren und das steht und fällt mit den Fähigkeiten der Content-Entwickler und die Möglichkeiten, die die Engine bereitstellt. Man kann also nur hoffen, dass die Aerosoft Interpretation der Schienensimulation genügend Möglichkeiten für Entwickler bietet, wirklich mal frei zu sein. Dazu braucht es eine nahezu uneingeschränkte Moddingfähigkeit und Soliden Grundcontent, auf dem man aufbauen kann. Ansonsten muss man immer irgendwo Abstriche machen.

Aus eigener Erfahrung kann ich sagen, dass der BS18 zum aktuellen Zeitpunkt mehr Moddingmöglichkeiten bietet als LOTUS. Wie das mal aussieht wenn LOTUS fertig ist, weiß ich nicht. Das Potential wird nur nicht genutzt, weil der Grundcontent schon zu Wünschen übrig lässt, zumindest aus der Sicht der non-casual Spieler.
Für BS18 habe ich ja beispielsweise mal mit einem Gelenk-Urbino herumexperimentiert. Es wäre problemlos möglich, viele Probleme, die das Spiel mitbringt, selbst zu verändern und entsprechend zu verbessern. Ich habe aber nicht die Zeit, "Grundlagenforschung" zu betreiben, da könnt ich mir auch selbst nen Spiel programmieren.

Der große Unterschied zwischen M&J und anderen Entwickler"studios" ist nur, dass Marcel aus der Szene kommt. Er weiß, wie es sich richtig anfühlt - das können andere Entwicklerstudios oftmals nicht. Ein gutes Skateboarding-Spiel kann nur von oder mit Leuten entwickelt werden, die aus der Szene kommen. Ein gutes Drift-Spiel kann nur von oder mit Leuten entwickelt werden, die aus der Szene kommen. Ein guter ÖPNV-Simulator kann nur von oder mit Leuten entwickelt werden, die - und jetzt Achtung - aus der Szene kommen. Warum sich Entwicklerstudios da so schwer tun ist mir bis heute ein Rätsel und das ist nicht nur ein Problem im Bereich Simulation.

tl;dr:
Solange Entwicklerstudios nicht Anfangen, aktiv mit Leuten aus der Szene zu arbeiten, kann und wird ein Projekt oft am Content scheitern, selbst wenn das Spiel dahinter gut programmiert ist. Damit steht und fällt auch die Aktivität potentieller Modder, denn wenn der Einstieg schwer ist macht sich keiner die Arbeit.
Gut ist, dass auch LOTUS mMn. nichtmehr mit Physik oder leichtem Modding Punkten kann. Dieses Alleinstellungsmerkmal gibt es mMn. nichtmehr. Es bleibt also spannend, wie sich andere Projekte schlagen werden.

naja, bei der Optimierung gehören schon immer beide Parteien dazu. In OMSI könnte ich problemlos nen Script schreiben, was OMSI in die Knie zwingt - ist deswegen der Spielkern nicht optimiert? So einfach ist es dann auch nicht. Aber man darf auch nicht vergessen, dass wir aktuell im Jahre 2020 sind. Da ist 4k mittlerweile der Standard bei Texturen, 8k z.T. im Vormarsch. Man muss ja gerade bei so einer Indy-Entwicklung keine Maßstäbe setzen, sollte aber dennoch Zeitgemäß arbeiten. Das hat Viewapp halt gemacht, die Engine kann das aber nicht. Wer da den fehler gemacht hat ist wohl Ansichtssache.

Lazarus ja, von schlecht war nicht die Rede, keine Frage - aber es ist jetzt auch nicht so, dass ich nen top of the line rechner habe, der "unverhältnismäßig" schnell ist. Gekauft hab ich meine Hardware im August 2018, also quasi vor zwei Jahren, wo LOTUS in den Early Access ging. Jetzt, zwei Jahre später sollte meine Kiste aufjedenfall noch als gute Mittelklasse durchgehen und Leistungsmäßig ein recht großes Spektrum abdecken und selbst da ist halt zu merken, dass der Spielkern auf sich selbst warten muss.
Auf Notebookhardware oder wirklich alten Maschinen kanns natürlich wirklich an der Rechenleistung liegen und ein Upgrade der Hardware für LOTUS macht sinn. Ordentlich Spielbar (und da rede ich von 60FPS+, auch auf Düsseldorf oder größeren Freewarekarten) kann LOTUS aber aktuell gar nicht werden und das Abschalten von Features wie Schatten zählt da mMn. nicht als Lösung. Dann brauch man sie auch gar nicht erst implementieren.

Perotinus Ja, Rolfs Zeug sieht wirklich, wirklich gut aus, wobei ein Stilles Bildauch besser aussehen kann als ein bewegtes. Screenshots aus OMSI könnten auch manchmal als Fotorealistisch durchgehen, Bewegtbilder sind dann wieder was anderes.
Interessant wäre zu wissen, mit welcher Framerate sich Rolfs Hamburg aktuell spielen lässt, wenn die Effekte auch so wie auf den Screenshots aktiviert bleiben. Denn München sah stellenweise auch super aus, aber ein Entwickler, der die Möglichkeiten ausreizt war dann ja schuld an der unterirdischen Performance. Ich würde mich soweit aus dem Fenster lehnen und behaupten, dass Rolfs zeug zum aktuellen Zeitpunkt ebenso nicht vernünftig Spielbar ist. Solche Bilder sollten dementsprechend auch nicht als Benchmark a la "guckt mal wie gut das aussehen kann" herangezogen werden.

Zitat von Perotinus

Deshalb ist der Stand für mich momentan: LOTUS bietet mehr Materialeigenschaften. Alles andere (Technik) habe ich in OMSI, oder ich kann es mangels NASA-Rechner nicht benutzen (Schatten, 3D-Vegetation).

auch wenn das von den Entwicklern und vielen Spielern oft behauptet wird, kann ich nachweislich behaupten, dass das so nicht stimmt. Meine Hardware - und diese ist nun nichtmehr das Maß der DInge (GTX1070ti, Core i7 8700k) wird von LOTUS nicht ausgelastet. der Spielkern limitiert bisher. Es ist also ab einem bestimmten Punkt nichtmehr relevant, ob dein PC schneller ist oder nicht, das Spiel selbst ist mit den Berechnungen überfordert und skaliert nicht proportional zur Rechenleistung.
Du kannst es also mangels Optimierung nicht benutzen, nicht mangels NASA-Rechner. Selbst wenn dein Rechner nichtmehr der modernste ist, kann ich dich "beruhigen" - auch bei mir läuft LOTUS nicht rund - Diorama zählt da nicht wirklich aufgrund der Kartengröße und selbst dort habe ich mit Microrucklern zu kämpfen. Aber Grundsätzlich gebe ich dir recht - was bringen Effekte, die man aus Performancegründen eh nicht sinnvoll nutzen kann? Nen Mehrwert sehe ich da aktuell auch nicht, abgesehen vom Multiplayer, der recht spaßig sein kann, auch wenns nur von kurzer dauer ist.

OMSI 1 als auch OMSI 2 waren nunmal keine performancewunder und vorallem unter Betrachtung des OMSI 2 Releases, bei dem durch die unterschiedlichsten Optimierungsversuche ein unspielbares Produkt veröffentlicht wurde und dies erst durch einige Patches erträglich wurde, finde ich es sehr wohl richtig als auch wichtig, auf die Framerateproblematik hinzuweisen. keiner hat Bock auf eine Diashow, vorallem nicht mit Hinblick auf VR. Es liegt hier an Marcel, "uns" vom Gegenteil zu überzeugen und zu zeigen, dass es auch vernünftig geht. Und wenn aktuell mit massig fehlenden Features das Spiel nicht den Eindruck erweckt, später mit entspannten 140FPS in VR zu spielen, fällt es mir wirklich schwer zu glauben, dass es irgendwann überhaupt so weit ist. Man darf auch nicht vergessen - den aktuellen Stand haben wir seit 2! Jahren und zumindest auf meinem Rechner hat sich die Framerate nicht verbessert, sondern stetig verschlechtert (wohlgemerkt auf "Tu es nicht!") Und dabei ist die Hardware auch irrelevant, zumindest wenn man einen bestimmten Schwellenwert überschritten hat. Denn weder CPU noch GPU werden von LOTUS zu 100% ausgelastet, das Spiel selbst limitiert hier immernoch, unabhängig der Hardware.