Beiträge von Chrizzly92

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!

    Die Source-Engine hat damit aber auch Probleme, zumindest vor 1-2 Jahren war das so. LOTUS steht da also nicht allein da. Aber klar, in Zeiten wo quasi jedes Mainboard nen Anschluss für nen Bildschirm und fast jeder Prozessor ne APU hat, sollte das zu keinen Problemen mehr führen.

    Ich hätte die Fahrgäste auch gern mal getestet, bei mir ist LOTUS allerdings unspielbar.

    warum nicht? Es ist doch richtig und wichtig pro und contra abzuwägen, vorallem für zukünftige Projekte. Seit wann ist überall diese "naja ist halt so" Einstellung modern? Bin vermutlich als Ossi hier einer der wenigen die nicht diese larifari Einstellung haben.

    "Wir erhöhen die Steuern um 20%" "Naja ist halt so, haben sich dazu entschieden dann soll es so sein, steht mir auch nicht zu drüber zu Urteilen." Klar, im Falle von LOTUS ändert eine Diskussion darüber nix aber alles überall einfach "wegzuignorieren", "es leid zu sein" ist doch wohl auch keine Lösung. Dann kann man auch einfach gleich jegliche Kommunikation unterbinden, sich nen Joint anzünden und auf alles scheißen.


    Das ist überhaupt kein Argument, um auf eine eigene Engine zu setzen. Das ist vielmehr ein Ausblick, warum es sinnvoll sein kann.

    Ich glaub wir reden aneinander vorbei. :D


    Das Ding mit der eigenen Engine verstehe ich bis heute immernoch nicht,[...]


    Im Endeffekt gar nicht blöd, weil du an keine Limitierung gebunden bist. [...]


    und das ist man beispielsweise bei der UE4 auch nicht. Spurcecode und co. verfügbar, man kann sie auf die eigenen Ansprüche anpassen. Das Rad neu erfinden ist nicht immer notwendig.

    Zu sagen, ne eigene Engine ist gar nicht blöd weil du keine Limitierungen hast ist sehr wohl nen altbackenes Argument. Bei SCS macht die eigene Engine auch nur Sinn, weil Sie seit Ewigkeiten in Entwicklung ist und vorallem gepflegt wird, in einer vernünftigen und Zukunftsorientierten Sprache (C++). Iirc wurde die SCS Inhouse Engine seit irgendeinem 18 Wheels of Steel genutzt und das ist bestimmt 15 Jahre her, dazu kommt die Zeit der Entwicklung vor Veröffentlichung. Das ganze als Ein-Mann-Team zum stemmen in so kurzer Zeit kann mMn. nichts werden.
    Klar, wenn du nen großes Studio hast macht eine eigene Engine Sinn, schon allein weil bei vielen freien Engines Gebühren anfallen. Oriolus würd ich aber nicht als großes Studio bezeichnen wo genug Kapazitäten für die Entwicklung bereitstehen.


    Edit: 2006 war das. Also 14 Jahre + Entwicklung vorm Release.

    Im Endeffekt gar nicht blöd, weil du an keine Limitierung gebunden bist. Du kannst das ganze grenzenlos erweitern und immer neue Dinge implementieren, ohne irgendwann halt machen zu müssen. Die Idee dahinter kann ich nachvollziehen und finde ich auch gut, jedoch scheitert so ein Prozess oftmals an fehlender Optimierung. Eine etablierte Engine mag zwar auch hier und da Performanceprobleme haben, aber eine eigene Engine erfordert viel mehr Anpassung und Optimierung, als andere - die dann auch dieser Entwickler ausbügeln muss.


    Ich bin halt der Meinung: Bevor man Gameplay bastelt, sollte die eigene Engine optimiert und angepasst sein. Hinterher wird die Chose nur noch ein Krampf.


    Das ist aber auch nen altbackenes Argument. Für die UE4 ist beispielsweise der Sourcecode öffentlich zugängig und lässt sich von jedem der Will entsprechend anpassen und optimieren.

    Komisch, im Logfile steht nichts auffälliges. Und ich habe so etwas auch noch nie erlebt.

    doch da steht was Auffälliges, Zeile 253:


    Code
    01:26:50 -  -   Error:           Fehler: im Befehl "(C.L.antrieb_getr_autoSwUpMaxSpd4)" (vehicles\London Citybus 200\\script\C200_main_AI.osc) <SC_ErrorInCommand_constantinvalid>


    Das kann durchaus ursächlich für den Fehler sein.

    Und wie Chrizzly sagt, man muss die verwendete Bildschirmauflösung in Verhältnis zur Textur bzw. Objektgröße sehen. Otto-Normaluser fährt wahrscheinlich immer noch in FullHD, Rest verteilt sich wohl auf 1440p und 4K. Jetzt nehmen wir mal an jemand mit 1920x1080 hat auf seinem Bus eine 4K Textur für die Außenwerbung. Wie viel Unterschied würde er also sehen wenn der Bus vor der Nase ist im Vergleich zu einer 2K Textur? Wohlgemerkt vor der Nase, über weiter weg möchte ich garnicht reden;-)

    Aber auch für niedrigere Bildschirmauflösungen machen hochaufgelöste Texturen sinn - und zwar dann, wenn man bei einem Bus mal an die Front ranzoomt um Logos vom Verkehrsunternehmen oder sowas zu sehen. Lochfolie auf Scheiben ist dafür auch ein gutes Beispiel.

    Trotzdem sind diese mittlerweile der Standard und Grafikengines sollten solche Grössen ohne weiteres aushalten.

    Naja... wenns um Häuser geht seh ich das ja vielleicht noch ein. Aber nicht bei Gullideckeln oder sowas kleineres. Das nimmst du so gar nicht war. Allgemein, und das ist meine Meinung, ist der Unterschied zwischen 4k und 8k nicht ausreichend groß, was die 4fache Texturgröße nachvollziehen lassen.

    du hast zwar Grundsätzlich recht, das ist dennoch nicht die Schuld von Viewapp. selbst Wenn sie einen Gullideckel in 8K texturieren, liegts an der Engine, hier die passende LOD-Stufe zu schalten. Nehmen wir an, eine Hausfassade hat eine 2k-Textur gemappt. Schaue ich diese mit einem Full-HD bildschirm an, erreiche ich mit einer 4K textur keine bessere optik. stelle ich mich nun näher an das Gebäude, um - übertrieben gesagt - das klingelschild zu lesen, wäre diese 2k- Textur dann nur noch wischiwaschi pixelbrei. Liegt die Textur in 8K vor, so kann LOTUS doch bei der Vorbeifahrt einfach die 2K Textur darstellen, zoomt man ans gebäude ran oder läuft irgendwann im Egomodus vorbei, werden die LOD Stufen durchgeschalten und gut ist. Das setzt natürlich vorraus, dass das Pipelining der Texturen vernünftig programmiert wurde und LOTUS sich nicht beim Laden verschluckt.

    Das ist ein weiterer Kritikpunkt am TramSim. Ich persönlich hätte es schöner gefunden, zwischen zwei Modi zu unterscheiden:

    Selbiges zu implementieren halte ich für nicht besonders aufwendig - wie erwähnt taten das TML-Studios auch bereits. Ich kann mir vorstellen, dass man in der Hinsicht auf den Wunsch der community eingeht, den ich schon öfters las.


    In wie weit TramSim und TheBus durch ihre Engine voneinander profitieren können, kann ich nicht beurteilen.

    Chrizzly92, du hast doch meines Wissens nach ein bisschen Erfahrung mit Blueprints und dergleichen. Kannst du, falls du Zeit und Lust hast, erläutern, ob dies theoretisch sinnvoll oder realistisch ist? Voraussetzung wäre natürlich auch das jeweilige Interesse des Entwickler(studio)s.

    Ich nehme an, das wirds auch noch geben. Aktuell gibts ja nur ein Fahrzeug und eine Strecke - nach einmal fahren gäbe es kein Ziel und die langzeitmotivation wäre dahin. So hat man ein Ziel vernünftig an den Haltestellen zu halten, den Fahrplan einzuhalten und ordentlich zu fahren, um Punkte zu sammeln und weitere Features freizuspielen. Mit Modding, DLC's und co. wirds mMn. auch eine Sandbox geben.


    Rein vom Aufwand her sollte das kein Ding sein. Ich weiß nicht ob UI und Spiellogik in C oder Blueprint geschrieben wurden, hätte ich ein ähnliches System über Blueprint implementiert, wäre es ein leichtes einfach einen branch einzubauen a la "Sandbox?" Ja -> deaktiviere den Schnickschnack oder halt nein-> zähle punkte.

    Achja, die Aussage dass stabile 30 besser sind als schwankende 60 sollte niemanden dazu animieren da die Framerate zu locken. Das schafft nämlich auch längere Zeiten zwischen den Frames, wo zum Beispiel das Nachladen und vieles andere passiert, und das bremst man unter Umständen dann aus... Aber da sind wir schon inder OMSI-Esotherik drin;-D

    Tatsächlich ists aber in OMSI genau andersrum. liegt aber auch daran, dass OMSI sehr CPU-Lastig ist. begrenzt du die Framerate auf 30 FPS, hast du in OMSI spürbar weniger und schwächere Ruckler, weil mehr "overhead" für andere Berechnungen frei bleibt. :-)

    Du wirst auch keine RTX 3090 drinhaben sondern irgendwas, was halt "gerade so" für LOTUS ausreicht, da zum aktuellen Zeitpunkt deine Karte schneller ist als der Spielkern. Für die Optimierung des Spieles würde sprechen, dass sie dauerhaft auf 100% läuft, da LOTUS dann mehr Bilder bereitstellen würde als die Grafikkarte schafft. (natürlich nur wenn VSync deaktiviert)
    Eine 80-90% Auslastung ist dementsprechend mit einer 10-20% Auslastung gleichzusetzen.

    Nein, nur eine GTX 980. Perfekt optimiert ist LOTUS da definitiv noch nicht. Aber anfangs wurde die Grafikkarte bei mir nur zu ca. 50% beansprucht. Insofern merke ich da durchaus ein paar Veränderungen... Aber meine Einstellungen sind natürlich entsprechend der Leistung meines Rechners nicht auf'm Maximum, weshalb der Vergleich zu deiner Auslastung eh ein wenig hinkt.

    hat ja auch keiner das Gegenteil behauptet. Als die Spiegel implementiert wurden, war ich positiv überrascht wie gut das noch läuft. zugegeben, die GT6n hat auch nicht viele und viel zum Rendern gabs noch nicht, aber immerhin.
    Wenn LOTUS mehr braucht als dein Rechner zur Verfügung stellt, machts natürlich Sinn, die Einstellungen runterzuschrauben. Wenn die Hardware aber noch nicht ausgelastet wie in meinem Fall sehe ich es aber nicht ein die EInstellungen zu reduzieren, denn dann liegts nicht an der Hardware die limitiert sondern am Spiel.

    Das Problem hierbei ist das schon oben angesprochene Content-System. Die LOTUS-Entwickler können einem Entwickler jederzeit den Gar aus machen anhand der Content-ID. Eine alternative Plattform für LOTUS-Mods oder ein unabhängiger Vertrieb von AddOns wird also kaum möglich sein weil es am Ende dazu führen könnte, dass man das Spiel + evtl. AddOns ganz verliert wenn man sich auf solches Terrain begibt. Ob das jetzt gut ist (keine Copyright-Probleme mehr) oder schlecht (künstliche Beschränkung der Vielfalt, insb. für die internationale Community) sei an dieser Stelle mal dahingestellt.

    Das ist per EULA zudem untersagt. Einziger Vertriebsweg geht über Oriolus, alles andere ist Freeware oder nicht erlaubt. Es ist ein Leichtes, entsprechende Pakete per Update zu markieren und die Ausführung zu verbieten.


    TramSim hat seit seinem Release Probleme die einzelnen Teile des Flexity zusammen zu halten. Das ist für ein fertiges Spiel zum Vollpreis meiner Meinung nach keine gute Entwicklung.

    Nun, man kann das TramSim natürlich ankreiden. Ich möchte hier aber erwähnen, dass im Letzten Spiel von Marcel eine Gelenkphysik integriert wurde, die bei weitem nicht besser ist. Gibt genug Screenshots, die komplett Zerissene Fahrzeuge in OMSI zeigen - und ich brauch nur mal ne in LOTUS ne Weiche unter mir stellen und schon zerreißt meine Tram.
    Der große Unterschied ist hier folgender: bei Tramsim wird - zumindest gefühlt - geschaut, wo probleme liegen und diese werden behoben. LOTUS schleppt seit JAHREN!!!! Probleme wie das Settingsmenü mit, welches das Spiel freezed oder Probleme wie Hier , welche zwar über Workarounds zu funktionieren scheinen, aber im Endeffekt auch nur das Symptom unterdrückt und nicht die Ursache behebt.
    Fehlerhafte Spiele sind kein Problem - solang man die Probleme Zeitnah behebt, vorallem dann wenn es Gamebraker sind.



    Der Unterschied ist einfach der, dass TramSim die völlig fertige Unreal-Engine von Epic Games verwendet und LOTUS komplett von null mit eigener Engine entwickelt wird.

    Habe mit der (vergleichbaren) Unity-Engine ein relativ vollständige 3D-Spielwelt innerhalb von 1 Woche erstellt, was ohne fertige Engine das 10-50x an Zeit in Anspruch genommen hätte.

    Das kann mir als potentieller Spieler doch aber komplett egal sein? Für den Mathelehrer ist es egal, ob du deine Prüfung mit nem schönen Casio oder TI Grafikrechner bearbeitest oder dir nach open source plänen einen eigenen zusammenbastelst, solange das Ergebnis stimmt. Da kannst dann allerdings nicht sagen; "Herr Lehrer, ich muss meinen Rechner noch zusammenbasteln", während alle anderen schon ihre Prüfung abgegeben haben.


    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.

    Fairerweise muss ich hierzu erwähnen, dass ich diesen "Test" seit Release der ersten EA Version durchführe und von Anfang an ALLE Effekte, Slider, Einstellungen oder Werte auf das Maximum gesetzt habe, um sowohl die Hardware maximalst auszulasten und auch immer mit den gleichen Einstellungen testen kann. Es läuft mit Sicherheit besser wenn man die Einstellungen runter schraubt. Ein Titel aus 2018 sollte aber mMn. auf Oberklassehardware aus diesem Zeitraum auch mit den höchsten Einstellungen vernünftiglaufen. (GTX1070ti, i7 8700k, 64gb ram)

    Unter diesen Bedingungen langweilt sich tatsächlich ein Großteil meines Prozessors. von 12 logischen Threads kann ich bis auf 4 alle deaktivieren, ohne dass sich die Framerate ändert. Die Threads werden immerhin auf 4 logische Prozessoren verteilt. Die Auslastung meiner GTX1070ti auf Diorama unter "tu es nicht " lag zwischen 40 und 60%.
    Mit schwächerer Hardware wird man natürlich irgendwann einen Flaschenhals bilden, zum letzten Testzeitpunkt (als die Fahrzeug-KI implementiert wurde) war meine Hardware aber nicht voll Ausgelastet, dementsprechend limitiert sich die Engine noch selbst. Natürlich nicht absichtlich, aber die Grafikkarte kann halt kein Bild Rendern, wenn die Daten dafür noch nicht bereit sind.
    Das sieht man auch als Außenstehender oft in Youtube-Videos oder Bugmeldungen. LOD Stufen die nicht geladen werden, Fahrzeuge bleiben durchsichtig und und und - das sind alles Probleme, die durch eine Überforderung der Engine entstehen. Da nützt es nix, den besten Rechner zu haben, die Probleme treten trotzdem auf. Features, die nicht nutzbar sind, kann man auch gleich weglassen.

    Dazu muss ich sagen, dass sich das - zumindest bei mir - doch schon deutlich geändert hat. Meine Grafikkarte wird i.d.R. durchaus zu 80-90% ausgelastet.

    Generell läuft der LOTUS bei mir auch bei höheren Einstellungen ziemlich performant und besser als der OMSI. Wie allerdings oben schon erwähnt wurde, verhält sich das halt leider bei jedem anders.

    Du wirst auch keine RTX 3090 drinhaben sondern irgendwas, was halt "gerade so" für LOTUS ausreicht, da zum aktuellen Zeitpunkt deine Karte schneller ist als der Spielkern. Für die Optimierung des Spieles würde sprechen, dass sie dauerhaft auf 100% läuft, da LOTUS dann mehr Bilder bereitstellen würde als die Grafikkarte schafft. (natürlich nur wenn VSync deaktiviert)
    Eine 80-90% Auslastung ist dementsprechend mit einer 10-20% Auslastung gleichzusetzen.

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

    Ähm - warum wird dann nicht gleich die Möglichkeit implementiert, grundsätzlich jedes Mesh austauschen zu können? da generiert das content tool halt einfach eine "Wagenkasten.l3d", die man mit einem eigenen Container austauschen kann.
    Dass das Modding in der Form beschränkt wird und nur das explizit möglich ist, was der Entwickler erlaubt, ist so gewollt. Es gäbe genug Ansätze 100% modding zu ermöglichen ohne extra nachzufragen. Wenn also ein Entwickler nur bestimmte Sachen zulässt, wird er sicherlich nicht auf Nachfrage nachreichen.



    Edit: Framerate ist übrigens nicht alles. Klar sind 60 FPS schön, besser wären aber 30, dafür ohne Nachlader und Microruckler, um einen sauberen Spielfluss zu simulieren, vorallem im Hinblick auf VR. selbst wenn auf manchen Karten also Stellenweise 60 FPS erreicht werden, fühlt sich das Spiel noch lange nicht flüssig an und einiges an rechenintensiver Simulation fehlt ja auch noch. wurstbrot , deine Karte im Multiplayer mit einem Spielerfahrzeug mehr wird dir direkt ein anderes Erlebnis bieten.

    Solang du modifizierte Dateien nutzt, egal in welcher Form, kann ich dir leider nicht weiterhelfen. Wie oben schonmal erwähnt hat man in OMSI zu viele Variablen, die Fehler verursachen können - daran ist dann aber nicht das Add-on schuld.
    Teste das ganze mal auf einer sauberen Installation - am besten so, wie omsi_sw es beschrieben hat. Dann brauchst du dir auch keine Gedanken machen, dass eventuelle Änderungen deine anderen Modifikationen verändern. Sollte der Fehler dann immernoch auftreten, können wir eventuell weiter schauen. Der Fehler tritt nur lokal bei dir auf - also schließe bitte nicht deine eigenen Anpassungen oder Mods aus, Ursächlich zu sein. Wie gesagt - ein Fremdrepaint aus der Karte Liestal hat dafür gesorgt, dass die MAN Stadtbusfamilie nichtmehr spielbar war - wie sollen wir als Entwickler so was ausschließen können?

    Spieldateien überprüfen hat allerdings zur Folge, dass sämtliche Anpassungen von Dateien wieder hinfällig sind und ich trotz Sicherung alles anpassen muss.

    In einer derart offenen Umgebung wie OMSI kann ich als Entwickler des Fahrzeuges keinen Wert auf individuelle Bedürfnisse legen. Rein technisch reicht schon ein zusätzliches Zeichen in einem Font fürs Fahrzeug, um solche Fehler zu verursachen. die Karte Liestal hatte mal nen Repaint für die MAN Stadtbusfamilie mitgeliefert, mit welchem Diese nicht mehr Spielbar war. Um also Sicherzustellen, dass du den gleichen Datenstand wie alle anderen Hast, ist dieser Schritt notwendig um Benutzerfehler durch Modding o.ä. auszuschließen.
    Habe das ganze eben auch noch einmal selbst mit der Steam-Version übeprüft, keine relevanten Fehler, auch nicht im Logfile. Wenn du den Weg über die Dateiprüfung nicht nehmen willst, entferne den Haken beim Add-on München, warte Kurz, bis Steam die Daten entfernt hat und navigiere dann ins /Vehicles/ Verzeichnis, dort enfernst du per Hand den Ordner "Muenchen_MAN_LC" und den kompletten Inhalt. Dannach installierst du das Add-on über Steam neu, ohne dannach Repaints oder Mods hinzuzufügen und teilst uns mit, ob das Problem damit behoben ist. Nur mit einer sauberen Installation kann man Fehler durch dritte aussschließen.

    Wie oben geschrieben, stört sich Omsi auch nicht an den etlichen Zugriffsverletzungen. Es ist also kein Absturz u.ä. bemerkbar.

    OMSI stört sich sehr wohl daran. Du hast nur Glück, dass der Fehler nicht wirklich relevant für OMSI zu sein scheint und du die Fehlermeldungen deaktiviert hast.


    DIe Zugriffsverletzungen ergeben sich erst nach dieser Meldung.

    Warnungen sind nur Hinweise und haben für die Funktion, egal bei welchem Fahrzeug, absolut keine Relevanz.

    dann ist entweder die aktuelle Steamversion fehlerhaft (was ausgeschlossen werden kann), du nutzt nicht die aktuelle Version (oder bist eventuell im OMSI Beta-Branch eingeschrieben?) , eine Mod ist dafür verantwortlich oder du nutzt eine illegale, veraltete, nicht funktionierende Version. Bitte mal die Spieldateien von Steam überprüfen lassen (Rechtsklick auf OMSI -> Einstellungen-> Lokale Dateien-> Auf Fehler überprüfen). Gäbe es seit dem letzten Update generell einen Fehler, wäre das hier schon kommuniziert wurden - das Problem ist dementsprechend ein lokales bei deiner Installation, kein generelles.


    Ja, Dann mach ich kurz eine neue Logfile.


    Am anfang hatte ich kurz den Göppel anghänger ausgewählt habe dann aber auf die standart gewechselnd wie gesagt nur der solo hat keine probleme Gelenk und buszug hat das problem logfile.txt

    Zu wenig freier Speicher. Räum mal deine OMSI Installation auf, vorallem den Font-Ordner. Bitte auch die Standard-Repaints austesten. Sollte ein Communityrepaint beispielsweise ohne komprimierung der Textur gespeichert worden sein, ist diese für OMSI viel zu groß und passt nicht in den Speicher.

    der MAN Stadtbus hat die Funktion, dass dort die Werbeanzeigen im Fahrzeug dynamisch ausgetauscht werden können.
    Sollte ich beispielsweise ein neues DLC veröffentlichen, kann ich dort Werbung für mein Produkt schalten.

    Die Webadresse ist übrigens noch aktiv, es liegen nur zum aktuellen Zeitpunkt keine Texturen zum Download bereit. Das ist aber auch nicht schlimm, denn das Fahrzeug wird per Steam mit einem Satz Werbungen für ausgewählte Produkte ausgeliefert. :-)

    take a look on how the logic part is done in my Urbino II Add-on. Buttonwise its pretty simple.

    for the pneumatic height control, the NL92 bremse.osc basically sets a target height in the ECAS section - if the bus is lower than the target, its getting raised, if its higher it is lowered. you can simply add a logic that takes this target value and increase or decrease it as you wish.

    Ging es nicht um Shadowbanns und dem Umgang mit Usern? Die Ursache ist dafür doch völlig irrelevant und nur weil Du/Ihr der Meinung seid, etwas sei unangebracht müssen das andere nicht so empfinden. War ggf. bisschen undeutlich formuliert, aber meine Aussage bezog sich nicht auf die Ursache, sondern auf die Tatsache.

    Ich würde euch empfehlen, die Angelegenheit die Lukas beschreibt privat über Discord nochmal zu besprechen und zu versuchen es klar zu klären, einfach um hier nicht wieder sich unnötig hochschaukelnde Diskussionen zu provozieren.


    Da ich dich Lukas, doch für ziemlich kompetent halte glaube ich schon, dass wenn ihr euch nochmal zusammenssetzt, ihr die Angelegenheit klären könnt. Zumindestens für dein "Einzelschicksal".:)


    Und Nein, ich will keine Diskussion unter dem Teppich kehren, aber es ist unsinnig, immer dieselbe Diskussion zu führen.

    Ich finde genau sowas muss ausdiskutiert werden. Es ist ja nicht nur die eine Situation, sondern das zieht sich seit Jahren hin und es lassen sich da ja auch Muster erkennen. Wer öffentlich als Person oder als Firma Auftritt, darf und muss auch öffentlich für solche Aktionen kritisiert werden dürfen.

    Mein Account im LOF hatte nicht einen Kommentar und wurde mit einem Shadowbann versehen. rein technisch ohne Grund, nur weil man mich halt kennt. Das gleiche bei rmpll und das gleiche bei Lukas während nachweislich andere Accounts problemlos funktionieren. Es ist eben kein "Einzelschicksal" oder ein Versehen.

    Wenn sie da nicht mitmachen wollen, bitte sollen sie halt einen TramSim programmieren bei dem man erst mal 10.000 Punkte sammeln muss bevor die Möglichkeit zum Weichen stellen freigeschaltet wird.

    Immerhin hat das Spiel eine gewisse Langzeitmotivation. Ich habe in Tramsim mehr Spielzeit als in LOTUS nach 2 Jahren. Gut, die Samplesize ist 1 und man mag mir auch eine gewisse Befangenheit unterstellen können - aber ich bin da nicht der Einzige. In LOTUS habe ich genauso viel "Spiel"spaß wie in Blender, nur der Name ist ein anderer. In Tramsim kannst halt Spielen, hast ein Ziel und viele gamebreaking Bugs wurden bereits behoben. LOTUS ist aktuell unspielbar ohne Workarounds und Kompromisse.



    Im übrigen ist die UE4 - was Modding betrifft - durchaus ganz weit oben mit anderen Spielen. Die Frage ist halt eher, was man unter Modding versteht. Das Verändern von Drittanbieterpaketen wie in OMSI ist schwierig, aber wenn man will kann man aus einem Bussim auch einen Egoshooter bauen, was bei OMSI wiederrum nicht möglich wäre. Die Contenterstellung für BS18 war Beispielsweise lächerlich einfach und wesentlich entspannter als in OMSI - das Paket jetzt aber zu ändern ist allerdings nicht so einfach, vorallem nicht für dritte.
    So eine offene Struktur wie in OMSI werden wir wohl in naher Zukunft nicht wieder sehen und LOTUS ist ja auch nicht so offen wie sie sich selbst gern sehen.