Gelenkbus: Scripts für Nachläufer / Scriptshare

**der_Nik_** · 19. Mai 2020

Hallo, ich habe mal eine allgemeine Frage:

Bei Gelenkbusssen werden üblicherweise Scripts nur in der Busdatei des Vorderwagens definiert, im Nachläufer lediglich varlists und Stringvarlists.

Nun will ich ein Script erstellen, in dem Kordinaten aus dem Trailer abgefragt werden müssen.

Würde ich dieses ganz normal in der Main-.bus-Datei einfügen, würde er ja die Kordinaten des Vorderwagens nehmen, deshalb meine Frage:

Kann ich einfach in der Trail-.bus-Datei einen Script- und Constfile-Abschnitt hinzufügen, der dann zusätzlich zum Script des Vorderwagens abgerufen wird, oder funktioniert das anders?

LG Niklas

**der_Nik_** · 21. Mai 2020

Ich würde gerne nochmal nachhaken:

Der Gelenkbus verwendet da wie üblich den [scriptshare]-Befehl im Nachläufer.

Schließt dieser Befehl aus, dass der Nachläufer über zusätzliche Scripte (mit Positionsabfrage) verfügt?

Ansonsten müsste ich ja alle Scripts doppelt eintragen bzw. ich würde Vermuten dass ohne Scriptshare die beiden Wagen nicht mehr miteinander kommunizieren können?

Wie könnte man die Positionsabfrage sonst lösen?

Würde mich über Hilfe freuen!

LG Niklas

**Chrizzly92** · 21. Mai 2020

welche koordianten willst du denn auslesen, bzw. was hast du denn vor?

**der_Nik_** · 21. Mai 2020

Zitat von Chrizzly92

welche koordianten willst du denn auslesen, bzw. was hast du denn vor?

Deine Schilderungen im OOF (oder wars Lotus?)-Thread haben mich dazu animiert, einen O-Bus (zum Test ST18) zu scripten (in der Tram-Version 2.2). Da bei diesen die Stromabnehmer auf dem Heck angebracht sind, muss ich ja auch die GetHeightAbovePoint-Abfrage von den Kordinaten her Relativ zum Nachläufer passieren, da es ansonsten beim Einlenken zu gravierenden Abweichungen kommen würde.

**Chrizzly92** · 21. Mai 2020

ahh, ich verstehe. Das ist wirklich eine berechtigte Frage und diese kann ich ohne eigene Tests auch nur spekulativ beantworten.
Die GetHeightAbovePoint Variable erwartet die koordinaten an einem absoluten Punkt, abhängig vom Nullpunkt Des Fahrzeuges aus. Das Impliziert, dass das in einem Nachläufer rein technisch gar nicht gehen würde - denn dieser bewegt sich ja. Ich würde also die Logik für einen O-Bus in ein eigenes script werfen, dass du nur im Nachläufer implementierst. Das sollte trotz scriptshare gehen. eventuell könnte man sogar Steuerleitungen eines Zuges zwischen die Wagen hängen - dann wäre auch eine Kommunikation ohne Scriptshare möglich - ob das geht weiß ich aber nicht.

Halt mich gern auf dem laufenden, was deine Tests angeht!

Ich lass dir hier auch nochmal meine Idee da, wie so etwas umsetzbar wäre.

Ich würde eine Spline bauen, die über dem Fahrdraht eine "einbuchtung" hat, die von GetHeightAbovePoint erkannt wird. links und rechts in unterschiedlichen höhen, damit du per Script die beiden abnehmer unterscheiden kannst. das würde auch unterschiedliche breiten des Fahrdrahtes ermöglichen. Einfacher wäre natürlich eine Einbuchtung zwischen den Fahrdrähten und damit würde ich auch erstmal an deiner stelle beginnen.

Hast du so eine Spline fertig, setzt du am besten die Abfrage der GetHeightabovePoint in Sollhöhe des Stromabnehmers. davon brauchst du allerdings eine ganze menge, damit der Stromabnehmer der Leitung auch entsprechend realistisch folgt. Diese vergleichst du miteinander und kannst so den Punkt finden, der aktuell von den anderen Abweicht - also den, wo der Panthograf hin soll.

Für eine Weichensteuerung könntest du beispielsweise auf Höhe der Fahrerposition links und rechts unter dem boden wieder mehrere GetHeightAbovePoint Abfragen positionieren. Dann setzt du, wenn du dich zum Beispiel auf einer Linksabbiegerspur befindest, einen Dummycube unter die karte, die dann von GetHeightAbovePoint erkannt wird. hast du links eins, merkst du dir vor dass, sobald deine GetHeightAbovePoint abfragen zeigen dass sich die Fahrbahn trennt, der Panthograf eher linksseitig geführt werden soll. Wie du das bei einem Gelenkbus allerdings durch das Fahrzeug schleifst, weiß ich noch nicht.

Bedenken musst du allerdings, dass es sich nur um Annäherungswerte handelt - ändert sich zum Beispiel die Höhe des Fahrdrahtes, würde sich ja auch die Position der GetHeightAbovePoint Abfragen ändern. Theoretisch könnte man diese Punkte aber auch mimt einer "Höhenerkennung" kombinieren und dann entsprechend die Punkte zum Auslesen verschieben.
Das Script dafür wird dann aber auch entsprechend komplex und ich weiß nicht, ob das einen großen EInfluss auf die Performance hätte. War meinerseits bisher ja auch nur trockene Theorie.

**der_Nik_** · 21. Mai 2020

Hallo Chrizzly, danke für deine Ausführliche Antwort!

Ich verstehe deinen Oberleitungsaufbau nich nicht ganz. Wenn ich mir den GetHeightAbovePoint im OMSI-Wiki anschaue, sehe ich das so, dass ich damit den Abstand eines Punktes zur nächsten darunterliegenden Objekt-/Splinekollision messe. Den Testpunkt setze ich also auf die Maximale Höhe der Trolleystangen. Jeder Wert, der zwischen diesem Testpunkt und dem Dach des Busses (also z.B. 3m - 6m) liegt, muss eine Oberleitung sein. Welchen Vorteil haben dann 2 Verschiedene Höhen intern in der Oberleitung?

Aktuell habe ich erstmal folgendes Geplant:

- Die Oberleitung besteht der Einfachheit halber aus einer zusammenhängenden Spline mit Mittiger Kollision von 10cm.

- Ich beherrsche Blender leider nicht, deshalb habe ich aktuell nur ein Testweises Trolleystangen-Provisorium aus Lublin aufs Dach gebaut, welches leider ein Starres Teil ist. Später sollte es mit 2 Seperaten Objekten trotz nur einer Kollision möglich sein, die Stangen halbwegs Präzise zu lenken

- Ich arbeite erstmal mit 10cm Spiel bei den Stangen. Wie genau man später wird, entscheidet die Performance.

- Die Oberleitungserkennung ist aus Performancegründen an If-Schleifen Gebunden: 1. Abfrage: bisherige Position, 2. Abfrage: +/- 10cm dieser Position (nacheinander in If-Schleifen). Ist die Abweichung Größer, Startet ein "Reset-Vorgang", der von 4,5 bis -4,5 (damit die linksliegende Gegenspur nicht fälschlicherweise erkannt wird) alles durchprüft.

Aktueller Stand: Im Vorderwagen dunktioniert das soweit, wenn ich das Script jedoch im Trailer eintrage, wird es nicht mehr erkannt und die Macros (diese werden im Main-Script aufgerufen) werden als ungültig ausgegeben.

Hier der Einträge im Trailer:

Code

[scriptshare]

    ////////////////////////////////////////////////////////
        Scripts
    ////////////////////////////////////////////////////////

[varnamelist]
24
script\AI_varlist.txt
script\Collision_varlist.txt
script\antrieb_varlist.txt
script\engine_varlist_turbo.txt
script\elec_varlist_turbo.txt
script\bremse_varlist.txt
script\auspuff_varlist.txt
script\lights_varlist.txt
script\door_varlist.txt
script\wiper_varlist.txt
script\cockpit_varlist.txt
script\klappern_varlist.txt
script\heizung_varlist.txt
script\rain_varlist.txt
script\dirt_varlist.txt
script\ALMEX_varlist.txt
script\churakrueger\VMatrix_varlist.txt
script\wimpel_varlist.txt
script\visual_varlist.txt
script\cashdesk_varlist.txt
script\VDV_varlist.txt
script\spray_varlist.txt
script\articulation_varlist.txt
script\trolley\trolley_varlist.txt

[stringvarnamelist]
4
script\ALMEX_stringvarlist.txt
script\churakrueger\vMatrix_stringvarlist.txt
script\cockpit_stringvarlist.txt
script\VDV_stringvarlist.txt

[script]
1
script\trolley\trolley.osc

[constfile]
1
script\trolley\trolley_constfile.txt

Alles anzeigen

Habe ich da irgendeinen Fehler gemacht oder funktioniert das kombinierte Script- und Scriptshare-Sxstem wirklich nicht?

LG Niklas

**Gamingonk** · 22. Mai 2020

Vermute mal, dass Omsi herumzickt, da zwar Scriptshare genutzt werden soll, jedoch der Nachläufer nicht die selbe Anzahl an zu ladenden Scripts hat, als der Vorderwagen.

Die [script] und [constfile]-Einträge müssen die selbe Anzahl im Nachläufer haben, wie der Vorderwagen.

**der_Nik_** · 22. Mai 2020

Zitat von GAMINGONK

Vermute mal, dass Omsi herumzickt, da zwar Scriptshare genutzt werden soll, jedoch der Nachläufer nicht die selbe Anzahl an zu ladenden Scripts hat, als der Vorderwagen.
Die [script] und [constfile]-Einträge müssen die selbe Anzahl im Nachläufer haben, wie der Vorderwagen.

würde das Bedeuten, dass er jedes Script doppelt läd?

Was mich halt wundert ist, dass OMSI keinen Scriptshare-Error auswirft, sondern einfach das Script nicht erkennt...

**DerGrafikfehler** · 22. Mai 2020

Für das Problem wäre glaub ich tempo1 der beste Ansprechpartner, der hat mWn die NF6D gebaut/war an der beteiligt, und bei der sind ebenfalls verschiedene Scripte in verschiedenen Fahrzeugteilen eingetragen.

**Chrizzly92** · 22. Mai 2020

Nun, einen Vorteil haben diese eigentlich nicht, da stimme ich dir zu. Ist aber einfach sauberer Meiner Meinung nach. Dazu kommt, dass - wenn er die Oberleitungs"mitte" mal verliert, dann trotzdem in der Nähe bleibt und die Werte auch nicht durch die Decke schnellen. Kann man natürlich auch mit nem script abfangen. Es führen ja viele Wege nach Rom und dein Ansatz funktioniert natürlich genauso.

Wenn du das script im Trailer aufrufst, musst du natürlich die {init} und {frame} schleifen nutzen. wenn du da nen script einträgst, welches andere macronamen hat, musst du diese in den haupt init und frame abschnitt eintragen. Fast jeder Bus in OMSI hat ja ein "main" script, in welchem alle unterscripts und deren macro definiert werden.
also entweder ein basisscript bauen, dass so aussieht:

Code

{init}
    (M.L.trolley_Init)
{end}

{frame}
    (M.L.trolley_Frame)
{end}

welche dann die macros in deinem "sub-script" aufrufen - oder einfach in dein trolley script entsprechend {init} und {frame} verwenden. würde ich zumindest tippen, da ich das script nicht kenne.

Zitat von DerGrafikfehler

Für das Problem wäre glaub ich tempo1 der beste Ansprechpartner, der hat mWn die NF6D gebaut/war an der beteiligt, und bei der sind ebenfalls verschiedene Scripte in verschiedenen Fahrzeugteilen eingetragen.

Dann wohl eher Feindflug oder ich. Unabhängig davon funktioniert die NF6D nicht mit Scriptshare sondern mit Steuerleitungen.

Zitat von GAMINGONK

Vermute mal, dass Omsi herumzickt, da zwar Scriptshare genutzt werden soll, jedoch der Nachläufer nicht die selbe Anzahl an zu ladenden Scripts hat, als der Vorderwagen.
Die [script] und [constfile]-Einträge müssen die selbe Anzahl im Nachläufer haben, wie der Vorderwagen.

wäre ja kein Problem. man kann die variablen für den nachläufer ja in eine x-beliebige constfile oder varlist eintragen.

**der_Nik_** · 22. Mai 2020

Danke für eure Tipps.

Ich habe nun eine Main.osc für den Trailer erstellt und dieses vor dem trolleyscript eingetragen (scriptanzahl auf 2 gestellt). Der Stromabnehmer bleibt jedoch ohne funktion.

Ich werde aber morgen mit der Fehlersuche weitermachen und mich dann melden.

LG Niklas

**Chrizzly92** · 22. Mai 2020

Tatsächlich funktioniert ein separat eingetragenes Script im Trailer nicht in Kombination mit Scriptshare. Interessant.
Jetzt gibts zwei Möglichkeiten: Den Vorderwagen und den Nachläufer via Steuerleitungen verbinden (sofern das geht) oder

die Koordinate der GetHeightAbovePoint Abfragen über den Nick- und Gierwinkel des Gelenkes berechnen.

Edit: alternativ gäbe es noch eine dritte möglichkeit:

Zitat

This command shares the script system. That means that THIS vehicle

will use the entire script system of the previous created vehicle

(it is not important, if this is coupled in front or in the back,

this only depends on which vehicle was create before THIS one)

eventuell könnte man Probieren, den Nachläufer eines Busses als "erstes" Fahrzeug zu definieren und den rest vorn dran zu hängen. das wäre aber recht viel Aufwand.

Edit: geht nicht.

**der_Nik_** · 22. Mai 2020

Ok, danke für den Hinweis. Ich würde es mit Umrechnung des Knickwinkels machen.

Jedoch habe ich ein Problem: Die unten genannte Systemvariable erzeuge eine Zugriffsverletzung.

Zitat

articulation_#_alpha / ~_beta Winkel, um den das #. Gelenk um die Hochachse (alpha) bzw. Querachse (beta) geknickt ist ° X X 2.00

Ich habe es schon mit (L.S.articulation_0_beta) sowie (L.S.articulation_1_beta) ausprobiert, wie lautet den der richtige Befehl für das Gelenk?

Logfile-Auszug

LG Niklas

**tempo1** · 22. Mai 2020

Zitat von DerGrafikfehler

Für das Problem wäre glaub ich tempo1 der beste Ansprechpartner, der hat mWn die NF6D gebaut/war an der beteiligt, und bei der sind ebenfalls verschiedene Scripte in verschiedenen Fahrzeugteilen eingetragen.

Ha! Das schicke Ding ist von @Feindflug, ich kann nur (Kreuzungs-)Editor.

**der_Nik_** · 22. Mai 2020

Die Zugriffsverletzung habe ich mittlerweile wegbekommen, ich musste die articulation als Lokale statt Systemvariable auslesen.

Jetzt habe ich das Problem, dass der Stromabnehmer seit der Implementierung des Knickwinkels mehr oder weniger rumtanzt wie er will (meistens vom einen Extrem ins andere: links-rechts, oben-unten) (davor hat er funktioniert, jedoch Positionsversetzt).

Den Knickwinkel lese ich doch in Grad aus (0 = Mittig), oder habe ich da einen Denkfehler? Die Rotation tanzt herum wie verrückt, die Höhe ist konstant auf maximalem Wert.

Hier der Abschnitt der Knickwinkelberechnung, bei bedarf würde ich das ganze Script per PN zur Verfügung stellen.

Trolley_Verschiebung_X: Der Wert (Meter), um den der Messpunkt vom eigentlichen Punkt entfernt ist

Trolley_Position_X: Der Wert ist die Position des Fahrdrahtes relativ zum Nachläufer/Stromabnehmer

Trolley_Abfrage_X: Der Wert ist die Position des Fahrdrahtes relativ zum Vorderwagen und wird als X-Wert für die Höhenabfrage verwendet.

Trolley_Verschiebung_Y: Der Wert (Meter), um den der Messpunkt durch die Rotation nach vorne verschoben wird. Dieser ist immer negativ/wird vom Script negativ gemacht, da die Nullstellung ja schon den hintersten Punkt darstellt.

Trolley_Abfrage_Y: Der Wert ist die Y-Kordinate der Höhenabfrage, bei Geradem Gelenk 12,5 Meter.

Trolley_Abfrage_Z: Der Wert ist die Z-Kordinate der Höhenabfrage, bei Ebener Strecke 6 Meter.

Code

'X-Achse

    (L.L.articulation_0_beta) sin 8.5 * (S.L.Trolley_Verschiebung_X)
    
    (L.L.Trolley_Position_X) (L.L.Trolley_Verschiebung_X) + (S.L.Trolley_Abfrage_X)
    

    
'Y-Achse
    
    (L.L.Trolley_Verschiebung_X) 0.5 *
    (L.L.articulation_0_beta) sin * (S.L.Trolley_Verschiebung_Y_Value)
    0 >=
    {if}
        (L.L.Trolley_Verschiebung_Y_Value) /-/ (S.L.Trolley_Verschiebung_Y_Value)
    {else}
        (L.L.Trolley_Verschiebung_Y_Value)
    {endif}
    (S.L.Trolley_Verschiebung_Y)
    
    -12.5 (L.L.Trolley_Verschiebung_Y) + (S.L.Trolley_Abfrage_Y)
    
'Z-Achse
    
    6 (L.L.articulation_0_alpha) sin 8.5 * + (S.L.Trolley_Abfrage_Z)

Alles anzeigen

Ich hätte noch ne Frage zur Fehlersuche: Es gab doch so einen Befehl, mit dem man Sachen im roten Text anzeigen lassen kann. Wie funktionierte das nochmal?

**Schleswig-Holstein** · 14. Juli 2020

der_Nik_ Besteht das Problem immer noch?

**der_Nik_** · 14. Juli 2020

Naja, ich muss das ganze halt umgehen, in dem ich säntliche Kordinaten mithilfe des Knickwinkelts umrechne. Hab aber lang nichts mehr dran gemacht.

Gelenkbus: Scripts für Nachläufer / Scriptshare

der_Nik_ 21. Mai 2020

Moderator 10. Oktober 2020

Teilen

Ähnliche Themen

[TUT] & [MOD] fOcUs04's Tüdelecke [eingestellt / discontinued]