Beiträge von Chrizzly92

ganz ausschließen würde ich nicht, dass ich für TheBus etwas mache. Das Problem ist hier eher wieder, dass die - zum aktuellen Zeitpunkt existierenden - Möglichkeiten des Moddings nicht an die von OMSI heran reichen, und durch "hausgemachte" Einschränkungen Projekte, die die Funktionen der Engine super nutzen könnten, technisch nicht in einem vernünftigen und qualitativen Rahmen umsetzbar sind. Das mag gehen, wenn man wie für Fernbus generische Splines und 0815 Kreuzungen verwendet. Gehts aber beispielsweise um Überhöhungen, Graderprofile oder komplexe Topographie im Kartenbau und damit um eine realistsche Abbildung der Fahrphysik (z.bsp. das durch die Straßengeometrie verursachte Wippen des Gelenkbusses beim Überfahren einer Kreuzung, aktive Force-Feedback-Eingriffe durch Straßenquerneigung etc.), kann man TheBus vergessen.
Die Engine selbst ist potent genug, viele Einschränkungen werden quasi erst hereinprogrammiert, um das Modding auf der einen Seite zu vereinfachen, was aber unweigerlich die "Experten" einschränkt.
OMSI 3. mehr braucht es eigentlich nicht. Gleiche Gedanken, gleiche Simulationstiefe, gleiche Schwerpunkte, mit einer effektiven Engine. Alles andere kann und wird an den Erfolg von OMSI nicht anknüpfen können.

ohne die entsprechenden Hofdateien kann man dir nicht helfen. dass das Fahrzeug während der Fahrt auf München das Ziel wechselt, ist so gewollt, da die Fahrgäste, die schon an der Haltestelle stehen, sonst an der ersten Tür "hängen bleiben", und vorallem im Buszug nie die hinteren einstiege benutzen würden.

Zitat von Lazarus

Ich glaube stark, dass er mit der Situation nicht zufrieden ist. Ich finde es total positiv, dass Qualität einen großen Faktor spielt.

In diese Position haben sie sich aber aufgrund der Ignoranz, Überheblichkeit und Besserwisserei selbst manövriert. "Wir wissen, was wir tun." Qualität ist nicht nur die Umsetzung einer speziellen Sache innerhalb des Simulators, das Gesamtkonzept muss funktionieren.

Zitat von gt670dn

Zitat von Chrizzly92

Maximalprofit

Inwiefern wird denn mehr durch das geschlossene Content-System mehr verdient?

Ansonsten stehe ich an dem Punkt tatsächlich auf Deiner Seite, hatte mir auch immer einen Tramsimulator erträumt bei dem man sich dann allerlei Fantasie selbst zusammen modden kann mit der Freiheit von Omsi. Aber ist jetzt halt nich so geworden...

Manche haben aber auch schon gesagt, dass sie mit einem offeneren System gar nichts für Lotus machen würden, weil sie auf die Zustände wie bei Omsi keine Lust hätten. Das finde ich persönlich zwar sehr schade, aber eben eine Abwägungsfrage der Reichweite die man als Entwickler treffen muss wenn derartige Ansichten existieren.

Eigentlich bräuchte es in der Nahverkehrs-Sim-Community mal eine spielunabhängige Platform auf der quelloffene "Rohfahrzeuge" frei getauscht und inkrementell verbessert werden können und aus diesen Grundmodellen immer wieder für konkrete Spiele abgeleitet werden.

Alles anzeigen

Die Frage kann man sich beantworten, in dem man darüber nachdenkt, warum solche Maßnahmen ergriffen wurden. Onlinezwang, verschlüsselte Container, verschlüsselte Meshes, compilierte Scripts. Dies dient - natürlich - zum einen der Wahrung des Copyrights, zum anderen ist das aber eine Maßnahme, um Leute zum Kauf zu "zwingen", weil man es eben nicht auf LOTUS-Mods.ru runterladen und spielen kann.
Das ist aus betriebswirtschaftlicher Sicht sicher sinnvoll, keine Frage, aber wenn man schaut, warum OMSI so eine stabile Performance ablegt, ist doch eigentlich klar, warum. Das Lego der Bussimulation quasi. Ist zwar schön, wenn man ein fertiges Modell erwirbt, damit spielt man auch mal 1-2 Stunden, aber ohne die Möglichkeit, mit den Steinen rumzuspielen, macht es halt deutlich weniger Spaß.
Interessierte, die ein Projekt kaufen wollen (Qualität, Umfang, Support, welcher Grund auch immer) tun dies. Eventuell erst in einem Sale, aber im großen und ganzen holt man mit einer fairen Preis-(Leistungs)politik die meisten potentiellen Käufer auch ab.
Die Leute, die Spiele "Cracken", tun dies doch entweder aus Überzeugung, oder weil sie keine andere Möglichkeit haben. In jedem Falle fallen die doch aus der Kalkulation sowieso raus, da sie so oder so kein Geld dafür ausgeben wollen(oder können). Was verliert man also? Zumindest bei meinen OMSI DLC's kann ich jetzt keine relevanten Unterschiede zwischen Kopierschutz und "offen" in der Verkaufsperformance erkennen. Es mag den ein oder anderen egozentrischen Menschen geben, der keinem anderen etwas gönnt und lieber crackt als kauft, sofern es einen gibt - aber das ist keinesfalls die Masse und in der Kalkulation vernachlässigbar. Solche harten Einschränkungen sind also meiner Meinung nach absolut kontraproduktiv und verursachen mehr Einschränkungen und "Schaden", als dass sie Vorteile mit sich bringen.

Das ist im übrigen nicht nur ein LOTUS Problem, auch TheBus geht ähnliche Wege. Ein Beispiel:

Die TheBus Moddingtools sind eigentlich ganz nett - wenn man im flachen Brandenburg wohnt. Man legt sich quasi die Gehwegsplines, markiert die edges und erstellt dazwischen Flächen, welche dann die Fahrbahn darstellen. Soweit, sogut.
Was machst du aber, wenn du Überhöhungen oder Querneigung umsetzen willst? dann ist das Splinesystem nicht benutzbar. Zum Glück kann man sich ja, wie in OMSI oder LOTUS, welche schreiben, die die komplette Straße abbilden.
Was machst du jetzt aber, wenn du mit einer überhöhten oder quergeneigten Fahrbahn aus 4 richtungen an eine Kreuzung anschließen willst? am besten noch in Hanglage? das geht nur mittels Objektbau.
OMSI hat dafür die optimale Lösung: Splineexport. damit holt man sich die Anschlusssplines aus dem Editor in Blender, baut die Kreuzung als Modell, lädt sie in OMSI und setzt sie in das Konstrukt einfach ein. fertig.
NICHT aber in TheBus. denn dort ist aus Gründen des Copyrights und intellektuellen Eigentums der Export aus der Engine grundsätzlich deaktiviert. Es gibt also nur rein in die Engine, nicht aber raus. Damit ist der Editor für komplexe Überlandkarten, für welche sich die Unreal Engine durch die guten Möglichkeiten im Hinblick auf Weitsicht und Flora top eignen würde, unbrauchbar. Flache Karten, ohne topografische Tiefe, ohne interessante Straßenführungen, sind mit den tools natürlich zügig umsetzbar. Aber alles, was aus der Ebene rausfällt, ist nichtmehr korrekt Umsetzbar. die einzige Lösung wäre, das komplette Straßennetz als Modell zu bauen, aber dann stellt sich mir die Frage: wofür brauche ich dann einen Editor? Selbst der BusSimulator21 bietet hier unterm strich bessere Moddingmöglichkeiten.

Das gleiche Schicksal wird auch LOTUS erfahren, da bin ich mir sicher, wenn an der Container-Politik festgehalten wird. so viele Kartenerweiterungen, so viele Mods (selbst wenns nur andere Haltewunschtaster oder scriptkleinigkeiten sind) aus nem 2-Türer nen 3-Türer modden, haltestellenhäuschen tauschen - all das wird nur noch auf Absprache möglich sein. Und wenn man Inhalte aus dem Workshop nutzt und diese dann mal entfernt werden (warum auch immer) ist es mir nichtmal möglich, die Probleme im Editor selbst zu fixen.
Und all diese Einschränkungen, damit ein Modell nicht nach Proton oder so konvertiert wird? Auch da Frage ich mich, was für ein Schaden entstehen soll. Es ist unmoralisch, ja, aber solange damit kein Geld verdient wird, who cares? Bei rechtlichen Problemen kann man entsprechend dagegen Vorgehen, Wenns einer aus Hobby oder privat macht, ist das mMn. irrelevant. Sollen die 50 Spieler doch ihren Spaß haben, währenddessen man dafür tausende im eigenen Franchise begeistern kann.

LOTUS scheitert schon an den eigenschränkten Moddingmöglichkeiten im Vergleich zu OMSI. Wenn man Glück hat, definieren die Entwickler entsprechende Modulslots, wenn man Pech hat, kann man gar nichts ändern. Ein perfektes Beispiel, wie die Sucht nach Maximalprofit und ein übertriebenes Copyright die Kernkomponente des Erfolges kaputt machen.

Darius gehört doch, genauso wie Rolf, zum Kuhnt-Dunstkreis. Es war abzusehen, dass es aus dem Hause Darius irgendwann Inhalte für LOTUS gibt. Wird unspielbar sein, aber die 5 Hardcore Fans werden es lieben.

Hallo liebe Community!
Nach fast 4 Jahren Arbeit ist heute der Tag gekommen, an dem ich euch mein neues Add-on "MAN Standardbus II" präsentieren möchte.

Einen besonderen Dank möchte ich an dieser Stelle an die Firma Heinrich Reisen sowie den Verein "Nahverkehrsfreunde Dessau e.V." richten, ohne deren Mitarbeit dieses Produkt nie in dieser Form möglich gewesen wäre. Weiterhin möchte ich hier ebenfalls Perotinus für seine sehr gute Arbeit beim Sounddesign danken und natürlich allen Betatestern, die stets mit Verbesserungshinweisen genervt haben.

Das Add-on wird am 11.01.2024 über den Publisher [group]AEROSOFT®[/group] erscheinen.

Kaufen auf STEAM: Hier Klicken

Vielen Dank und viel Spaß mit dem "MAN Standardbus II"!

Zitat von BusfahrerP

tolle Idee, nur dass es dann noch länger dauert, weil nicht nur geänderte, sondern alle Dateien neu runtergeladen werden, die zum Basisspiel oder den DLC's gehören. Dann doch lieber das geänderte aussitzen und wieder von der externen drüberbügeln.

ja, einmalig. auf dieser installation kannst du dann auch updates empfangen und händisch wieder in deinem "Projekt"-OMSI einfügen. da kann also geupdated werden wie steam will, zerschießt dir dafür aber nicht deine eigenen Änderungen jedesmal.
So mache ich das zum beispiel Immer. wöllte ich jetzt ein neues DLC Modden, würde ich mir Fahrzeug- oder Kartenordner duplizieren und umbenennen. verbraucht dann zwar bisschen mehr Speicher, aber der ist heutzutage so günstig, dass das eigentlich kein Argument mehr ist.

Ich hab mal in Steamworks für mein eigenes Projekt geschaut und sehe dort keine Einstellung, dass ich als Entwickler die Überprüfung der Dateien in irgendeiner Form beeinflussen könnte.
Eine ganz einfache Lösung scheinen die Betroffenen Personen aber immer zu vergessen: Nutz OMSI doch einfach aus einem anderen Ordner heraus! dann kann Steam doch synchronisieren wie es will, ohne dass die eigenen Dateien überschrieben werden.

Zitat von Lµkas

Zitat von Chrizzly92

Assets in Unity zu importieren und ähnliche Screenshots zu erstellen kann fast jeder in ein paar Stunden und einem Youtube-Tutorial als Hilfestellung.

Das kann auch ein Vorteil sein. Gerade wenn es um die Content Entwicklung geht, ist die LOTUS-Engine mMn nicht gut aufgestellt. Gibt man das an Unity ab, hat das auch für die Community Vorteile (unter der Prämisse, dass Content auch unter Unity entwickelt wird):

• Es gibt eine Fülle an fertigen, kostenlosen Modellen (oder für wenig Geld), die sich sehr einfach in Unity-Spiele bringen lassen.
• Die Sammlung an Tutorials, Anleitungen, Hilfestellungen, ... im Internet ist riesig.
• Der Editor hat sich jahrelang bewährt. Das System funktioniert einfach. Die Qualität der Tools ist eine ganz andere.

Was noch dazukommt: Nicht nur zu Unity, auch die Ressourcen zu C# sind im Internet quasi unendlich vorhanden. Ich persönlich halte C# schon seit vielen Jahren als die beste Sprache für Spiele. Man merkt bei der Arbeit, wie ausgereift das System ist.

Die Vorteile für die Community sind klar, aber das war gar nicht der Punkt, auf den ich mit dieser Aussage hinaus wollte. Ich wollte eher darauf hinweisen, dass die Screenshots gegebenenfalls einen Entwicklungsfortschritt suggerieren, der so noch gar nicht existiert, eben weil es leicht ist, mit wenig aufwand recht gute Ergebnisse zu erzielen. nen Prefab in Unity zu importieren und zu texturieren ist halt noch lange kein Fortschritt vom Spiel selbst.

Zitat von Thomas U.

Die Bussim-Reihe basiert ja auch auf dieser Engine und ist eher ein Beispiel zum Abgewöhnen. Sicherlich eine Frage der Arbeit, die man reinstecken möchte. Zumindest werden wir in LOTUS keinen Drehzahlmesser bekommen, der im Stand auf Null sinkt, während der Motor weiterläuft.

Bussim ist Unreal Engine und in beiden Engines sind natürlich auch identische, wenn nicht sogar bessere physikalische Umsetzungen möglich. nimmt man natürlich eine arcade-vorlage, kann da kein gut simuliertes fahrzeug draus werden. Das OMSI Motor/Getriebekonzept ist in der Unreal Engine beispielsweise 1:1 umsetzbar.

Im Grunde haben die beiden 5 Jahre gebraucht um festzustellen, dass die Entwicklung einer eigenen Engine nicht zu stemmen ist, zumindest nicht bei den Zielen, die sie sich selbst gesetzt haben.
Also das, was große Teile der Community schon vor 5 Jahren gesagt haben.

Ändert leider nichts am Spiel, den Fortschritten, dem Kommunikationsverhalten und den ganzen anderen Problemen, die es um dieses Franchise und die Entwickler gibt.
Ich bewerte das als Scheitern nach Jahren der Entwicklung.
Screenshots wie im Bild sagen übrigens nichts über den aktuellen Stand aus. Assets in Unity zu importieren und ähnliche Screenshots zu erstellen kann fast jeder in ein paar Stunden und einem Youtube-Tutorial als Hilfestellung.

im Fahrzeugscript ist aber nur die Amplitude und die Stärke des "Vibrierens" definierbar. ich kann per Script also bei niedriger Motordrehzahl oder beim Scheppern das Lenkrad vibrieren lassen, das war es aber auch schon - ich kann via Script das Lenkrad nicht aktiv nach links oder rechts drehen. Das verziehen der Lenkung, zum Beispiel am Bordstein, wird OMSI-Intern festgelegt und ist dementsprechend nicht mit dem Script eines Fahrzeuges zu beeinflussen.

Es geht nicht drum, wo der Antrieb ist oder welche Achse angetrieben wird. Die Nachläufer haben einen vom Gelenkwinkel abhängige Lenkung - der zu beschreibende Kreisbogen verändert sich also dynamisch, je nachdem, wie geknickt das Gelenk ist. OMSI unterstützt allerdings keine aktiv gelenkten, weiteren Fahrzeugteile. Man kann das ganze "faken", in dem man den rotationspunkt des Anhängers künstlich verschiebt oder den Lenkwinkel der Räder via Script optisch beeinflusst.
Solche Umsetzungen sind also - wie zum beispiel der Buszug aus München - nur bedingt realistisch umsetzbar. Den einem reichts, dem anderen stößt das Fahrverhalten auf, manch einer erkennt vielleicht nichtmal den Unterschied zwischen SG242 und SG242H. Für mich ist das allerdings einer von vielen Gründen, mich nicht um einen 242H zu kümmern. Eher werfe ich noch nen SM hinterher oder auch ein OBus, wenn die Logik von unserem Trigonometriefreund irgendwann fertig ist.

halt mal etwas länger gedrückt. hört sich an wie ein implementierter Komfortblinker.

ich vermute eher einen Fehler bei den Fonts, nicht bei den Repaints. das war nur ein Beispiel, wie Drittanbieterinhalte dafür sorgen können, dass DLC's nichtmehr funktionieren. Du kannst ja auch mal testweise deinen OMSI Ordner zu "OMSI 3" umbenennen und dann OMSI ohne DLC's frisch über Steam installieren (auch ohne BBS, AUXI, OMSI Navigation und co!). dann mal Ruhrgebiet runterladen und schauen, ob es auch absolut vanilla nicht funktioniert. wenn das Problem immernoch bestehen sollte, liegts nicht am Inhalt selbst, wenn das Problem weg ist, würde ich als allererstes den gesicherten Font-Ordner in das OMSI Archiv kopieren und schauen, ob das problem wieder besteht.

Wichtig ist immer, dass man OMSI nicht einfach nur neu installiert, sondern auch den Ordner selbst entfernt/umbenennt, sonst verbleiben die ganzen Sceneryobjects, Splines, Texturen und co. im Ordner.

Zitat von Thomas U.

[...]aber dieser Kurznachläufer ist optisch ebenfalls gruselig.

Vielen Dank für den Support. Das sieht irgendwie falsch aus und ist auch mein Hauptargument wenn es um die Frage geht, warum kein 242H. Wer sich berufen fühlt, kann die Kisten dann ja aus dem SG242 ableiten, aber mir ist die Kiste deutlich zu hässlich, zudem das in OMSI durch die gelenkte Hinterachse auch nur bedingt realistisch umsetzbar wäre.

Zitat von derTobi

Das komplette Kacheln nicht geladen werden können ist ebenfalls absoluter Schwachsinn. Beim starten des Editors erhält der User die Möglichkeit, den fehlenden Content entweder zu tauschen oder zu löschen. Beim erneuten starten kann er diese alternative Liste erneut laden, oder sie durch eine andere austauschen. Dadurch können zwischenzeitlich fehlende Objekte wieder richtig ersetzt werden.

Das mag ja für Inhalte gelten, die geändert werden können. Wie siehts aber bei Containern aus, wo du als Spieler keinen Zugriff drauf hast?
Falls Karten grundsätzlich editierbar sind vom Spieler (da bin ich mir nicht sicher), kann man hier dennoch nicht verlangen, dass dieser die Karte entsprechend editieren muss. Zudem gäbe es auch Methoden, zumindest unkritische Inhalte gegen Generic-Würfel oder so auszutauschen.

nope. ich kann nur sagen, dass bei meiner OMSI Installation (aus kompatibilitätsgründen fast ausschließlich Standardcontent installiert) das ganze kein Problem ist. Die Ursache kann also überall liegen, gegebenenfalls nichtmal am Add-on.
Ich kann mich beispielsweise an eine ähnliche Situation entsinnen, wo der MAN Stadtbus durch fehlerhafte Repaints von der Karte "Liestal" unspielbar gemacht wurde.

Repaints, Mods, Fonts - Durch die komplexität von OMSI ist es MIR nicht möglich, die Ursache zu finden. Da müsste man sich mal die gesamte Omsi-Installation der betroffenen Systeme anschauen.

Zitat von SGDLoewe

In Pirna fuhr damals ein Gelenkbus davon

Zitat von OMSIflo

---

Ihr habt ja recht.

Find den MAN SG 242 übrigens auch total hässlich, was Chrizzly92 und vielleicht auch andere wohl anders sehen...

Wollt ihr denn auch lieber den SG 242 oder eher den SG 240H??

Komm da nicht drauf klar, das es den in über 10 Jahren OMSI noch immer nicht gibt...

Wenn ich doch nur die Fähigkeiten hätte so einen zu bauen...

Dabei geht es nicht primär ums "wollen" - so ein Projekt steht und fällt mit der Verfügbarkeit von Vorbildfahrzeugen. Zudem komme ich als Entwickler aus dem Osten der Republik, die SG240 Zeit gab es hier in der Form so gut wie nicht. Mir ist auch kein Unternehmen bekannt, welches in der "näheren" Umgebung entsprechende Vorbildfahrzeuge hatte und vorallem auch noch hat, um entsprechende Referenzen zu erstellen.
Klar könnte man hier aus Rolfs O305G irgendwas pfuschen, aber um ne gute Qualität abzuliefern, ist das Vorhandensein eines Vorbilds in der Regel nicht zu ersetzen. Soundaufnahmen, Details, Maße, Technik - und daran scheitert es halt beim SG240.
Wenn du all das besorgen kannst, dann ist der erste Schritt in Richtung Umsetzung bereits gegangen. Wenn nicht, wirst du wohl für immer darauf warten müssen oder dich mit irgendeinem "Pfusch" zufrieden geben.