Moin zusammen,
ich bin gerade dabei, mein Haltestellenschild mit einer Alpha-Fläche auszustatten, die sich über das Haltestellenschild legt, um eine Art "Ausgeblichenheit" (durch lang anhaltende Sonneneinstrahlung usw.) darzustellen.
Um dies möglichst dynamisch halten zu können und nicht 70 verschiedene SCO-Dateien zu benötigen, habe ich mich dazu entschieden, die Deckkraft dieser Fläche (und damit den Grad der Ausgeblichenheit) dynamisch per [alphascale] anzugeben. Das Vorgehen ist dann eigentlich recht simpel: Über eine Scriptvariable kann man im Editor über das "Beschriftung"-Fenster eine gewünschte Ausgeblichenheit zwischen 0 und 1 eingeben, ein kleine Script wandelt diesen String einmal in eine Zahl um und speichert sie in eine entsprechende Zahlenvariable, die dann mit alphascale die Deckkraft der Ausgeblichenheit bestimmt.
(Farbe und Form des "Ausbleichungsdings" bitte erstmal ignorieren, das ist bisher nur ein Prototype und irrelevant für mein "Problem")
Das Script nochmal ganz simpel:
{frame}
(L.L.init) !
{if}
'Ausgeblichenheit einmalig setzen und dann über "init" merken, damit es nicht in jedem Frame wieder ausgeführt wird (Performance)
(L.$.Ausgeblichenheit) $StrToFloat (S.L.Ausgeblichenheit)
1 (S.L.init)
{endif}
{end}
Mein Haltestellenschild besteht aber nicht nur aus einem Objekt, sondern aus mehreren Einzelteilen, die im Editor modular zusammengebaut werden können (im Wesentlichen die große Haltestellentafel mit dem Haltestellennamen sowie zusätzlich Linieneinschübe). Diese werden alle per attach to an den Mast (der alleinstehend ein eigenes Objekt ist) geheftet.
Das sieht dann so aus:
Auch diese einzelnen Einschübe haben natürlich die Ausbleichungs-Mechanik, d.h. ebenfalls das Mesh und entsprechende Variablen. Tafel und Einschübe nutzen jedoch nicht die gleiche Stringvarlist, da sie verschiedene Beschriftungsstrings haben, allerdings heißt die "Ausbleichungsvariable" überall gleich.
Und jetzt kommt das überraschende: Wenn ich beim "ersten" Objekt, also der Tafel, einen beliebigen Wert eintrage und die Variable aber bei den Einschüben darunter leer lasse, scheint das oberste Objekt seinen Variablenwert die nachfolgenden zu vererben. In rot habe ich jeweils daneben geschrieben, welchen Wert die einzelnen Objekte bei der Ausbleichung eingetragen haben:
Allerdings lässt es sich scheinbar auch unter gewissen Kriterien überschreiben, dies wird dann auch nach "unten" hin weitergegeben:
Jedoch findet die Vererbung scheinbar nicht zwingend nur von "oben nach unten" (in der Reihenfolge der Objekt-IDs, also der Platzierungsreihenfolge) statt:
Objekt "3" scheint an Objekt "1" zu vererben, aber Nummer 2 nicht anzutasten, da es einen eigenen Wert hat:
Das ganze funktioniert sogar auch, wenn die Objekte garnicht per attach to das gleiche Elternobjekt haben. Diese beiden Dinger wurden vollständig separat nacheinander platziert:
Auch hier funktioniert die Vererbung in beide Richtungen, d.h. egal, welchem Objekt ich einen Wert gebe, das andere ohne Wert nimmt den des ersten an...
Ich frage mich, ob dieses Verhalten irgendwie bewusst in OMSI programmiert wurde bzw. ob das irgendjemandem schon bekannt ist oder vielleicht sogar aktiv genutzt wird oder dazu genaueres bekannt ist.
Grade diese Tatsache, dass die Vererbung scheinbar in beide "Richtungen" von den IDs her klappt, wirft bei mir dann doch Fragen auf, weil mir nicht klar ist, von wo ein Objekt seinen Wert im Zweifelsfall nimmt...
Scheinbar scheint das ganze auch nicht direkt am String-Wert zu liegen sondern eher der dahinterliegende Zahl-Wert vererbt zu werden, wenn dieser "-1" ist (?)
Die Funktion $StrToFloat parst laut Wiki den obersten Stringstack-Wert in einen Float bzw. gibt "-1" aus, wenn die Konvertierung fehlschlägt, z.B. weil der String keine gültige Zahl darstellt (was - denke ich mal, bei einem Leerstring der Fall ist).
Wenn ich jedoch folgende Prüfung in meinem Script hinzufüge, verhindere ich damit, dass eine "-1" ausgegeben wird und interpretiere somit jegliche ungültige oder leere Eingabe als "0":
{frame}
(L.L.init) !
{if}
(L.$.Ausgeblichenheit) $StrToFloat (S.L.Ausgeblichenheit)
'NEU: Interpretiere eine ungültige Eingabe als "0":
-1 = {if} 0 (S.L.Ausgeblichenheit) {endif}
1 (S.L.init)
{endif}
{end}
Alles anzeigen
Diese kleine Änderung sorgt jedoch nun dafür, dass die gesamte Vererbung nicht mehr funktioniert bzw. nicht mehr aktiv ist, daher meine Hypothese dass OMSI "-1" in einer Zahlvariable interpretiert als "ungesetzt, hol dir den Wert von woanders".
Wie gesagt, mich würde mal interessieren, ob es irgendeine Person in der OMSI-Community gibt, er dieses Verhalten bekannt ist und vielleicht mehr darüber weiß...
Edit/Nachtrag:
Ich habe grade, um es genauer zu verstehen, mir mal die Variablenwerte direkt auf das Objekt im Textfeld ausgeben lassen. Das führt zu der Erkenntnis:
Der Variablenwert selbst im Rahmen der Scriptsystems scheint nicht direkt vererbt/überschrieben zu werden, die Variable an sich ist und bleibt tatsächlich "-1". Jedoch scheint OMSI dann bei der Verarbeitung und Darstellung des alphascales (und vielleicht auch noch bei anderen Dingen) den Wert dann nicht zu verwenden, sondern ihn von woanders zu suchen.
In diesem Fall habe ich links verschiedene Werte eingetragen. Rechts bliebt die ganze Zeit leer, daher wird der String als "-1" eingelesen und angezeigt:
Nicht für für "-1", sondern jeden Wert unter 0 ist das Verhalten so:
Ungültige Werte über 1 (ergibt ja an sich auch keinen Sinn für eine Deckkraft) werden aber hingegen wie "1" behandelt:
= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! 
