LOTUS Simulator

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!
  • Hm? Irgendwie ist das Zitat von B&B mir zugeordenet worden? Wie kann denn das passieren?


    Ich habe B&Bs Post zitiert und plötzlich stand da "Perotinus" drüber, obwohl korrekt zitiert wurde. Keine Ahnung wie das passiert ist, aber ich habe es manuell korrigiert.


    Neuigkeiten über das Aerosoft-Ding würden mich auch interessieren, zumal dem einen Foto nach zu urteilen die Entwicklung den Kinderschuhen reichlich entwachsen sein dürfte. Vielleicht ist es aber auch besser sich da erstmal bedeckt zu halten, bis wirklich etwas präsentierbares da ist. Oder man verfolgt diese Diskussion (und andere) aufmerksam, um aus den Fehlern anderer Entwickler zu lernen. Das wäre ja geradezu traumhaft: Spielend einfach zu bedienender Editor, volle Omsi-Kompatibilität, Frameraten von 100fps auf jedem PC, Echtzeitreflexionen, realistische Sonnen-und Regeneffekte, realistisch funktionierende KI, realistische Fahrzeugphysik, distant terrain, gern ohne Leiststellengedöns und Aufgaben.... Achja, wie schön das wäre!

  • Hm? Irgendwie ist das Zitat von B&B mir zugeordenet worden? Wie kann denn das passieren?


    [...]

    :/


    Ohne die beiden in Schutz nehmen zu wollen, aber als ehemaliger Selbständiger weiß ich, was ein Burnout it. Wenn Du tagein, tagaus ohne feste Arbeitszeiten oder Urlaub vor derselben Arbeit sitzt und nicht rauskommst, bist Du irgendwann hinüber und brauchst eine Auszeit, vor allem auch bei dieser teilweise geistig sicherlich sehr fordernden Arbeit. Wir wissen ja auch durch unsere private Tätigkeit für Omsi, dass irgendwann die Motivation weg ist und man einfach mal 1-2 Wochen (oder auch mehr) etwas anderes braucht, um neue Kraft und Lust zu schöpfen oder einfach das schöne Wetter zu genießen.


    [...]

    Meine IBIS Um- und Einbauten habe ich in den letzten Tagen auch nächtlich bis morgens um 03:30 Uhr hingefummelt - der Großteil meiner Arbeitsleistung im Studium entstand auch immer nachts... ^^^^ Von daher bin ich da irgendwie drin.


    Ja, aber du hast recht. Auch wenn das hart klingt, so ist in heutiger Zeit aber leider das Schuften knapp an der Leistungsgrenze aber leider einfach Normalität geworden. Zumindest in Jobs, wo das persönliche Potenzial groß ist.


    Sicherlich hat die Selbstständigkeit viele Vorteile - aber eben auch Nachteile gerade bei der Arbeitszeit... Irgendeinen Tod muss man dann auch sterben. ;)


    LOTUS ist vom geplanten Umfang eben auch eine hohe Herausforderung. Ohne Frage. Aber wenn man die Simulation in dem Umfang plant, dann sollte man sich eben auch damit abfinden müssen, das man Zeitpläne braucht und diese auch einhalten muss oder sollte - und dann endet der Arbeitstag idealerweise nicht um 16 Uhr, sondern irgendwann nachts und beginnt am nächsten Tag im frühen Morgen. :) So ist das dann leider... Ich glaube nämlich, dass die Fertigstellung von LOTUS gar nicht mehr beziffert werden kann, weil sie irgendwann in dem kommenden Jahrzehnt oder darüber liegt. ;)

    "Selten ein Schaden, wo nicht auch ein Nutzen ist."

  • Vielleicht kommt neben TheBus auch noch TheTram raus ^^


    Wenn es allerdings mod-mäßig so beschränkt sein wird wie andere Produkte, dann wird da, außer offiziellen DLCs, wahrscheinlich auch nicht viel kommen und zumindest in der Hinsicht, und möglicherweise in Sachen Physik, keine Gefahr für LOTUS darstellen.

  • 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.

  • Nie wurde das Spiel effektiv für die Community erweitert, das passierte nur weil es für Payware gebraucht wurde.

    Das ist der springende Punkt. In Omsi wurde nur das umgesetzt, was M+R gebraucht wurde (Beispiel: nur ein Entwerter pro Fahrzeug). Einige andere Sachen, wurde von M+R nur umgesetzt, wenn es von Payware-Entwicklern gebraucht wurde. Egal welche Ideen oder Vorschläge aus der Community kamen, fand bei Marcel keine Ohr und kein Auge. Und der größere Content für Omsi, kamen von der Community.


    Und da wurde ganz am Anfang auch beworben. Erinnert ihr euch noch: OMSI, weils geht. Omsi sollte ein modifizierbarer Simulator werden. M+R wollten mit der Community zusammen, einen Simulator entwickeln, der fast alles möglich macht. Die Realität sah aber anders aus. Nur eine Fragerunde an den Entwickler Marcel, wünsche der User für Omsi wurden entweder versprochen, aber nicht gehalten oder auch ignoriert.


    In Lotus wird aber gleich von vornherein, der Riegel vorgeschoben. In Omsi mußten viele User, erst mal sehr vieles rausfinden, wie etwas umgesetzt wird. Möglich war dies, weil man in die Busse von M+R reingesehen hat. Marcel und Rüdiger beantworteten nur Anfangs die Fragen der User.

    Und genau das wird sich in LOTUS wiederholen. Support kommt dann nur von den Usern, aber kaum vom Entwickler.


    Man kann bei der Programmierung sicher nicht an alles denken, muß man auch nicht. Dafür gibt es die Community, die man nur fragen muß, was noch fehlt. Es gibt im Internet so viele Mechatroniker, Schloßer und auch Busfahrer, die man über technische Gegebenheiten befragen kann. Man muß nicht alles wissen, solange man weiß wo man fragen kann.



    Es ist auch nicht zwingend erforderlich, einen Simulator zu verkaufen, der absolut perfekt ist (was nicht geht). Es ist doch vollkommen ausreichend, eine Simulator zu erstellen, der vieles noch offen läßt. Den Rest kann man mit der Zeit und der Community entwickeln.

  • In Lotus wird aber gleich von vornherein, der Riegel vorgeschoben. In Omsi mußten viele User, erst mal sehr vieles rausfinden, wie etwas umgesetzt wird. Möglich war dies, weil man in die Busse von M+R reingesehen hat. Marcel und Rüdiger beantworteten nur Anfangs die Fragen der User.

    Und genau das wird sich in LOTUS wiederholen. Support kommt dann nur von den Usern, aber kaum vom Entwickler.

    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...)

    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.

    Als Entwickler muss man sich immer die Frage stellen, wie viel Offenheit möglich und wie viel nötig ist (mal abgesehen vom Container-System was ich persönlich Mumpitz finde, hatte ich ja schonmal gesagt...). Ein Spiel sollte so offen wie möglich sein, damit möglich viel umsetzbar ist, aber nur so offen wie nötig sein, damit es nicht zu komplex wird.


    Jetzt mal ehrlich, niemand will ein Spiel, was physikalisch und technisch so komplex ist, dass alles umgesetzt werden kann, die simpelste Physik aber schon zu schwierig umzusetzen ist, weil man zu viele Parameter eingeben muss. Man kann in Sachen Modding NIE die eierlegende Wollmilchsau erwarten. Irgendeine Beschränkung gibt's immer.


    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.

  • 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.

    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.