Beiträge von Lµkas
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:
-
-
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:
- Sandboxmodus, in dem man alles machen kann, aber auch keine Punkte o.ä. sammelt.
- Karrieremodus, bei dem die Features nur je nach Level verfügbar sind, man dafür aber auch Erfahrungspunkte sammelt, die man z.B. in den Community-Ranglisten sehen kann.
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:
- Schlauchbauweise
- Backdrops
- 3D-Gras, wobei das "3D" daraus entstanden ist, dass man vier Faces aus jeder Richtung sieht
- Texturen, die aus OMSI bekannt sind
- Flache Häuser, die ebenfalls nicht über den Detailgrad von OMSI hinausgehen
- Flache Grastextur auf dem Rasengleis anstatt wirkliches 3D-Gras
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:
Dass 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.
In 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.
Ich 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
-
Bei LOTUS beträgt diese Zeit maximal 5 Minuten, und ich kann losfahren.
Bedenke jedoch, dass LOTUS noch nicht fertiggestellt ist und noch viele Features fehlen, die noch auf Ladezeit und Performance Einfluss haben. OMSI ist bereits "fertig" und beinhaltet auch Features, die LOTUS gegenwärtig noch nicht bietet.
Daher ist es extrem schwer und mühselig darüber zu diskutieren, weil es immer auf eigenen Erfahrungen beruht.
Anders herum wird daraus ein Schuh: Gerade der Vorteil von Performance ist, dass man hier wirklich harte Fakten anführen kann. PC-Daten, CPU-Auslastung, Benutzung des Speichers, Speicherzugriffe pro Sekunde, GPU-Auslastung. Dementsprechend ist Performance bis zu einem gewissen Grad sehr wohl objektiv messbar und muss nicht immer nur im Auge des Betrachters liegen.
Mal ganz zu schweigen von der Grafik, die sowieso immer nur eine rein subjektive Wahrnehmung sein kann.
Das stimmt insofern als dass man sagen kann "Grafik gefällt mir, weil ..." oder eben der umgekehrte Fall. Hier zieht man als objektive Kriterien eher Vergleiche mit anderen Spielen zurate (ETS2, TramSim, OMSI), die teilweise auch objektiv sein können, wie z.B. das Statement "A bietet B, was die Darstellung von C realistischer macht."
-
Selbst auf PCs von 2020 läuft Omsi ja nicht gut
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.
Linien woanders hin fahren lassen oder Fahrpläne verändern, wie Schleswig-Holstein es macht (gut, dieses Feature ist noch nicht fertig, kann man also wenig darüber sagen)
Soweit ich das bis jetzt allerdings verstanden habe, soll ein Fahrplan unabhängig einer Map erstellt werden können.
Folglich hast du dann einen Container für eine Map und einen Container für einen Fahrplan oder einen zweiten für einen anderen Fahrplan.
Ich habe daraus noch nicht so ganz verstanden, wie ich dann zb neue Buswürfel (wenn in LOTUS damit gearbeitet wird) hinzufügen kann, ohne dass ich ja die Map anfasse.
Welcher Ersteller setzt mir zb an einer Schule schon 5/6 verschiedene Buswürfel von Haus ausMit "Fahrplan" könnte auch gemeint sein, dass man lediglich die Fahr-/Umlaufzeiten ändern kann, nicht die Routen oder so. Also alles, was sich in OMSI außerhalb des Mapeditors in den Dialogen und im Fahrplaneditor stattfindet.
Aber da warten wir lieber mal, bis das Feature fertiggestellt ist.
-
kann nur vorgefertigte Teile nehmen.
Wie meinst du das genau ? Ich kann z.b. auch eine Innenanzeige in Blender bauen, scripten, diese dann im Workshop hochladen und dann in den GT6N einsetzen.
Du beschränkst Dich nur auf das, was von den vorhandenen Modul-Schnittstellen vorgesehen ist
. Was ist z.B. mit folgenden Sachen:
- Meshfehler selbst beheben
- Loch flicken
- Entwerter austauschen
- Haltewunschdrücker an ne andere Stelle verschieben
- eine Sitzreihe wegschieben zugunsten einer Kinderwagenecke
- Anhängerkupplung hinzufügen und zB mit dem Anhänger eines anderen AddOns mischen
- Spiegel austauschen
- Sicht verändern, um sie an seinen Bildschirm anzupassen
- Performancefresser entfernen (anmierter Motor, siehe NL202 von Frenzymax, den hat sich eigentlich jeder selbst entfernt :D)
- Stern bei den Payware-Fahrzeugen hinzufügen, die ihn nicht haben
- Radkappen hinzufügen
- Konferenzecke ausbauen
- Getriebe austauschen, manuelle Schaltung hinzufügen
- Skripts austauschen, um zB eine automatische Weiterschaltung oder automatische / manuelle Türen zu ergänzen
- Einen Gang hinzufügen
- Höchstgeschwindigkeit verändern, um Spaß zu haben
Bei den Karten sieht es ähnlich aus:
- Performancefressendes Objekt entfernen
- Aus dem realen AddOn seiner Lieblingsstadt die Straße, in der man wohnt, ergänzen
- Nervige Engstellen entfernen
- Schwierigkeiten hinzufügen (Engstellen, parkende Autos)
- Karten auf eigene Faust verschönern, weil einem die Gestaltung nicht gefällt
- Texturen austauschen weil man mit einer Grastextur auf Kriegsfuß steht
- Eine halbfertige und unvollendete Karte weiterbauen weil es zu schade wäre, sie wegzuschmeißen oder der Autor sich zurückgezogen hat, gesagt hat "macht was ihr wollt" aber die jeweilige Einstellung (Public Domain) versäumt hat
- Linien woanders hin fahren lassen oder Fahrpläne verändern, wie Schleswig-Holstein es macht (gut, dieses Feature ist noch nicht fertig, kann man also wenig darüber sagen)
Kurzum: Alles was nicht niet- und nagelfest ist, nach eigenem Ermessen anpassen. Die Modbarkeit von LOTUS lässt zu wünschen übrig, weil sie zu eingeschränkt ist. Und damit meine ich explizit "Modding" im engeren Sinne, also Veränderung von bestehendem Content.
Man muss sich darauf verlassen, dass der Ersteller des Fahrzeugs einen Slot anbietet
Auf gut Deutsch: Wenn einem etwas nicht gefällt, muss man sich darauf verlassen, dass der Fahrzeugbauer vorher weiß, dass es nicht gefallen könnte und zu einem Modul macht. Was Alper da macht, ist zwar gut und schön, aber ich denke, die meisten Erzeugnisse werden doch in ihrer Modularisierbarkeit sehr dürftig ausfallen.
Die Anzahl an Tram-Enthusiasten, denen die Grafik und Performance komplett egal ist, hält sich in Grenzen. Nur sich auf diese Zielgruppe zu versteifen, halte ich für falsch. Nicht jeder Simulator braucht Raytracing und dergleichen, klar. Aber ein gesundes Mittelmaß aus Simulation und Spielspaß (dazu gehören nunmal die Anzahl Abstürze, die Ruckler und die Grafik!) wäre nett.
Aber bei Omsi ist es doch genauso ? Omsi hat doch seit jeher nicht die Grafik gehabt, die es vielleicht bei der Konkurrenz gab. Auch Omsi hat sich auf eine Zielgruppe versteift. Trotzdem sind wir hier alle zusammengekommen
Du vergisst, dass wir uns fast im Jahr 2021 befinden und da hat man erstens einen anderen Anspruch als an ein Spiel, deren Hauptversion von 2011 ist; zweitens sind auch die PCs deutlich besser geworden.
großen, treuen und v.a. leidensfähigen
Du hast "zahlungskräftig" vergessen.
Ohne genaue Statistiken o.ä. zu kennen, denke ich, dass etwa 80% der LOTUS-Kunden von OMSI gekommen sind. Außerhalb der OMSI-Community ist LOTUS ein nicht ganz ernst genommener Witz größenwahnsinniger Entwickler.
dass Trams möglich sind
Waren sie in OMSI auch - kritische Zungen behaupten bis heute, dass dieses Feature mutwillig entfernt wurde, aber das soll jeder für sich selbst entscheiden.
Fahrzeug- und Mapeditoren sind dort in Planung und Arbeit!
Da muss man allerdings auch so fair sein und TML das selbe vorwerfen wie Oriolus: Versprechen kann man viel, es zählt die Umsetzung.
-
Du kannst nichtmal Objekte hochladen, bei welchen du nicht als Entwickler eingetragen oder copyrightfrei hochgeladen wurden. (=damit mein ich die einzelnen LCT-Container, aus dem Workshop kannste alles verwenden)
Das System ist prädestiniert dazu, dass jemand aus Frust seinen Content aus dem Workshop herunternimmt und dann möglicherweise hunderte Karten auf einen Schlag unbrauchbar werden. Anders als bei OMSI, wo es auf der OWD hier nahezu perfekt funktioniert: Die Ersteller von Objekten erlauben, dass ihre Sachen mitgeliefert werden und die Karten liefern den benötigten Content mit. Wenn jetzt beispielsweise ein Oberpfalz 3D alle seine Sachen runternehmen würde, passiert nichts. Eine solche Situation in LOTUS ... nicht auszudenken. Jahrelange Arbeit umsonst.
Lotus ist allgemein extrem copyright-sicher.
So würde ich das nicht sagen. Closed-Source führt nur dazu, dass findige Leute andere Wege suchen. Mit der Zeit werden sich Plattformen etablieren, die Content vorbei am Steam-Workshop anbieten. Wie gesagt, hat alles seine Berechtigung, aber das ganze Content-System ist aus meiner Sicht einfach nur der Versuch, maximale Kontrolle auszuüben. Ob das jetzt unbedingt förderlich ist für Modding sei dahingestellt.
Bestes Beispiel: Microsoft. Jahrelang dafür bekannt, Software unter Verschluss zu halten und zu beschränken.
Soweit ich das verstanden habe, wollte man einfach nicht, dass dann für sämtliche Karten nach zusätzliche, Paywarekosten anfallen. Was man irgendwo ja auch verstehen kann.
Kann ich persönlich leider nicht verstehen. Als Kartenentwickler baue ich doch vor allem für mich selbst, weil es Spaß macht und wenn ich meinetwegen bei Düsseldorf ein cooles Objekt sehe, was genau zu der einen Stelle passt - warum nicht?
Ich denke, was die Bäume angeht, macht Florian da schon echt gute Arbeit. Vor allem die letzten Überarbeitungen gefallen mir zumindest extrem gut.
Ohne Zweifel, die sehen super aus. Aber was die Performance davon hält (im Zusammenspiel mit den noch fehlenden Features), ist noch nicht abschließend geklärt.