Beiträge von Chrizzly92

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.

Zitat von Kevantasy

Ich wage stark zu bezweifeln, dass wenn du hier nach Hilfe fragen würdest, dir jeder 24/7 zur Seite steht, irgendwann geht es nämlich tatsächlich auf die Nerven wenn du nicht in der Lage bist dinge umzusetzen.

Nun, auch wenn ich dir grundsätzlich recht gebe, muss man das in eurem Falle differenzierter sehen.
Es handelt sich ja - wie auch immer kommuniziert wurde - um einen Early Access für die LOTUS-TOOLS und eine Möglichkeit, Entwickler frühzeitig einzubinden, damit zum Release des Spieles genug Inhalte verfügbar sind. Das ganze ist aber keinesfalls eine Einbahnstraße. Wenn ich dafür bezahlen soll, ein Spiel durch Feedback und eigene Leistung voran zu bringen, dann kann ich meiner Meinung nach auch verlangen, ordentlichen Support zu erhalten - speziell von den Entwicklern selbst, die nur in den seltensten Fällen helfen.

In OMSI hatte man den Vorteil, dass man jegliche Scripts, sei es Free- oder Payware, sei es offizieller Inhalt oder Communityinhalt, einsehen und modifizieren konnte. Ich glaube keiner in der OMSI Szene hat den Code nach einmaligem durchlesen des Wikis fehlerfrei rausgeschissen. Oft beginnt man mit kleinen Änderungen, fügt mal hier nen Haltesummer hinzu, dort einen Türtaster für ne Automatiktür, wo anders eine automatische Haltestellenbremse - und so hangelt man sich Zug um Zug von Problem zu Problem und lernt dabei die Handhabung der Scriptsprache, Hat eine funktionierende Scriptbasis, kann sich anschauen wie etwas funktioniert und entsprechend im Handumdrehen mit dem Notepad adaptieren und modifizieren.
Im Falle von LOTUS beschränkt sich diese Möglichkeit auf die Inhalte in OpenLOTUS und die paar opensource Scriptbeispiele im Lexikon sowie die Public Domain Inhalte, wo vom Entwickler festgelegt wird, ob es modifizierbar ist oder nicht.
Das macht den Einstieg und das selbstständige "basteln" also um ein vielfaches! schwieriger, als das bei OMSI der Fall war.
Zudem halte ich die Art, wie das Lexikon auf lotus-simulator.de integriert ist, für maximal unübersichtlich und schlecht benutzbar.

Die einzige, übriggebliebene Möglichkeit, zu Lösungen zu kommen ohne viel Vorwissen angeeignet zu haben, ist also, sich helfen zu lassen oder erstmal Jahre Zeit zu investieren, um so fit in Scripts zu werden, dass man Sie aus dem Ärmel schüttelt.
Und auch hier spiegelt sich wieder der Egoismus und die Überheblichkeit wieder, die bei LOTUS herrscht: "Kümmere dich selbst, geh uns nicht auf den Sack, bring mehr Eigenleistung ein, Denk dir was aus, nutz die Suche", anstatt einfach gemeinsam an einem Strick zu ziehen, um Inhalte und das Spiel selbst vorwärts zu bringen.
Versteh mich nicht falsch, ich fühle mich auch manchmal von generischen PN's mit "Ich hab da mal ne Frage" genervt, wo ich eigentlich erwarten kann, dass man sich mit einer speziellen Frage an mich wendet. Aber nicht jeder hat jahrelange Erfahrung in dem, was er tut und irgendwann fängt jeder mal an. Ich kann und möchte nicht beurteilen, inwiefern die TigerChris Inhalte das Spiel voran gebracht hätten, aber so oder so hat man - mal wieder - einen potentiellen Entwickler vergrault, anstatt ihm die notwendige Hilfestellung zu geben. Alle haben mal klein angefangen und dumme Fragen gestellt. Ich weiß selbst noch, wie ich Busfanat in 2014 oder so genervt habe, weil ich ne Dresdner DFI umsetzen wollte - heute würde ich meine Fragen als "Cringe" abstempeln, damals wusste ich es einfach nicht besser.

Hier mal nen Beispiel:
Das minimal-script zum bewegen eines Fahrzeuges wurde korrekt im Anhang hinterlegt:

und hier wird vom "im Anhang angehangen" gesprochen, ist aber als Hotlink implementiert, den man aufgrund der fehlenden optischen Unterscheibarkeit kaum erkennen kann:

Einfach inkonsequent und schlampig aufgebaut das ganze. Da war das OMSI Wiki wesentlich angenehmer zu bedienen. Mit nem Kontrastarmen Bildschirm ist man da gegebenenfalls schon aufgeschmissen, falls man nicht zufällig mit der Maus über den Link fährt.

kommt auf den Preis drauf an. Ich fühle mich auch verarscht, wenn die Franzosenbusse, die in 4 Monaten "rausgeschissen" werden, für den gleichen Preis erscheinen wie Projekte, in denen Jahrelange Arbeit steckt.
Ich bin mir allerdings auch sicher, dass man bei diesem Projekt über Umfang und Qualität vermutlich nicht meckern können wird und die Preis/Leistung stimmt.
Dreist finde ich die Aussage, dass nen SG321UL schön wäre, trotzdem keinesfalls. im Grunde zeigt das doch nur das Interesse der Community an diesen Fahrzeugen und wer weiß denn, ob nicht aus den mitgelieferten Fahrzeugen mal nen SG entsteht, eventuell auch als auskopplung und eigenes DLC oder als Mod?
Das war ja von Petterson keinesfalls eine Forderung, sondern nur ein "ach wie schön doch ein SG gewesen wäre". Wie du dich da so getriggert fühlen kannst, ist mir ein Rätsel.

Zitat von TigerChris79

Nabend ,

auch ich werde L als Maperbauer den Rückkehren !!

keine Lust mehr auf die L-Mafia !

Sofern es sich bei dir um den "echten" TigerChris handelt - woher dieser schnelle Sinneswandel? Du warst doch die letzten Tage im LODUS-Forum noch aktiv!

100km Gerolstein - check!

Map: Geröllstein (w.i.p)
Bus: MAN SG292 (w.i.p)

Bus: MAN SG292 (W.I.P) by Krizli29

Karte: Gerolstein

Auf der Oriolus-Seite wird Janine auch im Bereich Objektbau erwähnt.

ja, model.cfg war der falsche begriff, im falle eines scenery-objects kommen die Einträge dann natürlich in die *.sco Datei.

GIF geht nicht, nein.
night-texturen funktionieren ähnlich dem Prinzip von Bamp. du nimmst dafür einfach die variable "licht1" und fügst folgenden Eintrag in die Model.cfg unter dem [mesh] eintrag deines Modells ein:

[matl_change]
Dein_Texturname.jpg
0
light1

[matl_item]

[matl_nightmap]
Dein_Texturname_leuchtend.jpg

besitzt dein Modell nun mehrere Texturen, fügst du den o.g. Code nochmals ein und änderst entsprechend die namen der Textur und der Leuchttextur.

Zitat von Swissletsplay

Ich muss aber auch sagen, dass The Bus schon eine gute Tiefe hat, mittlerweile. Klar, nicht vergleichbar mit OMSI. Aber das ist auch teilweise der Engine geschuldet, denn einen eigenen Bus (samt allen Details) ist nunmal in der Unreal schon komplex...aber gewisse Punkte wie Sound dürften auch nochmals ein Stück besser sein...

Ich hab das nie gelernt und bin mir zu 100% sicher, dass meine, in 2 Stunden zusammengeklöppelte Gelenkbusphysik, qualitativ die von TML bei weitem übersteigt.

Die Busphysik in OMSI ist zudem auch eingekauft (Open Dynamics) und ist quasi eine simple Line-Trace Physik, bei der - quasi - ein "Strahl" an jedem Rad vom oberen Punkt der Aufhängung nach unten geschossen wird. Bei diesem Strahl wird die Entfernung gemessen, bis dieser ein Objekt/Spline/was auch immer mit Kollision trifft. Ist dieser Wert größer als das soll, wird das Fahrzeug abgesenkt, ist es kleiner als der Sollwert, wird es angehoben. Das führt auch zu dem "aufschaukeln" bei niedrigen Framerates, weil die Intervalle der Berechnung immer länger und damit ungenauer werden. Das ist übrigens auch der Weg, den Nvidia's PhysX geht und so auch nativ in der UE umsetzbar ist.

Ich bin es leid, dass hier immer das Argument "Unreal Engine" vorgeschoben wird. Aber muss ja unrealistisch sein, weil sie ja schon "unreal" im Namen hat.
Eine OMSI-like Physik ist in der UE innerhalb weniger Stunden umgesetzt. Das könnte jeder Dulli sogar in Blueprint mit ein wenig Youtube Tutorial und Recherche, wer C++ beherrscht braucht eventuell ein paar Stunden länger, aber es ist auch dort zügig Umsetzbar.

Natürlich muss man, wenn die physikalische Grundlage steht, hier noch die Fahrzeuglogik (korrekt!) Scripten. Da scheitert es schlicht an Fachwissen und Interesse, nicht daran, das TML das nicht könnte. Die OMSI Physik wäre ohne die Pionierarbeit von Marcel und Rüdiger, die Getriebe und Motor in vielen Details umgesetzt haben, auch nicht so gut, wie sie von uns Empfunden wird.
Es ist aber einfacher, das UE Wheeled-Vehicle Template zu nehmen, was man vermutlich schon seit dem Fernbus mitschleppt, auf C++-Ebene halbherzig anzupassen und dann nie wieder anzufassen.

Eine Gewisse Spieltiefe bringt das Spiel mit, keine Frage - aber wenn es "Der BUS" heißt, und das Hauptaugenmerk des Spieles nicht überzeugt, wird hier am Thema Vorbei entwickelt und/oder der falsche Begriff für das Spiel verwendet.

Zitat von Omsifan62

soweit ich weiß hat Chrizzly eig ein update mit dieser variante geplant nur halt ist besagtes update nie gekommen.

So stimmt das nicht ganz. ich hatte mal in einer Nacht- und Nebelaktion das Außenmesh zusammengefriemelt, ja. Es wäre grundsätzlich auch schnell gemacht, das ganze als Update oder eigenes DLC zu veröffentlichen. Um meinem eigenen Qualitätsstandard zu entsprechen, würde das aber auch einen Rework der Stadtbusfamilie selbst bedeuten und zudem fehlen mir wichtige Referenzen, was den restlichen Aufbau angeht. abgesehen von der Fensterkante sind nämlich auch Innenraum, z.T. Podeste und Fahrerkanzel, womöglich Türen und weitere Dinge unterschiedlich. So einfach ist es also nicht, das ganze mal eben in einer vernünftigen Simulationstiefe und ordentlich aussehend umzusetzen.

Zitat von Bottroper Repaints

Als Zusammenfassung für das Thema des Threads habe ich eine übersichtliche Liste aller Busse erstellt, die (meiner Meinung nach) noch für OMSI 2 als AddOns wünschenswert wären (in der linken Spalte die Modelle, in der rechten ggf. die Varianten):

um SL202, SG2x2, SÜ242 und eventuell SM1x2 kümmere ich mich aktuell.

Lebt das Projekt noch?

Eventuell sollte man dort noch nen kleinen Hinweis Verankern, wie sich die Achsenrotationen in OMSI Verhalten, um das Objekt entsprechend zu drehen.

Es wird ja standardmäßig über die x-Achse rotiert, dreht man den Ursprung mittels origin_rot_z um 90°, also quasi um die Hochachse um 90° gedreht, wird das Objekt dann beispielsweise Standardmäßig über die längsachse animiert. Bei Daueranimationen vorallem in Verwendung mit anim_trans relevant, damit man es, je nach originaler Objektausrichtung, auch in die richtige Richtung verschiebt.
Hab jetzt nicht in den Animationen-Eintrag geschaut ob dazu schon ein Hinweis existiert, aber im Rahmen der Daueranimationen sollte das meiner Meinung nach erwähnt werden.

entpacke mal den Inhalt von diesem Archiv in dein OMSI 2/Scripts/ Ordner und ersetze die dort vorhandenen Dateien.
Wenn dieses Problem global auftritt, wurden die AI-Car-Scripts modifiziert. das archiv enthält die originale aus der Vanilla OMSI Installation.

Zitat von DerGrafikfehler

Wenn du z.B. nur zwei Optionen hast, kannst du die Zahl 3 auch einfach durch 2 ersetzen. Dann wird entsprechend so gezählt: 0, 1, 0, 1,...

Das geht noch kürzer - ! invertiert ja grundsätzlich, d.h. ein Trigger mit dem Inhalt
(L.L.Deine_Variable) ! (S.L.Deine_Variable) wechselt immer zwischen 0 und 1, weil der Wert jeweils invertiert wird.

Zitat von Bamp

on OMSI her auch nicht.

das stimmt so nur bedingt. Zumindest der Standard X zu o3d Converter heult rum, wenn die Datei zu groß wird. Das lässt sich nur mit 3rd-party Exportern umgehen.