Beiträge von Chrizzly92

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.

versuchst du eventuell, Pixel an einen Ort außerhalb des Texturespaces zu schreiben?

Soviel zum Thema "OMSI stirbt" - freut mich, dass immer noch fähige Leute mit guten Ideen hier rumrennen!

Zitat von DerGrafikfehler

Das gesamte Display mit ein- und ausgeschalteten Pixeln auf die Scripttextur zu holen habe ich tatsächlich noch nicht probiert, das schaue ich mir mal an.

Mir erschließt sich trotzdem nicht ganz, wieso die Scripttextur selber als Textur verwenden ein anderes Ergebnis liefert als selbige Scripttextur für eine gleichfarbige "normale" Textur zu verwenden. Gefiltert ist alles.

Zitat von Chrizzly92

dann zuallererst deine hintergrund-bitmap in die scripttextur laden, dann deinen text drauf addieren

Funktioniert das überhaupt? Das habe ich vor einigen Jahren schon mal probiert, aber mit keinen sinnvollen Ergebnissen.

mach mal STNewTex, STLock, STLoadTex und dann STUnlock. dann kurz fahren oder nen speichern erzwingen und die entsprechende scripttextur im mapordner prüfen. wenn sie dort korrekt dargestellt wird, sollte es rein technisch funktionieren. probiert habe ich das selbst allerdings in der form noch nicht. die einzelnen RGB Kanäle kann man aber per script aufjedenfall beschreiben, wüsste also nicht warum man keine textur laden können sollte.
Eventuell ist auch wichtig, dass die Textur im Bitmap oder DDS format vorliegt.

Das Problem beim Mipmapping ist, Dass zwei nebeneinander liegende Pixel für die nächst kleinere Texturstufe zusammengerechnet werden.
Stell dir vor, Weiß ist deine Schrift, Schwarz ist der Alphakanal. halbierst du die Texturmaße, werden 2 nebeneinanderliegende Pixel zusammengerechnet. Aus Weiß (255) und Schwarz (0) ergibt sich 127 (grau). Die entstande Mipmap hat nun also eine "weichgezeichnete" kante mit einer halbtransparenz.
in der nächsten stufe wird nun diese graue pixelkante wieder mit dem schwarzen pixel daneben multipliziert. Dies ergibt also eine Transparenz von 64. nächste stufe 32.
umso weiter du also weggehst, desto mehr "blutet" der Alpha-kanal in die Pixel der sichtbaren Buchstaben.

Zitat von Entdecker666

Also bei mir funktioniert es nur zur Hälfte. Ich habe es mit einer .tga ausprobiert, dort wird alles genauso übernommen, auch die Transparenzen. Was jedoch Probleme macht, ist das Schreiben mit Text darauf. Dort wird einfach der neue Alpha-Wert auf die Skripttextur geschrieben, ohne dass der darunterliegende Pixel beachtet wird. Gibt es dafür auch eine Lösung? Falls das nicht zu verstehen war, hier mal ein Ausschnitt:

das ist tatsächlich eine Einschränkung, die sich so einfach nicht beheben lässt - zumindest ist mir da kein Weg bekannt, der sich performancetechnisch relativieren lässt. schreibst du mit einer alpha auf die vorhandene textur, wird diese ja auch entsprechend übernommen. im script könntest du aber beispielsweise einen großen Rahmen in Weiß auf den Alphakanal der Scripttextur zeichnen, um die transparenzen zu entfernen - dann hast du allerdings einen Rahmen um die einzelnen Buchstaben. Hier hilft nur, den Background des Fonts an den Hintergrund des Displays anzupassen und gegebenenfalls durch verschiedene Fonts durchzuschalten, je nach Hintergrundfarbe.

Rein technisch gäbe es auch dafür eine Lösung: Zwei Scripttexturen. Dazu erstellt man zwei Scripttexturen gleicher Größe und nutzt wie bei den VMatrizen einen "Pixelcursor", um Pixel für Pixel von der einen Textur in die andere zu übertragen.
Ist die Ausgabe von STReadPixel an Position X/Y in den RGB Werten kleiner als 50, wird der Pixel ignoriert, ist er größer als 50 (oder ein beliebiger selbst definierter Schwellenwert) wird der Pixel von der einen auf die andere Scripttextur übertragen.
Bei einem Display von 1920x1080 pixeln würde das aber bedeuten, dass man 2,1 millionen Frames benötigt, um das Display zu übertragen, wenn man pro Frame einen Pixel überträgt.
hat man eine überschaubare Anzahl an Textfeldern, kann man das natürlich optimieren, braucht aber bisschen mehr Script, um die Positionen von Start und Zieltextur zu bestimmen.
Hat der Font 16px höhe und du hast 8 textfelder mit jeweils 256px länge, wären nur 32000 pixel zu übertragen. aber selbst dann braucht man ein riesen Konglomerat an Scriptschnipseln und Macros, um das in einer Sinnvollen Zeit abzuarbeiten.
Sinnvoll Einsetzbar ist die Nutzung von Fonts als direkte Scripttextur also nur, wenn man den Background der Fonts dem Background des Displays anpasst.

Die Tatsache, dass man bei Scripttexturen alle 4 Kanäle beschreiben (R,G,B,A) und bitmaps laden kann, zeigt doch im Umkehrschluss schon, dass man diese Funktion nicht nur für den Alphakanal einer Matrix nutzen kann. ist zumindest mir schon seit Jahren bekannt, wenngleich das - zumindest bisher - kaum verwendung gefunden hat.
Die Probleme der schlechten Sichtbarkeit kommen vom Mipmapping der Texturen. Wenn du näher ranzoomst, sollte die Sichtbarkeit besser werden.
Damit das ordentlich funktioniert, musst du die scripttextur locken, dann zuallererst deine hintergrund-bitmap in die scripttextur laden, dann deinen text drauf addieren und dann locken, um sie zum rendern freizugeben. Je nach Verwendungsfall gegebenenfalls mit M.V.STFilter arbeiten.
Also nicht mit Halbtransparenzen die Texte auf den Background bringen, sondern den Background selbst ebenfalls als Scripttextur umsetzen.

Zitat von tramkatze

Beide Beispiele klingen halt arg nach Copy-Paste mit Abänderung von ein paar Buchstaben oder Zahlen.

Anders hatte ich auch nicht angefangen. Wie gesagt, ich will hier das Verhalten von TigerChris nicht "schönreden", da auch ich ein wenig Eigeninitiative erwarte. Aber man muss da halt auch die Fähigkeiten der einzelnen Person anschauen und daran die Antworten fest machen. Was für den einen halt selbstverständlich ist, ist für einen anderen halt absolut unverständlich, da man halt nicht das gleiche Basiswissen besitzt.