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!

    reich ist immer eine Sache der Interpretation. Wenn die Verkäufe eines Moduls OHNE Zwischenmann (Sie publishen ja selbst) die Verkaufszahlen von OMSI erreichen (würden), ist das selbst nach Abgaben an Steam und eventueller Lizenzen mindestens ein einstelliger Millionenbetrag Umsatz. Selbst wenn wir hier den höchsten Steuersatz annehmen (Verkäufe ziehen sich ja über Jahre, realistisch wären wir da deutlich drunter) bleibt ein Netto"gehalt" in Millionenhöhe übrig. Ziehen wir hier weitere Module und/oder Anteile an DLC mit in die Kalkulation, wird man vielleicht kein Mulitmillionär, aber Reich - nach meiner Definition - aufjedenfall.
    Dass LOTUS - neben dem Aspekt der "Selbstverwirklichung" darauf abzielt, Umsatz zu machen, erkennt man aber auch am Aufbau, dem Copyrightmanagement, Verschlüsselungen, naehzu-always-online, Lizenz- anstatt Kaufvertrag usw. usf. Man kann es sich natürlich mit "ja, aber dann kann jeder nur das kaufen was er will" schönreden, jeder andere Publisher würde mit den gleichen Methoden sofort als billiges Moneygrab-System enttarnt werden. Natürlich weit weg vom microtransaction müll, aber ganz klar drauf ausgelegt, gutes Geld zu verdienen. Das ist auch nicht zu verübeln, aber die Communitynahe Enhusiastensimulation ist schon lange nicht mehr Programm oder zumindest nicht der Hauptantrieb.

    So ist es. All diese Funktionalitäten wären mit einer off-the-shelf-engine bereits implementiert gewesen. Ich frage mich bis heute, was der Grund für diese Vorgehensweise ist. Selbst wenn eine Funktion einer Engine nicht gegeben ist, lassen sich diese meistens mit Plugins oder der Manipulation des Quellcodes implementieren. Ich glaube auch nicht - und nach dem Werdegang des Projektes auch immer weniger - dass der zu erwartende Umsatz aus diesem Projekt ein Maß übersteigt, wo Lizenzierungskosten die Investitionen in eine eigene Engine übersteigen. Man versucht weiterhin - wenn auch jetzt zu zweit - die Eierlegende Wollmilchsau zu programmieren. Das Ging schon beim Originalcode schief, und wird auch jetzt höchstwahrscheinlich so sein. Die Vergangenheit in OMSI und den Lotus-Variationen hat es vorgemacht. Versprechungen, die nicht gehalten werden können treffen auf Streitigkeiten zwischen den Entwicklern bis es zu einem Bruch im Gefüge kommt und man "alleine" und "alles besser" (weiter) macht.
    Ich wünsche allen, die wirklich noch Hoffnung in LOTUS stecken, dass eure Hartnäckigkeit irgendwann Früchte trägt. Objektiv betrachtet ist das Projekt allerdings schon mehrfach gescheitert und wird - vorallem unter der Betrachtung, wie das alles bisher gelaufen ist - auch höchstwahrscheinlich nie fertiggestellt werden. Da bringen auch die unregelmäßigen Updates nichts.

    reduziert man den invertierten Lenkradius, reduziert man aber auch gleichzeitig den "maximalen" Einschlag der Lenkgeometrie, kann dann also keine engen kurven mehr fahren, wenn man es denn möchte. Deswegen ist dieser beim MAN SG auch höher gewählt, weil sonst bei der Fahrzeuggeometrie und dem Radstand der Lenkradius zu klein gewesen wäre.
    Ich würde als allererstes versuchen, die Achseinstellungen des Lenkrades zu prüfen. dort kannst du mit "Charakteristik" und "schmaler" einstellen, wie sich das lenkrad anfühlt.
    Linear heißt, dass der Lenkeinschlag linear zu deinem lenkrad ist - bei 50% lenkrad hast du dann auch 50% lenkung in OMSI.
    ich würde bi-degressiv versuchen. Damit ist der Lenkeinschlag beim "start" der Lenkung stärker als zum Ende hin, was das Fahrzeug dann aber unruhiger macht und schwerer in der Spur zu halten ist.

    ...dass das Schild nur dort aufgestellt wird, wo du in die Situation kommen kannst, Vorfahrt geben zu müssen - wie zum Beispiel an einer T-Kreuzung, wenn du rechts von dir den abgehenden Arm hast. Das Schild zeigt dir dann im Kreuzungsbereich, dass du Vorfahrt hast. Hast du den abgehenden Arm aber Links von dir, hast du ja - außer gegenüber dem entgegenkommenden Verkehr - so oder so Vorfahrt, das Schild ist also nicht nötig und wird in der Regel auch nicht gesetzt.


    Beispiel: T-Kreuzung, Rechte Spur KEIN Vorfahrsschild:

    S1uruPV.jpeg

    Gegenrichtung mit abgehendem Arm MIT Schild:


    bWbyJuk.jpeg



    Die Position vor oder nach der Kreuzung je nach In- oder Außerorts hat damit nichts zu tun. die markierten Schilder würden aber in der Realität an dieser Stelle gar nicht stehen. ;)

    Woher sollen wir das wissen? Nochmals: Das Fahrzeug-DLC funktioniert in einer sauberen Neuinstallation von OMSI nachweislich völlig Problemlos. Das DLC ist dahingehend fehlerfrei, es gibt keine Bugs, die von unserer Seite aus zu beheben sind. Die Fehlerursache können wir also nicht wissen, sondern nur vermuten - und da du in OMSI so gut wie alles machen kannst, ist nicht absehbar, von wo die Fehlerquelle ausgeht. Das kann ein Repaint sein, das kann ein Shader wie SweetFX oder Reshade sein, das kann eine Inkompatilität mit OMSI und deinen Grafikkartentreibern sein, es kann quasi alles mögliche sein.

    Die Fehlersuche können wir also für dich nicht durchführen, das musst du selbst tun.


    Schick mir mal nen Screenshot aus dem Texture-Ordner des Fahrzeuges, auf dem alle vorhandenen Ordner und Texturen ersichtlich sind.

    und hast du es denn mal aktiviert und getestet? die Konfiguration macht immer noch der Entwickler des jeweiligen Fahrzeuges , nur weil das Modell und das Script identisch/ähnlich sind, ist es nicht zwangsläufig die Implementierung. Alle Effkete aktivieren, OMSI neustarten, testen. Ist das Problem immer noch vorhanden, kann man schauen woran es eventuell noch liegen könnte.

    Natürlich hat sich der Entwickler zum Thema schon geäußert.
    Wenn das Add-on als Vanilla-Installation funktioniert, liegt die Ursache an Zusatzinhalten oder falschen Einstellungen.

    Edit: just die Steam-Version heruntergeladen, U18 gesetzt:

    6ndIBub.jpeg


    bnmz35m.jpeg

    Wichtig ist, dass alle Effektkanäle aktiviert sind:


    SO9aTHF.png

    Dannach OMSI NEUSTARTEN.

    Schafft das keine Abhilfe, den Fahrzeugordner VOR DER NEUINSTALLATION löschen und dannach KEINE REPAINTS ODER MODS einfügen und erneut probieren. OMSI grundsätzich neustarten und keine Situation nach der Neuinstallation laden.
    OMSI ist eine sehr offene Plattform und entsprechend fehlerbehaftet - wie soll ich bitte weiterhelfen, wenn es nachweislich in einer sauberen Installation funktioniert? Selbst ein SweetFX Shader kann die Transparenzen entsprechend so manipulieren, dass es entsprechende Negativeffekte geben kann. Ein Support solcher fehler ist ausschließlich mit Vanilla-Instalationen möglich, weil andere Fehlerquellen nur so auszuschließen sind.

    Schuld sind wir als Entwickler hier auf keinen Fall, ganz unabhängig vom alter des Add-ons. Schuld ist, welche mod /welches Programm diesen Fehler verursacht.

    Es sind trotzdem aber Fehler, und daran ändert auch nichts dass 99% der Busse, ob Free- oder Payware, solche Fehler haben. Und in der Summe trägt dass eben auch zu unsauberen Frametimes bei.

    Das ist so nicht korrekt. Die einzigen Frametime-Einbußen durch Texture-Warnings entstehen durch die Warnung und das schreiben ins Logfile (beim Spawn) selbst, was allerdings über den Startparameter "-nolog" umgehbar ist, sollte das Schreiben ins Logfile überhaupt messbare Einbußen verursachen.
    Bei "Error", Fehler bei Bereichsprüfung und co. bin ich ganz bei dir - die Texturwarnungen sind allerdings technischer Natur und nicht immer vermeidbar.- im übrigen auch nicht exclusiv bei Pay- oder Freewareprojekten, sondern auch im Standardcontent selbst.

    Ich hab dafür leider auch keine Zeit. Meine angefangenen Projekte hab ich hier in der Filebase zur Verfügung gestellt, wenn Lurchi da nicht noch weitere Pläne mit hat, wäre das eventuell auch ne Option. :-)

    Allerdings stimmt die Farbgestaltung wenn man es mit der Realität vergleicht hinten und vorne nicht. Der Himmel ist definitiv viel zu farbintensiv beim Sonnenuntergang, die Umgebung zu entsättigt. Dadurch entsteht meiner Meinung nach, ein ziemlich unausgeglichenes gesamt Bild. Omsi, das offensichtlikche Vorbild dafür, ist m.M.n. nicht unbedingt das parade Beispiel für eine realitätsgetreue Darstellung.

    Das gute bei der UE ist ja grundsätzlich, dass du Kartenabhängig über die Post Process Volumes Kontrolle über fast alles hast. auch LUT's fürs Color Grading.
    In der gesamten Betrachtung gibts allerdings eine relevante "Hürde" - Modding. In einer PBR-Engine kannst du solche Ergebnisse wie bei Assetto Corsa nur erreichen, wenn man nicht nur mit Diffuse-Texturen arbeitet, sondern für nahezu jede! Textur die entsprechenden Effekttexturen (Displacement, AO, Specular, Roughness, Normal und co. definierst, um eben die physikalischen Eigenschaften der Oberfläche zu simulieren. Das kann man als Entwicklerstudio mit (hundert) tausenden von Euros an Budget und mehreren Grafikern umsetzen, klar, aber dafür ist meinerseits weder das Budget, noch die Zeit vorhanden. Im Bereich der Stadtsimulation hast du da auch ganz andere Voraussetzungen, da reichen nicht 3 Asphaltmaterialien, 5 Zäune, 2 Curbtexturen, 5 Leitplanken und paar generische Elemente, um ne Rennstrecke dar zu stellen. Da ist optimalerweise jede Textur individuell.
    Dementsprechend habe ich die Shader auf die klassische Diffuse-OMSI optik ausgerichtet, um ähnliche "einfache" Moddingmöglichkeiten anzubieten. Keines meiner Materialen hat bisher spezielle Effekttexturen - das heißt aber nicht, dass sowas nicht auch möglich wäre!
    Um also die Contententwicklung so einfach wie möglich zu gestalten, kann ich nicht Voraussetzen, dass ein "OMSI-Haus" auf einmal 5 Effekttexturen, 3 Masken, Night/Lightmap usw. zwingend notwendig macht, denn das verkompliziert die Contententwicklung immens. Bei Repaints in der OMSI Szene scheitert es ja zum teil schon an der korrekten Einstellung der Transparenzen, wie soll das werden, wenn man o.g. Effekttexturen erstellen soll?
    Du hast natürlich grundsätzlich recht, die Optik entspricht keinesfalls dem Optimum. Unter der Prämisse, dass das Spiel vernünftig und vor allem einfach modbar sein soll, muss man halt anderswo abstriche machen.

    Aber das ganze geht auch zuweit ins off-topic. ich wollte damit eigentlich nur darstellen, dass es auch eine "gezämte" Optik in moderneren Engines möglich ist und nicht jeder Effekt aktiviert sein muss, nur weil es ihn gibt - gleichzeitig starke Reflexionen oder Glanz nicht zwangsläufig unrealistisch sein müssen. Der gesunde Mittelweg sollte angestrebt werden.
    In Film und Fernsehen und bei Robotern gibts das sogenannte "uncanny valley" - der Punkt, an dem die Optik eines Roboters oder gerenderten Menschens nicht wirklich realistisch wirkt, aber auch nicht wirklich unecht - also sich genau an der Schwelle zum Fotorealismus bewegen. Das wirkt dann "creepy", komisch, nicht wirklich einzuordnen. Eine ähnliche Problematik gibt es mMn auch in der Spiele-/Simulationsentwicklung. will man "zu viel" wirkt es wieder irgendwie falsch. da bewege ich mich lieber auf OMSI niveau, als es komplett zu versauen. :D

    38.000 Wolkeneffekte und zig Glanzeffekte sind nix für mich. Also wenn ich bei uns in der Stadt im Sommer herumlaufe, werde ich jedenfalls nicht vom Sonneneffekt auf der Gleisoberkante der Tram geblendet, bis mir die Netzhaut wegbrutzelt. Das ist Quatsch, wie mir das einige Simulationen erklären wollen. Und das ist halt, wie sich 3D-Artists teilweise die Realität vorstellen. ^^ Da sage ich nur, die sollen vor‘m WoW aufstehen und nach draußen gehen und sich die Realität angucken. ;)

    naja, das ist auch schon bisschen stark verallgemeinert. Ja, TML und co. übertreiben hier und da mit Grafik, aber wenn man sich mal Asphalt oder Gleisoberkante in tiefstehender Abendsonne betrachtet, bruzelt es mir aus dem Auto schon die Retina's weg.
    Ich nutze in meiner eigenen, hingepfuschten Simulation ebenfalls die Unreal Engine und bin mit Beleuchtung, Kontrast und Effektstärke durchaus zufrieden.


    schaut man sich mal einige Berliner Gebäude an einem sonnigen Sommertag an, stellt man ebenfalls fest, dass "verspiegelt" oder "glänzend" eigentlich ganz passend ist:

    ...und das sind nur Bilder, wo sich die Sonne nicht direkt in den Fenstern und Glasflächen spiegelt.


    Manchmal ist weniger mehr und nur weil eine Engine etwas kann, muss man es nicht zwangsläufig nutzen. Viele Effekte machen auch gar keinen Sinn, so wie chromatische Aberration oder Lens-flares in einem "Spotting-mode" mit virtueller Kamera Sinn machen, aber in der Spielerkamera nichts zu suchen haben. Nach meinem letzten Wissensstand ist beides bei The Bus dennoch standardmäßig aktiviert, obwohl es - sowohl aus einer realistischen als auch aus einer persönlichen Sichtweise - dort absolut keinen Sinn macht. Ich glaube sogar, dass man mit einer "entschärften" Grafik bessere Ergebnisse erzielt, was nicht nur dem Enthusiasten, sondern auch dem Casual-Gamer zugute kommen würde.

    Entspannt euch doch mal!

    Ich weiß selbst als Dev wie viel Zeit so etwas benötigt. Kann gut verstehen dass sie sich voll auf den Engine Wechsel fokussieren anstatt alle 2 Stunden status Updates zu geben… gebt ihnen doch mal Zeit dafür ;)

    nah. nicht, wenn man ein Produkt schon auf dem Markt hat, nicht, wenn es Käufer gibt, die warten, die Erwartungen haben.
    Das Argument des Early Access zieht da auch nicht. Ein täglicher Beitrag kostet 5 Minuten zeit, wenn man diesen nicht für die Community übrig hat, lässt das tief blicken.