= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Theproloser Prinzipiell hast du recht, wäre da nicht die VR-Funktion von LOTUS. Natürlich scheiden sich da auch wieder die Geister, aber 20-30 FPS halte ich für VR einfach zu wenig. Erfahrungen hab ich nicht, aber hin und wieder hört man aus der VR-Community einen Richtwert von 45FPS, ab dem es "angenehm" wird.
Eine Erfahrung gibt's z.B. hier zu lesen. https://www.lotus-simulator.de…cht-in-vr-sehr-stotternd/
Ich finde das hier tatsächlich recht unübersichtlich und wusste nicht, wo ich die Frage stellen sollte.
Schau Dir am besten mal folgenden Artikel an:
Da findest du ein paar Infos über die Bereiche. 
75 11:12:17 - - Error: The file "Money\Berlin2020\euro.cfg" could not be loaded!
76 11:12:17 - - Error: The file "TicketPacks\Berlin_2020\Berlin_1.otp" could not be loaded!
Geh mal in die Datei maps\Berlin_Buch\global.cfg rein und öffne sie mit einem normalen Texteditor. Suche folgende Schlüsselwörter und ersetze folgende Zeilen:
Damit sollte sich das Problem erledigt haben. Zum Rest siehe fOcUs04s Antwort
Erklärung: Anscheinend wird das Geld und Ticketpack nicht gefunden. Mit obigen Einträgen setzt du beide auf den Standard zurück, der mit OMSI im Auslieferungszustand mitgeliefert wird.
Verschoben in den richtigen Bereich.
Deshalb schlage ich vor, dass diese maximale Anzahl an Zeichen ausschliesslich für Zeichen ausserhalb eines Spoilers gilt
Da weiß ich nicht, ob das technisch möglich ist. Was sagen die Admins?
Technisch nicht möglich. (bzw. immer dann wenn ich sage "nicht möglich" meine ich "nicht mit verhältnismäßigen Arbeitsumfang möglich", möglich ist alles )
Die verspoilerte Logfile sollte die erste Wahl sein, aber z.T. sehe ich zwecks Formatierung im Download auch schneller den Fehler.
Da würde ich die Regel ändern, dass auch Logfiles in Code-Blöcken gepostet werden sollen, finde ich persönlich übersichtlicher!
Im Wiki ist dies bereits vermerkt. Die Richtlinien für Supportanfragen sind mir untergegangen, das wird zeitnah geändert.
Ansonsten könnte man auch generell einfach die maximalanzahl an Zeichen des Beitrags hochsetzen!
Klar kann man das machen, aber a) steigt mit zunehmender Länge eines Beitrags auch die Ladezeit und manche Browser verkraften zu große Seiten auch nicht, insb. auf dem Handy; b) ist jede Grenze immer willkürlich gewählt, das heißt egal, wie man es dreht und wendet, es wird immer Logfiles geben, die zu lang sind. 
Deswegen verstehe ich auch bis heute nicht warum man sich ausgerechnet an die Luftfahrt noch wagen möchte.
Weil Marcel damit schon aus früheren Flight Simulator-Zeiten Erfahrung hat.
Lotus ist kein Ersatz für Zugsimulationen. Es kann zwar Zug, aber die Sinnhaftigkeit wird irgendwo im Regionalverkehr aufhören.
Ich meine mal gehört zu haben, dass man sich auch auf den Regionalverkehr beschränken möchte. Im Entwicklungsfortschritt ist jedenfalls die S-Bahn-Linie Spandau-Lichtenberg genannt.
Wie definiert/ machten das in Omsi, mit den scheibenreflektionen und den Lichtern
Der liebe Tatra hat da ein umfangreiches Tutorial geschrieben:
Daniel Buda meinte meines Wissens nach mal, dass man alles so programmiert hätte, dass der Spung von Tram auf Bus nicht allzu problematisch wäre, Tram auf Zug ist wahrscheinlich auch nicht das Problem.
Ich denke, ViewApp wird schlau genug sein und bei der Entscheidung für/gegen Busse berücksichtigen, wie TheBus wird. Ich hätte auch nichts dagegen wenn die beiden Simulatoren parallel existieren, TramSim für Straßenbahnen und TheBus für Busse. Natürlich wäre es cool, alle Fahrzeugtypen unter einem Dach zu vereinen und vielleicht hofft der ein oder andere auch insgeheim, dass sich beide Firmen da zusammentun (ist ja auch die gleiche Engine), aber die Eierlegende Wollmilchsau gibt's nicht. Das ist einfach utopisch.
Stimmt! Haben die hoffentlich mitbekommen, dass dieses System in den Ausmaß schlecht ist. Ich zahle nicht für ein Spiel, damit ich es spielen muss, um weiterhin Spielspaß zu haben.
Bei Tramsim muss ich selbst für die virtuelle Weichenstange mal Level 3 haben. Zukünftig sind dann immer mehr Funktionen des Fahrzeuges und auch andere Fahrzeuge mit dem Levelsystem verknüpft.
Das ist ein weiterer Kritikpunkt am TramSim. Ich persönlich hätte es schöner gefunden, zwischen zwei Modi zu unterscheiden:
Im Endeffekt dann so etwas wie die Karriere-Szenarios im Dovetail Train Simulator (wie es in TSW aussieht, weiß ich nicht). Die dritte Möglichkeit wäre, Geld als Belohnung einzuführen, mit dem man sich die Features dann kaufen kann, ähnlich wie im ETS2 könnte man dann auch einfach einen Kredit aufnehmen. Und dann könnte sich z.B. in Kombination mit einem Wirtschaftssystem die Frage stellen: "Kaufe ich mir jetzt die Fähigkeit, Weichen per IBIS zu stellen (weil das normalerweise nur per Hand geht und Zeit kostet = Verspätung bringt) oder repariere ich Tür 2 rechts (= schnellerer Fahrgastfluss)" - auch eine interessante Möglichkeit, aber alles Zukunftsmusik.
Floats-Modul
Dabei handelt es sich nach allem, was ich bisher gehört habe, um einen "Scherz", der mMn aber auf offiziellen Seiten nichts zu suchen hat. Ist ja auch umtitelt mit dem "Modul für Gleitkommazahlen".
Die Performance von einem EA-Spiel mit halbfertiger Engine und diversen noch fehlenden (Teil-)Features zu vergleichen mit einem Spiel, was bereits den Release-Umfang erreicht hat, ist jetzt aber nicht so zielführend.
Meine Erwartungshaltung ist aus diesem Grunde auch, dass LOTUS aufgrund der noch fehlenden Features und der Unfertigkeit der Karten / noch fehlender Detaillierung durch zu wenig Content, definitiv besser laufen müsste als TramSim. Das ist jetzt aber kein Beweis, dass LOTUS eine bessere Performance hat, sondern einfach nur ein Ergebnis des Implementierungsstandes.
Ein Java-HelloWorld-Programm ist auch viel schneller als eine vollständige C++ Anwendung mit GTK oder Qt - trotzdem würde ich einfach mal so behaupten, dass C++ die schnellere Programmiersprache von beiden ist.
Viel weiter bringen uns die Kommentare "Aber auf meinem PC läuft X besser" auch nicht. Da spielen einfach zu viele Faktoren rein, wie Hintergrundprogramme, Hintergrundaufgaben, Internetverbindung, Einstellungen, neben der GPU und CPU natürlich noch HDD vs. SSD, Arbeitsspeicher, ... Eine Aussage über die Performance ist auch nur eine Momentaufnahme, kann z.B. von Hintergrundupdates von Windows beeinflusst werden, von Steam (?) oder auch einfach davon, dass gerade in der getesteten Spielversion ein Bug drin war und und und ...
Ich denke, wir haben mittlerweile alle verstanden, dass die Performance von LOTUS noch nicht optimal ist, aber die Entwickler versprochen hat, dass sie sich noch darum kümmern werden. Wie viel sich da tatsächlich noch tut, kann man nur mutmaßen.
Dann müssen wir aber auch erwähnen, dass auf München sämtliches Zeugs ne 2k bis 4k Textur hat.
... was ich von Spielen im Jahre 2020 als Mindestandard voraussetze.
Sorry, aber das ist wieder der Fingerzeig auf die ach so bösen München-Entwickler, die dem Spiel zu viel zumuten. Wenn das Spiel mit 2-4k Texturen nicht gut zurechtkommt oder mit ausmodellierten Häuserfronten, ist es doch nicht Schuld der Entwickler, sondern es liegt am Spiel.
Ich für meinen Teil finde die flachen Häuserfronten, wo Spalten, Absätze etc. per Textur gelöst sind, überaus hässlich. The BUS kann das besser.
Da frage ich mich, ob das so bleibt wenn Features wie KI-Verkehr, Menschen und Fahrpläne dazukommen.
Bei einem PC, der mit einer GTX 3080 und einem ebenbürdigen Prozessor ausgestattet ist, erwarte ich, dass jedes Spiel flüssig läuft. Alles Andere wäre schon ein derbes Armutszeugnis.
[...] das Modulsystem nicht einfach umgekehrt hat, sodass standardmäßig alles editierbar wäre, aber der Ersteller Bauteile explizit nach den eigenen Präferenzen abwählen müsste, um den Ausbau/Austausch zu unterbinden. [...]
Würde doch aber aufs selbe hinaus kommen, nur mit dem Unterschied, dass der Ersteller mehr Zeit für den Release braucht.🤷♂️
Nein, weil die meisten Leute faul sind und lieber keine Haken anklicken anstatt aktiv irgendwas zu machen. Genau das ist ja auch das Problem bei der Frage, ob Opt-Out oder Opt-In für interessenbasierte Werbung besser ist.
Hier mal ein Blick auf eine meiner aktuell im Bau befindlichen Karten.
Ich sehe auf den Bildern vor allem Folgendes:
Schau dir als Vergleich mal folgenden Screenshot vom FBS an und achte mal besonders auf den Straßenrand:
https://cdn.cloudflare.steamst…920x1080.jpg?t=1608289631
(btw: Screenshot NICHT von mir!)
Wohlbemerkt bin ich mir relativ sicher, dass sich das Gras bewegt. In LOTUS keine Spur. Dabei könnte man so viel damit machen, bspw. Rasengleis, wo sich das Gras mit der fahrenden Straßenbahn im Wind bewegt.
Hallo, hier jemand, der sich auf diesem Gebiet auskennt
Wie viel kann man später noch raus holen? Auch jetzt wird Marcel ja versucht haben, halbwegs effizient zu arbeiten. Wie viel Raum zur Optimierung bleibt dort noch?
Gut, pauschale Aussagen werden da wahrscheinlich nicht möglich sein. Aber die Framerate zu verdoppeln, stelle ich mir schwierig vor.
Meine Meinung dazu hab ich bereits vor Monaten zum Ausdruck gebracht:
Alles anzeigenDass die Engine mal wieder stark limitiert merkt man bei der Nutzung von Workshopinhalten. Meine Hardware wird nichtmal ansatzweise ausgelastet - aber offiziell hat man dann halt nen Kartoffel-PC, wenns nicht richtig läuft.
Das ist genau wie bei OMSI. Kaum Multithreading, 64-Bit-Unterstützung fehl am Platz, ... Mich hat schon von Anfang an sehr sehr sehr stutzig gemacht, dass Performance und eine 64Bit-Unterstützung (die mMn schon 2018 mit dem Release zum guten Ton gehörte!) am Anfang der Entwicklung als nebensächlich bis stiefmütterlich abgehandelt wurde. Das rächt sich jetzt. Außerdem hörte man auch schon von Anfang an Stimmen zur negativen Performance, bei dem Content, der im Moment im Umlauf ist und den bescheidenen Funktionen ein klares Makel.
Ein bisschen ist die Community da aber auch selbst schuld und ich kann das auch gut verstehen (als Spieler will man vor allem Features sehen, ob es jetzt 1-2 FPS mehr oder weniger sind, ist egal). Schließlich gab es auch noch nichts, was wirklich performance-intensiv war (KI-Verkehr, Fahrzeugmodelle die mal ein paar Polys mehr haben als ein Haus mit vier Wänden, Vegetationsmodelle usw.) - auf der grünen Wiese packt auch ein noch so schlechter PC ein noch so performancefressendes Game. Wenn man sich vorstellt, dass aber irgendwann mal die Linie 100 oder die M1 in Berlin fertig realisiert werden soll (wer mal da war, weiß wovon ich spreche)... Ähm joa... Man hat halt eher den Eindruck, dass man möglichst schnell vorzeigbare Sachen haben will (= mehr Sofortkäufe voller Vorfreude) als dass man erst mal ne ordentliche Engine fertigstellt (oder schon Vorhandenes nutzt).
Meiner Meinung nach hat man da die Prioritäten falsch gesetzt, die bei einem Game von solchen Ausmaßen nunmal sind: 1) Engine (einhergehend mit der Performance) 2) Logik 3) Content. Bei LOTUS ist es eher ein Wirrwarr: Während schon fleißig Content entwickelt wird (sowohl von der Community als auch von DLC-Anbietern als auch von den Entwicklern selber) wird immernoch an der Engine geschraubt und die Logik mal einfach so "nebenher" erweitert (zB KI-Verkehr, Multiplayer, ...).
Wenn man Software entwickelt, ist die erste Frage vor der man steht ja auch nicht die Frage ob ein Button blau oder grün sein soll (Content im weitesten Sinne). Man fängt erstmal mit dem Kern (zB Backend, Grundfunktionen) an.
Alles anzeigenIn der Community-Abstimmung für "zuerst KI, dann Performance" gestimmt wurde
Das hat die Community dann selbst verbockt:
Ein bisschen ist die Community da aber auch selbst schuld und ich kann das auch gut verstehen (als Spieler will man vor allem Features sehen, ob es jetzt 1-2 FPS mehr oder weniger sind, ist egal). Schließlich gab es auch noch nichts, was wirklich performance-intensiv war (KI-Verkehr, Fahrzeugmodelle die mal ein paar Polys mehr haben als ein Haus mit vier Wänden, Vegetationsmodelle usw.) - auf der grünen Wiese packt auch ein noch so schlechter PC ein noch so performancefressendes Game. Wenn man sich vorstellt, dass aber irgendwann mal die Linie 100 oder die M1 in Berlin fertig realisiert werden soll (wer mal da war, weiß wovon ich spreche)... Ähm joa... Man hat halt eher den Eindruck, dass man möglichst schnell vorzeigbare Sachen haben will (= mehr Sofortkäufe voller Vorfreude) als dass man erst mal ne ordentliche Engine fertigstellt (oder schon Vorhandenes nutzt).
Das ist auch das Problem mit direkter Demokratie. Viele Leute haben einfach keine Ahnung von schwierigen Prozessen im Hintergrund, fordern aber möglichst schnell vorzeigbare Ergebnisse. Bei solch wichtigen Sachen bindet man dann halt nicht die Community ein, sondern verklickert den Meckerern, dass erstmal hinter den Kulissen gewerkelt werden muss bevor Ergebnisse sichtbar werden. Stattdessen wirkt das irgendwie planlos, so nach dem Motto "Was sollen wir jetzt machen?" - "Keine Ahnung, lass die Community mal fragen."
Man konnte vorher halt nicht genau einschätzen, wie stark die KI die Performance beeinflusst.
Dann hätte man die KI halt vorher implementieren sollen und nicht inmitten der EA-Phase. Das Ganze steht total auf wackeligen Beinen. Erst das Grundgerüst solide und fertig machen, dann die Community ranlassen und Content entwickeln. Das, was da geliefert wird, ist eher ne Public-Alpha als eine EA.
Alles anzeigenIch bin kein Programmierer, aber mal rückgefragt: Was spräche dagegen zuerst eine performante Basis zu entwickeln und dann die performancefressenden Funktionen draufzusetzen?
Nichts. Das macht man eigentlich überall in der Softwareentwicklung. Wenn man bspw. ne Webseite entwickelt, ist die erste Frage nicht, ob ein Button blau oder grün ist, sondern man setzt erstmal ne Basis auf, überlegt sich ne Architektur, stellt Anforderungen und einen genauen Plan auf, in der professionellen Softwareentwicklung würden dann noch Lasten-/Pflichtenheft dazukommen und Monate / Jahre, die nur für Dokumentation (rechtliche Gründe) und Kundengespräche draufgehen. In einem Großprojekt kann das schonmal bis zu einem Jahr dauern bis die erste Zeile Code geschrieben wird.
Im Prinzip würde ich sagen, dass das in der Spieleentwicklung genauso läuft. Man wählt erst ne Engine aus (ggf. entwickelt man die selber) und komplettiert die Basis. Um die Performance zu testen, kann man dann gewisse Szenarien und Benchmarks entwickeln ohne bereits "produktiven" Content zu entwickeln. Dann schaut man, wie man das weiter verbessern kann und wenn man damit zufrieden ist, hat man idR schon ne halbwegs stabile Basis, auf die man bauen kann. Zu diesem Zeitpunkt gibt's dann noch gar nichts Vorzeigbares, aber das Konzept ist fertig.
Es spricht aber aus meiner Sicht nichts dagegen, an der Performance im Nachhinein rumzuwerkeln. Dann sollte man sich aber der o.g. Effekte bewusst sein: Je später man an der Basis von Software noch was macht, desto wahrscheinlicher ist, dass man damit viiiel mehr zu tun hat und man Workarounds ohne Ende einsetzen muss. Das Scheitern von großen IT-Projekten ist zu 95% damit erklärbar. Man kann nicht die Grundanforderungen an ein System ändern, dessen Kern schon fertig ist. Dafür gibt's dann agile Methoden (für den, den es interessiert: Google "agile Softwareentwicklung"), die das versuchen, auszuräumen. Aber auch da fängt man mit dem Kern an und nicht "irgendwo".
Edit: MeerrettichMeister hat das unten sehr anschaulich dargestellt.
Fazit: Priorisierung der Performance als letztes ist gefährlich - hat aber die Community selbst verbockt, die am liebsten Content und Features sieht.
Hätte man dann nicht auch schnell omsi patchen können?
Das wiederum ist ein anderes Thema und meinem Kenntnisstand nach den (Rechts-)Streitigkeiten mit Rüdiger geschuldet, dass sich an OMSI nichts mehr getan hat.
allerdings findet das auf viel zu wenigen Karten Verwendung.
Wäre natürlich super wenn das in Zukunft mehr Leute machen würden.
Genau dieses Problem sehe ich halt beim Modul-System + das potenzielle Problem, dass man gar nicht wissen kann, was jemand in der Zukunft sich alles für Module wünscht.
Allgemein wäre es sinnvoller wenn man beim importieren einmalig festlegen müsste, was modbar ist und was nicht, so dass das a) im Vorfeld kommuniziert werden könnte, b) nicht jeder Modder zum betteln kommt und c) keine Berechtigungen zurückgezogen werden könnten.
So als kleine Spinnerei: Eine Art "Sandbox", in dem man jeglichen Content egal wie beliebig editieren, kreuzen und mischen kann, aber dann so, dass man das nicht veröffentlichen kann, bspw. sichergestellt durch kryptografische Verfahren, Checksummen o.ä. Dann könnte man ähnlich wie eine Git-Patch-Datei alle Änderungen loggen und dann so ein Archiv packen, in dem nur die Änderungen drin sind.
Das gepackte Archiv kann sich dann jeder herunterladen, der Bock auf den Mod hat, es wird aber jeweils nur das Geänderte geteilt, bspw. neue selbst-erstellte Texturen oder Sounds. Da Originaldateien nicht mitgeliefert werden, sondern noch im jeweiligen Container liegen, ist das wahrscheinlich vom Copyright her kein Problem.
Funktioniert dann ähnlich wie Perotinus mit den Skripts seiner Busse, die dann einfach die Dateien im Original-Ordner abrufen, ohne sie mitzuliefern.
detailliertere Karten
Ähm? Das will ich aber mal sehen. Die LOTUS-Karten, die ich bisher gesehen habe, sehen alle sehr steril aus, ohne die ganzen Details (Büsche, herumliegender Müll, Flecken auf der Erde, Gras, ...) Das wirkt schon alles sehr lieblos.
Klar, ist EA aber dann bitte auch nicht einfach Sachen behaupten, die nur für die Zukunft gelten sollen.
einfachere Moddingfunktionen für den "einfachen Benutzer"
Anders, ja, aber nicht unbedingt einfacher. Einfacher ist eher das OMSI-System im Sinne von "ich öffne ne Textdatei und ändere mal eben schnell ne Konstante, speichere ab und fertig".
Wenn ein Modder Interesse daran hat das die eigenen Fahrzeuge umfassend umgebaut werden können, dann muss man halt Module erstellen. Ich denke aber das hier Kommunikation ein Schlüssel ist. Wenn man was einbauen möchte, warum fragt man ihn dann nicht einfach den Autor vom Bus ? Ein Aufwand sind die Module nicht.
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).
Bei aktiven Benutzern mag das stimmen. Und bei der deutschen Community ebenso. Aber wenn man dann so nen Oberpfalz 3D hat, der quasi überall seine Finger im Spiel hatte, sich aber zurückgezogen hat oder Mods aus der internationalen Community, deren Ersteller dann einmal auftauchen und dann nie wieder gesehen wurden...
Mir scheint als würdest du nicht über den Tellerrand hinausschauen, sondern nur Vorzeige-Entwickler sehen, die auf jeden Wunsch aus der Community eingehen. Das sind die wenigsten. Und ich hätte ehrlich gesagt auch keine Lust, mir ständig von irgendwelchen Leuten anhören zu müssen "bau das noch als Modul, bau dies noch und jenes bitte auch". Da geht mir irgendwann der Hut hoch, sage "macht was ihr wollt" und stell gar nichts mehr online aus Frust. Die wenigsten werden in diesem Moment dann daran denken, ihre Inhalte als Public Domain zu kennzeichnen.
Und sorry, das Argument, dass man miteinander reden kann, zieht einfach nicht. Beispiele gibt es zuhauf aus allen Spiele-Communities. Allein die Tatsache, dass man keine Veränderungen durchführen kann ohne dass der Ersteller dies explizit erlaubt, ist eine Beschränkung für Modding.
Nebenbei: Was ist mit Karten? Da gibt's so etwas wie Modulslots nicht.
Zitat(und wenn dann dürfte man den Mod ja sowieso nicht veröffentlichen).
Veröffentlichen nicht, aber privat modden tun ja auch viele und das ist definitiv legal. Eben das, was ich zuvor beschrieb, dass man sich den Bus der persönlichen Lieblingsverkehrsgesellschaft zusammenstellt und wenn das Teil nen komischen Entwerter hat, der in OMSI nur im kommerziellen Solaris-Stadtbus-AddOn mitgeliefert ist, kauft man sich halt das AddOn und baut den Entwerter aus dem AddOn ein.
Von den ganzen Omsi Spielern gibt es nur eine mittelgroße Gruppe die Sachen moddet. Hier sprechen größtenteils die Leute aus der Modder Gruppe. Ich schätze aber mal das von den Tausenden Omsi Käufern nur 1/3 bis 1/4 auch sich Sachen privat ummodden. Für 2/3 bis 3/4 ist das System von LOTUS also benutzerfreundlicher.
Ich hau einfach mal ne Zahl raus und behaupte, dass etwa 50% aller OMSI-Spieler schon mal an den Dateien irgendwie "rumgepfuscht" haben.
Genau das ist doch auch, was man TML oft beim FBS oder ViewApp auch beim TramSim vorwirft: Man muss die Sachen so nehmen wie sie sind und kann sie nicht verändern.
Hier wird mit zweierlei Maß gemessen!
Es gab nie eine öffentliche Ankündigung. Das die Fußgänger früher kommen sollten wurde doch nur von Viewapp öffentlich gemacht. Seitens M+J ist mir keine Ankündigung bekannt.
Dir vielleicht nicht, weil Du ein - entschuldige meine Ausdrucksweise - unbedeutender Spieler bist und auch keinen Vertrag mit Oriolus abgeschlossen hast. Aber ViewApp hat das und da gehe ich erstmal von aus, dass das Hand und Fuß hat. Vor allem da sie nicht einfach nur "rumgemoppert" haben, sondern gleich ein eigenes Spiel auf die Beine gestellt haben und ich denke nicht, dass sie das gemacht hätten wenn sie irgendeine andere Lösung gefunden hätten.
Beispielsweise Bordsteinabsenkungen. Die kann wesentlich leichter mit Polygonen und den Bordsteinsplines umsetzen, als in Omsi.
Auch das ist problemlos in OMSI möglich. IceTea2202 hat es vorgemacht in diesem Wiki-Artikel. Wenn man Straßenzüge in Blender baut, kann man all das performancesparend in einem wirklich guten Editor bauen, siehe die Hamburg-Map. Aber:
Das muss dann aber natürlich auch gemacht werden
Und das ist in OMSI wie in LOTUS das Problem mit minderwertigem hingeklatschten Content. Jeder kann was bauen, aber gut bauen können nur die wenigsten. Wieso das jetzt ein Argument für LOTUS ist, erschließt sich mir nicht, denn die wenigsten LOTUS-Karten, die ich bisher sah, machen so etwas auch tatsächlich, genauso wie in OMSI, wo nur die wenigsten Straßenzüge in Blender bauen.
siehe oben
