Beiträge von Tatra

Wie Wiki-Einträge beinhalten nur eine grobe Übersicht. Das Scripten erlernt man damit sicher nicht.

Ansonsten hat Thomas schon recht:

Zitat von Thomas U.

Mit viel Fleiß

Grundlage ist das Verstehen, wie die Rechnerei in den Scripten abläuft. Das alles zu erklären ist zu Umfangreich. Dahoer solltest du mit kleinen Sachen anfangen, die sehr einfach sind.

(L.L.Variable)

Hiermit wird der Wert einer Variable abgefragt. Ist der Wert "wahr" dann schreibt Omsi eine 1, Ist der Wert "unwahr" oder "falsch" dann schreibt Omsi eine 0.

(L.L.Variable) 0.25 >

Ähnlich in diesem Beispiel. Ist der Zustand des Objektes mit dieser Variable größer als 25% (0.25 = 25%, da 1= 100% ist), dann wird die Variable wahr, also wird 1 geschrieben.

(L.L.Variable) !

Hier wird ebenfalls die Variable ausgelesen und der Wert negiert. Ist die Variable wahr, dann schreibt Omsi 0, ist sie unwahr, schreibt Omsi 1.

Nun kann man einfache Variable berechnen lassen. Dabei gilt immer gleicher Aufbau:

Die Operatoren stehen im Wiki. Hier sind nur UND (&&) und ODER (||). Nun arbeitet Omsi diese Operations ab:

Variable_1 wahr oder unwahr?

UND

Variable_2 wahr oder unwahr?

ODER

Variable_3 wahr oder unwahr?

speichere das Ergebnis in die Variable mit dem Namen "Lösungsvariable".

Bis hierher ist es alles ganz einfach. Da Problem beginnt in den Scripten, weil ich dieses Beispiel unterschiedlich schreiben kann und dennoch kommt immer die selbe Antwort raus.

Noch kurz zur Erkennung der Lösung:

(L.L.Variable_1) Beispiel Wahr = 1

(L.L.Variable_2) && Beispiel unwahr = 0

(S.L.Lösungsvariable) Lösung = 0

Der Rest ist dann die Sache mit dem "logischen Gatter" (Digitaltechnik)

Was heißt das nun? Wann ist eine variable wahr oder unwahr? Beispiel eine einfache Tür. Ist die Tür zu (originale Position aus dem 3D-Programm), dann ist die Variable unwahr. Öffnet sich die Tür, dann bewegt sie sich von = (unwahr) nach = 1 (wahr). Ein Licht kann nur zwei Punkte annehmen. Entweder ist es unwahr (Licht aus) oder es ist wahr (Licht an). Das wiederholt sich mit allen Variabeln:

Soweit der einfache Teil. Jetzt wird es kompliziert. In Omsi gibt es bestimmte Variable, die du nicht umbennen kannst. Das sind die festgelegten Systemvariablen (Wetter, Temperatur, Helligkeit, Sonnenstand, Uhrzeit, usw). Die kannst du nicht ändern. Aber man kann andere Variablen umbenennen und somit auch neue Variablennamen einführen. Ich muß die Variable für den ersten Türflügel nicht (L.L.door_0) nennen, ich kann sie auch (L.L.tuer_A) bezeichnen. Diese Abfrage[L.L.] funktioniert nur, wenn ich die Fahrzeugvariable auch so gespeichert habe [S.L.] (S.L.tuer_A). Fortan muß ich die Türabfrage auch so benennen. Also wenn eine bestimmte Variable in einem Bus einen festgelegten Namen hat, heißt es nicht, das es auch in allen anderen Bussen so sein muß.

Ich empfehle dir, mit wirklich einfachen Sachen anzufangen. Am besten eignet sich der MB O305 von Rolf oder die Busse von M+R Software. Hier sind die Scripte noch sehr übersichtlich. Nun kannst du beim MB O305 kleine Fehler berichtigen oder neue Sachen umbauen. Man kann die fehlerhafte Schaltung des Türlicht berichtigen oder Kontrolleuchten verändern. Das sind so die ersten Schritte, die wirklich sehr einfach sind.

Es ist ratsam, die ersten Gehversuche mit dem Wiki-Eintrag "Scriptsystem" zu erkunden. Damit kannst du anfangen, leichte Berechnungen auszulesen und eigene Schritte in das Script zu pinseln. Wichtig sind die Variablenzugriffe und die Operatoren. Du mußt diese nicht auswendig lernen, du solltest nur wissen, wo diese stehen, damit du immer nachschauen kannst. So merkst du dir das ganze Automatisch.

I might not put it in the transmission script. I was thinking more about coupling the hazard warning light variable, the reversing light or the key trigger. Or you enter the variable for the activation of the reversing light, in the script snippet of the hazard warning lights. The former is certainly easier. I think it makes sense to take in the model.cfg the variable for the tail light and to search for this variable in the script. This variable is then additionally entered at the hazard warning light. In the end, if the reversing light is activated, the hazard warning light should also be activated.

So search for the variable for the hazard warning light and add the variable for the reversing light, in the script (light.osc) or (Cockpit.osc):

or whatever the variables must be.

You have to set that in the script. Either you enter the variable for the Warnblicklicht when setting the reverse gear. Or you write at the entry for the warning light, the activation of the reverse gear. This can be done on all vehicles.

That the reverse gear fails, is not possible in Omsi.

Dann prüfe bitte für deine Windows-Version, wie man versteckte Systemordner aufdeckt. Google hilft dir dabei.

Zitat von Vinhfred

Habe ich auch getan.

Was genau hast du getan?

Nochmal:

Windowsfenster öffnen, oben in der Menüleiste: Organisieren

In der Optionsleiste auf Ordner und Suchoptionen klicken

Im neuen fenster auf den Reiter: Ansicht klicken

Beim Punkt: Geschützte Systemdateien ausblenden (empfohlen) - Haken entfernen

Beim Punkt: Unter versteckte Dateien und Ordner ---> ausgeblendete Dateien, Ordner und Laufwerke anzeigen.

Dann ist der Ordner auch sichtbar.

Windows-Fenster öffnen

Menüpunkt Organisieren

Kartenreiter Ansicht

Menüpunkt Geschützte Systemdateien ausblenden (empfohlen) - Haken entfernen

Dann mußt du in den Ordneroptionen unter Windows, die sichtbarkeit der versteckten Unterorder einschalten.

Meist wird in der door.osc (Also dem Türscript) geregelt, wann ein Pfad frei ist. Omsi-Menschen sehen keine Objekte wie Türen, Sitze oder sonstwas. Daher wird im Script genau geregelt, wann ein Pfad frei ist. Suche in der Door.osc nach Dingen wie Entry und Pax.

Solaris Urbino 18_MO

Bei dir halten sich die Passagiere nichtmal an die Pfadpunkte. Die laufen vom Einstiespunkt direkt zum Ausstiegspunkt. Du mußt die in der Passengercabin vorgegebenen Pfadpunkte nutzen oder neue erstellen und die Positionen genau zuweisen.

Im Omsi-wiki findest du genaue Informationen zur Passengercabin und zur Pfaddatei.

Den Ordner findest du, indem du unter START, bei >>Programme/Dateien suchen<< folgendes einträgst:

%AppData%

Dort findest du den Unterordner: Local darin den Unterordner Rumpelhans, darin den Unterordner HofSuite, indem die Datei liegt.

Möglich ist es, aber das ist bei diesen beiden Maps schwer möglich. Zum einen mußt du bei einer Map, einen Teil der Karte entfernen (Bereich Kagran - Kagraner Platz). Und dann ab Makromanenstraße wieder zusammen stellen. Es gibt einen Grund, warum es bisher nur bei einer einzigen Map gemacht wurde, wo beide Städte fiktiv sind. Der Aufwand ist sehr umfangreich.

Bei Ahlheim&Laurenzbach wurde der fehlende Zwischenteil, einfach neu erstellt. Das ist bei Wien 1+2 schwer möglich.

Es gibt ein Tutorial im Omsi-wiki, das das Zusammenfügen zweier Maps erklärt.

Bei einem Static-Vehicles werden lediglich viele nutzlose Objekte und nicht benötigte Scripte entfernt. Also in der model.cfg werden Sachen wie, Teile des Amaturenbrettes, oder andere im Bus befindliche Objekte entfernt und Scripte die nicht benltigt werden. Hat aber dennoch nichts mit einem Staticviheles zu tun, denn statische Fahrzeuge werden auch mit einem polygonearmen Modell geliefert, um die Belastung für Omsi, stark zu minimieren.

Dafür muß der Träger des Fahrplans, mittels veräänderter o3d-Datei verschoben werden. Dafür ist ein 3D-Programm von nöten und die originale Objektdatei. Andernfalls geht es auch mit einer Daueranimation. Wie man eine Daueranimation erstellt, findest du mehrfach hier im Forum. Nimm die Sucfunktion zur Hilfe.

Vielen Dank für den Hinweis mit dem SDK. Das hilft nun weiter. Hast mir wirklich sehr geholfen.

Hallo Leute.

Könnte mir bitte jemand die einzelnen Strings des Befehls [matl_allcolor] erklären?

Ich weiß, dass der Befehl, die Objektabdunklung im Bus zurücksetzt. Ich sehe auch, dass darunter 14 Strings folgen. Und ich weiß auch, dass der Befehl notwendig ist, weil Omsi die Lichtquellen für den Lichtschein, nur im Spielerbus aktivieren kann. In KI-Bussen bleiben die Objekte im dunkeln.

Aber ich finde nirgendwo eine Erklärung, für was die einzelnen Strings eigentlich stehen. Weiß das zufällig jemand?

Ganz recht. Nicht alle Trigger und Macros sind komplizierte Berechnungen. Solche Abfragen sind recht einfach und in diesem Beispiel sind alle gleich. Die Grundlagen aller Scripte sind, aus den Bussen von M+R software.

Die Umstellung wird in der passengercabin eingetragen. Die Eingänge bekommen die Makierung [entry], die Ausgänge haben die Makierung [exit].

Aber aufpassen. Gibt es nur einen Pfad, für den rechten Türflügel, kann es vorkommen, dass sich die Pahrkunden blockieren.

In dem Script door.osc muß dann noch die Bedingung angepasst werden, damit die Passagier nur einsteigen, wenn auch die Tür geöffnet ist.

100% real geht ohnehin nicht, weil es in Omsi Grenzen gibt. (Verschleißteile wie Bremsen, Kupplung, Öl, Reifen, etc.). iTram hat schon mit dem Heizungsscript mehr umgesetzt, als eigentlich notwendig ist. Es gibt aber weiterhin Grenzen, deren Umsetzung keinen Sinn machen. So ist es in Omsi egal, ob die Heizluft nun aus dem Fußraum kommt oder aus den Gebläsedüsen im Amaturenbrett. Anderes Beispiel waren die bereits angesprochenen Klappsitze, die man in Omsi leider nicht nutzen kann, weil diese die Fahrgastpfade blockieren.

Aber letzten Ende soll der Bus auch mal fertig werden, denn es gibt sehr viele User, die schon gespannt auf diesen Bus warten.

Indem du im Script, wo auch das Kneeling enthalten ist, die Bedingungen entsprechend anpasst.

Suche nach dem Kneeling-Trigger oder Macro und du findest du Türabfragen:

(L.L.door_x) 0 = &&

Irgendsowas steht dort. dann Definierst du die Abfrage neu, indem du den Wert änderst.

[L.L.door_x) 0.91 < &&

Der Wert 0.91 steht hier für die prozetuale Angabe, wie weit die Tür offen ist, oder wie weit die Tür offen sein soll.

Die Werte zwischen 0 (=0%) und 1 (1=100%) können beliebig geändert werden. Je höher die Zahl, desdo früher reagiert das Kneeling. Aber nicht übertreiben, sonst reagiert das Kneeling falsch, also zu früh.

Das sieht bedeutend übersichtlicher aus, als die erste Version. Deine Überarbeitung hat sich wirklich gelohnt.

Man kanne Haltestellen sauber lesen und der Plan wirkt nicht mehr überladen und durcheinander.

Unsere Firma hat leider nur den O408 1 1/2-Decker. Einen reinen O408 habe ich nie fahren können.

Die Reihenfolge der Animationen ist vollkommen egal. Macht keinen Unterschied ob die Daueranimation zuerst, oder die Funktion zuerst eingetragen wurde. Der Fehler lag nur am falschen Objektursprung für die Funktion.