Beiträge von Chrizzly92

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.

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.