https://live.dovetailgames.com…ulator-classic-the-future
Vielleicht mal interessant zu lesen für Interessierte.
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:
= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! -
-
OMSI ist zum Teil einfach ein Rätsel.
Eigentlich nicht. OMSI ist ein sehr deterministisches Computerprogramm, was sich immer genau gleich verhält. Der Casus knacksus ist hier zu 95% der User:
- Vermurkste Verzeichnisse (z.B. Objekte, die eigentlich in andere Ordner gehören oder Texturen, die überschrieben wurden)
- Zusatzcontent vergessen
- Optionen anders als bei Testern (hier: Kollision an/aus)
Musste sein.
-
Zu den Texturen: Frei Schnauze skalieren ist kein Problem. Kannst die Textur beliebig skalieren. Auch wenn die Bildtextur dann eigentlich verzerrt wäre, solange an den Model-Dateien und an dem Textur-Mapping in Blender nichts geändert wird, bleibt es in OMSI "schön". Wenn kleinere Pixelfehler auftreten, kann man die in der Regel mit nem manuellem Pinsel beheben, der ne zusätzliche Streuung (dunkler/heller mit Transparenz) hinzufügt.
Du kannst es gerne bei dir ausprobieren, ich kann dir eine .sco schicken zum testen.
Leider nicht, habe OMSI nicht installiert und nicht vor, es wieder zu installieren.
Was die Haltestellen angeht. Die sind ja von Zane. Da darf ich eigentlich nicht dran rumspielen.
Das ist natürlich blöd ... Passiert immer wieder. Eventuell kannst du ja ne eigene SCO anlegen (Schöpfungshöhe dürfte gering sein, da Klartext) und daraus dann die originalen Model-Dateien referenzieren (statt dings.o3d mit einem Präfix: ..\..\OriginalOrdnerVonSceneryobjects\o3d\dings.o3d, falls es nicht klappt, mal rumspielen mit verschiedener Anzahl von ..\). Soweit mir bekannt, ist Zane aber auch nicht mehr aktiv.
-
Zumindest wenn man im Editor die Bounding-Boxen sichtbar macht
Das sind zwei unterschiedliche Sachen. Die Bounding Box spielt eine Rolle für die Bestimmung, ab wann ein Objekt sichtbar ist (vgl. Einstellungen mit x Prozent Mindestsichtbarkeitsgröße). Standardmäßig verwendet OMSI zur Kollision die Bounding Box. Wird aber [collision_mesh] benutzt, wird das angegebene Mesh zur Kollisionsberechnung genutzt, nicht die Bounding Box.
Edit: Was mir aber auch auffällt ist, dass die Bounding Box der Haltestelle um 90° gedreht sein dürfte. Was auch immer der Grund dafür ist, wenn das Ding richtig herum gedreht wäre, bräuchte man zumindest für die Haltestelle (die ja oft vorkommt) kein komplexes Kollisionsmesh mehr (Performance!), sondern könnte es bei der Bounding Box belassen.
-
Da es prozentuale Werte ist, stört das falsche Seitenverhältnis nicht. Ne 671x458-Textur kannste z.B. ohne Probleme in paint.net über "Größe ändern" einfach auf 512² ziehen.
PS:
[nocollision] ist eigentlich nur ein Workaround. Die "richtige" Lösung wäre, [collision_mesh] (vgl. Kreuzungsobjekte, nur ohne surface-Einträge), gefolgt vom Mesh einzutragen. Standardmäßig macht OMSI einfach ein großes rechteckiges Kollisionsmesh um das Objekt herum, was bei zusammengefassten Häuserzeilen natürlich nicht richtig ist.
Hab den Überblick verloren, Busfahrer1991 das mal ausprobiert?
Zur restlichen unsachlichen/negativen/...-Kritik: Typisch Internet. Früher hab ich mal gedacht, diese Korinthenkackerei ist eine spezielle Spezialität der OMSI-Community. Mittlerweile weiß ich aber, dass wir damit nicht alleine sind. Jeder muss heutzutage seine 2 Cents in die Welt posaunen.
-
Ich empfehle Dir/Euch dringend, die verbauten Objekte, hinsichtlich Kollisionen, nochmals zu prüfen und zu testen.
Mich wundert bloß, dass es weder bei mir persönlich noch bei den Beta-Testern als Problem aufgetreten ist
Weil viele mit deaktivierten Kollisionen fahren
[nocollision] ist eigentlich nur ein Workaround. Die "richtige" Lösung wäre, [collision_mesh], gefolgt vom Mesh einzutragen. Standardmäßig macht OMSI einfach ein großes rechteckiges Kollisionsmesh um das Objekt herum, was bei zusammengefassten Häuserzeilen natürlich nicht richtig ist.
-
Warum entwickelt man etwas, wovon offenbar unkundige Entwickler glauben, dass es erfolgreich sein könnte statt etwas herzustellen, was die Leute wirklich wollen?
So läuft Softwareentwicklung.
Bei Erscheinen von TramSim hatte ich ja noch die Hoffnung, dass das Ding ausgebaut wird in Richtung Bussimulation
Da war nichts zu erwarten. Es gibt bereits einen Bussimulator auf gleicher technischer Basis. Was ich gehofft habe, dass sich TML und TramSim zusammentun. Die Grafik vom TramSim finde ich persönlich schöner und nicht so effekthascherisch als TheBus. Man könnte sicherlich voneinander lernen. Umgekehrt auch, da TML wesentlich mehr Erfahrung mit der Engine hat.
Ein Bussim mit besserer Grafik und weniger Möglichkeiten als OMSI
Ich glaube, dass da in Richtung Modding Tools noch mehr kommen wird. Der Karteneditor ist ja erst der Anfang und mit der mächtigen Engine kann man quasi wie OMSI alles machen, was einem lieb ist.
-
Stimmt nicht mehr fps! es ist mehr, dass 64 eine bessere Verarbeitung schaffen kann. nicht so viel fps aber mehr prozessorkerne und nicht wie omsi wo die nutzung der prozessorkerne nicht optimal ist und einen großen teil ungenutzt lässt was in heutigen pc möglich ist
64Bit hat mit Prozessorkernen nichts zu tun. Der einzige Vorteil besteht darin, dass man mehr Daten im Arbeitsspeicher halten kann. Das bringt genau dann etwas, wenn Caching so effizient programmiert ist, dass der volle Platz genutzt wird. Während man spielt, darf ruhig der komplette Arbeitsspeicher genutzt
Anekdote: Viele meckern ja immer über den Chrome, der viel RAM verbraucht. Genau das führt aber zu der guten Geschwindigkeit. Alles, was im Arbeitsspeicher ist, muss nicht von der viel langsameren Festplatte oder gar aus dem Internet nachgeladen werden.
-
hoffe ich, dass Steam den Spielern eine Rückerstattung gibt, es ist ein Betrug.
Eher nicht. Du hast das bekommen, was du bezahlt hast.
32 or 64bits won't make much of a difference. Either your piece of software runs good or it doesn't. Having extra addressable memory isn't the solution.
+1 from a view of a professional software developer.
Willfully "killing" OMSI (...) One could hope (or rather dream) of a little quality of life patch for OMSI
The situation is a bit more complicated ... One hears that OMSI can no longer be further developed due to legal difficulties (the original development team has split up, but was jointly responsible for the development).
-
Achte darauf, dass der letzte Pfad bei der Hinfahrt und der erste Pfad der Rückfahrt (bzw. der letzte Pfad der Rückfahrt und der erste Pfad der Hinfahrt) derselbe sind. OMSI braucht eine Überlappung um genau ein Pfadsegment, damit der Übergang zwischen zwei Trips richtig erkannt wird.
-
Und doch fand ich neue Wege richtig. Man kann nicht an Omsi flickschustern und gleichzeitig etwas neues entwickeln. Vor allem nicht, wenn einer der beiden Entwickler von Omsi fehlt.
+1. Man kann OMSI grundsätzlich nicht mehr "flickschustern". Die technische Basis ist hoffnungslos. Auch wenn OMSI eine mächtige Scriptengine hat, mit der man alle möglichen Sachen machen kann (in umgekehrter polnischer Notation, wohlgemerkt!), es ist hoffnungslos. Mit LOTUS hat man aber wieder nur alten Wein in neue Schläuche gefüllt:
- Die Engine limitiert. Aus welchem Grund auch immer. Performancetechnisch ist LOTUS genauso Müll wie OMSI.
- Pascal als Skriptengine ... Was zur Hölle!? Damit wird man nie und nimmer gute Modder außerhalb der Community gewinnen.
- Zugriffsverletzungen, Abstürze ohne Kommentar ... Excuse me, wir haben 2023. Es kann doch nicht sein, dass ein (vor mehr als 5 Jahren) neu entwickeltes Spiel (immer noch) so vor Fehlern und Abstürzen strotzt. Das ist nicht normal. Da ist bei der Programmierung grundsätzlich was schief gelaufen.
- Tools - Wo Benutzbarkeit ein Fremdwort ist. Funktionen, schön und gut, aber die LOTUS-Tools sind mit Funktionen so aufgeladen, dass sie zu einem losen Haufen von Eingabefeldern werden, für die man tagelang in Handbüchern stöbern muss. Der Anspruch ist, dass man möglichst alles simulieren möchte, was geht, trotzdem sind viele Sachen unausgereift und es fehlt dann doch immer noch was.
Warum gibt so wenig Content? Warum läuft die Entwicklung von Projekten so langsam voran, dass 500m Karte ein nennenswerter Forschritt ist, über den es sich lohnt, zu berichten? Es ist nicht so, dass niemand Interesse hat, aber sehr sehr viele User scheitern an den Tools. Wie lange braucht man für einen Kilometer Straße mit ein paar Kreuzungen und einer kleinen Linie mit Fahrplan? Noch dazu kommen die Lade-, Warte- und Rumrechzeiten des Map-Editors, die jenseits von Gut und Böse liegen und ebenso nervige Workarounds. Das "Neuberechnen" wirkt als wäre es ein Selbstzweck. Rechnen, um des Rechnens willen (Energieverbrauch?). Die ganze Zeit, die man mit alldem verbringt, kann man eigentlich nur leisten, wenn man dafür eine Gegenleistung erwartet (wo wir bei kommerziellen DLCs wären). Jedoch gibt es nach wie vor niemanden, der sich außerhalb der Bubble dafür interessiert.
-
Der Streckenbau ist nun auch keine kleine Aufgabe. Vorallem nicht, wenn man einmal hochrechnet, wie viele Objekte für die M1/den 100er notwendig sind. Ich würde behaupten wollen, dass wir da über 10.000-15.000 Objekte sprechen, die vielleicht nicht alle originalgetreu, aber zumindest der Szenerie entsprechend entworfen werden müssen.
Wenn man es nach "alter Schule" (Textur fotografieren, händisch aufbereiten, Gebäude ausmessen, modellieren usw.) macht, schon. Aber mittlerweile gibt es (KI-gestützte) Möglichkeiten, das ganze zu automatisieren. Man macht ein paar Fotos, gibt evtl. noch ein paar Eckdaten dazu und schon hat man ein virtuelles Modell, mit dem man weiterarbeiten kann. Microsoft hat mit dem Flight Simulator gezeigt, was alles möglich ist, allein basierend auf Kartendaten und Luftbildern. Wie es ungefähr funktioniert, wird hier (am Beispiel einer S-Bahn für ein Train-Simulator-AddOn) gezeigt. Das Problem ist halt: Die Technik ist noch nicht erschwinglich und für die breite Masse nutzbar.
Wenn man sich Bildgeneratoren etc. so anschaut, könnte es in ein paar Jahren so weit sein, dass ganze Objektserien (z.B. "Moderne Vorstadtvilla") per Knopfdruck erzeugt werden.
Was LOTUS betrifft, ich persönlich glaube, das Entwicklerteam würde gut daran tun, die "einfachen" Arbeiten (vor allem 3D-Objektbau) anderen Personen zu überlassen, um Kapazitäten für die Engine zu bündeln, denn daran scheitert LOTUS aktuell gnadenlos. Andererseits tut man ja schon genau das, mit der Folge, dass der sogenannte "BaseContent" ziemlich fragmentiert ist, es keinen zentralen Ansprechpartner dafür gibt und die Qualität je nach Person und Alter stark variiert. Es wirkt irgendwie so, als würde der Content auf die Community abgeladen werden. Auch wieder doof ...
-
Sofern die Zahlen von Steam DB stimmen, sind es nicht wirklich viele Spieler.
Peak Mai 2022 mit 78 und aktuell um die 15 in der Spitze.
OMSI recht kontinuierlich 1400 am Tag. Peak war im Dezember mit 2.300 im letzten Jahr.
Da spricht schon Bände.Nicht nur die Spielerzahlen, sondern auch die Aktivitätszahlen der Community (z.B. Anzahl aktive User in einschlägigen Foren, Beiträge pro Tag) und in Steam (Anzahl Reviews, Follower) sprechen Bände.
-
die eierlegende Wollmilchsau
Was Rechenleistung (unter der Annahme, dass sie begrenzt/teuer ist) und Performance angeht, widersprechen sich nicht nur Flug vs. ÖPNV, sondern auch Zug (im Sinne von ÖPFV; soll durch LOTUS ja auch umgesetzt werden) und ÖPNV.
- Bei einem Flugsimulator braucht man eine hohe Sichtweite (insb. Lichtpunkte auf der Landebahn bei Dunkelheit & Nebel) und eine gute Windphysik. Außerdem ist es essenziell, dass die Umgebung schnell nachlädt (aufgrund der hohen Geschwindigkeit). Dafür kann man die Oberfläche vernachlässigen (Terrain braucht außerhalb von Flughäfen nur eine geringe Texturgröße) und KI (ob ein Auto beim Bremsen jetzt nach vorne wippt, sieht man eh nicht, genauso detaillierte Straßenmarkierungen und Spurwechsel an Autobahnkreuzen etc.).
- Bei einem Zugsimulator braucht man immernoch mehr Sichtweite als bei einem Bus-/Tram-Simulator und schnelles Nachladen, aber weniger davon. Die dadurch freiwerdende Rechenleistung kann man z.B. in Oberleitungssimulation, KI, Physik (ohne Wind, dafür z.B. mit Schleudereffekten bei nassem Laub) und Oberflächentexturen (Schienen, nahe Landschaft) stecken. Auch hier spielt aber z.B. eine komplexe Auto-KI (Spurwechsel, Staus etc.) weniger eine Rolle.
- Bei Tram und Bus ist schon die Geschwindigkeit eine ganz andere. Das heißt, das Nachladen kann langsamer passieren, außerdem kann die Sichtbarkeit eingeschränkt werden (oft sieht man wegen Kurven eh nicht um die nächste Ecke herum). Die freiwerdende Leistung kann man in Terrain (auf dem man ja immer fährt) und komplexe (Auto-)KI stecken, die gerade am Boden ausgefeilter sein darf. Und Menschen, die dort herumlaufen.
- Bei der [reinen] U-Bahn kommt im Gegensatz zu den vorherigen Kategorien noch das Spiel mit Licht & Schatten dazu. Dafür muss man sich unter der Erde nicht mit Wind & Wetter beschäftigen und Ampeln für Fußgänger wird es wohl auch kaum zu modellieren geben.
-
-
Es gibt mehrere Haken. Einen für das Forum, einen für das Wiki und einen für den Info-Bereich. Der Haken funktioniert nur in dem Bereich, wo man gerade ist.
-
Schau mal hier: Plug-in-Schnittstelle
-
Du benutzt höchstwahrscheinlich einen VPN.
-
wie soll man allein mit Scripten die Kollision mit der Spurführung abfragen?
In der 2.2 könnte man das wahrscheinlich mit GetHeightAbovePoint lösen, wie man es bei Stromabnehmern für Straßenbahnen gemacht hat. Bleibt allerdings die Frage, ob das in der 2.3 noch so funktionieren würde, ich nehme mal an nein..
Ich glaube, die 2.3 ändert das nur für Schienenfahrzeuge.
-
Nach meiner Kenntnis haben die Height-Profiles keinen Effekt (oder nur auf die Fußgänger). Ich bin mir nicht sicher, ob es [nocollision] auch für Splines gibt. Ansonsten ne Lösung, die definitiv funktioniert: Nur die Grundfläche als Spline und die "Wände" als Objekt mit nem separaten Kollisionsmesh (oder deaktivierter Kollision). Oder halt die Straße so verbreitern (sieht zwar etwas unrealistisch aus, aber was soll's...), dass man halbwegs gut fahren kann. Und wenn man dann an den Bordstein kommt, ist die Kollision halt ein "Feature"
