Lorby's AAO (Axis And Ohs)

  • Guten Abend zusammen,


    ich brauch nochmal Hilfe.


    Über (>K:scriptgroup-scriptname) kann ich aus einem Script ein anderes aufrufen.

    Aber wie kann ich dem zweiten Script einen Parameter übergeben? Bzw. wie kann ich den Paremter im zweiten Sript auslesen?


    Ich hätte erwartet, ich schieb den Wert einfach auf den Stack - aber im zweiten Script ist der Stack leer.


    Also z.B.


    7 (>K:MyScriptGroup-MyScript)


    und in MyScriptGroup-MyScript:


    (A:AUTOPILOT·HEADING·LOCK·DIR,·Degrees) + dnor (>K:HEADING_BUG_SET)



    Also nimm das aktuelle Heading, addiere den übergebenen Wert (vom Stack, in dem Fall also 7), normalisiere und setze das Heading.


    Funktioniert aber nicht.



    Einziger Weg, den ich gefunden habe ist den Wert im ersten Script in eine LVar zu schreiben und diese im zweiten Script auszulesen. Gefällt mir aber nicht wirklich.

    Gibt's eine bessere Möglichkeit?



    Danke und Gruß,


    Thomas

  • Guten Tag Thomas,


    leider bist du auf die letzte Unterhaltung nicht mehr eingegangen.


    Zu deinem aktuellen Problem: Ich weiß nicht ob das geht, aber das Script ist so auch nicht richtig.

    Herzliche Grüße :)

    Oliver

  • Moin Oliver,


    sorry, ich hab nicht geantwortet, da ich noch am herumprobieren bin, ob Dein Vorschlag das richtige für mich ist.

    Ich habe meine komplette Konfiguration gelöscht und angefangen alles neu zu programmieren unter eine neuen Namenskonvention. Das "jeder Button triggert immer ein RPN Script" möchte ich so umsetzen - das scheint mir wartungsfreundlicher zu sein als Variablen oder Events direkt als Aktion zu hinterlegen.


    Ich habe noch nicht viel, da ich oft noch am Probieren und Testen bin - und vielleicht werfe ich auch das alles nochmal über Board, wenn ich feststelle, dass ich damit nicht zufrieden bin...


    Sobald ich einen Status habe, mit dem ich zufrieden bin, lasse ich es Euch hier wissen :)



    Das Kernstück, an dem ich gerade arbeite, ist die Action, die der right Rotary auf meinem Bravo auslösen soll. Der Part sieht aktuell so aus:


    (L:AAO_Inputs_Rotary_Select) 0 == if{ (L:Generic-Inputs_RotaryChange) (L:AAO_Inputs_Shift) 900 * 100 * + (>L:Generic-Autopilot_ChangeAltitude)·1·(>K:Generic-Autopilot_ChangeAltitude) }

    els{ (L:AAO_Inputs_Rotary_Select) 2 == if{ (L:Generic-Inputs_RotaryChange) (L:AAO_Inputs_Shift) 9 * 1 * + (>L:Generic-Autopilot_ChangeHeading)·1·(>K:Generic-Autopilot_ChangeHeading) }

    els{ (L:AAO_Inputs_Rotary_Select) 5 == if{ (L:Generic-Inputs_RotaryChange) (L:AAO_Inputs_Shift) 0.9 * 0.1 * + (>L:Generic-Avionics_ChangeNavFrequency)·1·(>K:Generic-Avionics_ChangeNavFrequency)}

    els{ (L:AAO_Inputs_Rotary_Select) 6 == if{ (L:Generic-Inputs_RotaryChange) (L:AAO_Inputs_Shift) 0.9 * 0.1 * + (>L:Generic-Avionics_ChangeComFrequency)·1·(>K:Generic-Avionics_ChangeComFrequency)}

    els{ (L:AAO_Inputs_Rotary_Select) 7 == if{ (L:Generic-Inputs_RotaryChange)·(>L:Generic-Avionics_ChangeBarometer) 1·(>K:Generic-Avionics_ChangeBarometer)}

    }}}}


    Wie Du siehst rufe ich aus dem je nach Status das Left Rotary und meines "Shift" Buttons andere Scripte auf, die dann wiederum die eigentliche Aktion ausführen.

    Beispiel Altitude: Ich definiere als Action den Aufruf des o.g. Scripts mit dem Input +1 (bei Increment) bzw -1 (bei Decrement):



    Im Script berechne ich dann, ob ich um 100 (Shift=0) oder 1000 (Shift=1) erhöhen bzw. erniedrigen möchte und triggere dann das Generic-Autopilot_ChangeAltitude Script (eben mit den Werten -1000, -100, 100 oder 1000).

    Das funktioniert alles - ich finde es nur unschön, dass ich den Änderungswert nur über (>L:Generic-Autopilot_ChangeAltitude) übergeben kann - deshalb meine Frage, ob das nicht einfacher geht. Über den Stack funktioniert es halt leider nicht - oder ich mache etwas falsch...)


    Btw - den oben gezeigten Script-Code hebe ich mir zur Pflege so mit Einrückungen und Zeilenumbruch in einem Text-Editor auf. Im XML wird nach Entfernen der ganzen Formatierung


    (L:AAO_Inputs_Rotary_Select)·0·==·if{·(L:Generic-Inputs_RotaryChange)·(L:AAO_Inputs_Shift)·900·*·100·*·+·(>L:Generic-Autopilot_ChangeAltitude)·1·(>K:Generic-Autopilot_ChangeAltitude)·}·els{·(L:AAO_Inputs_Rotary_Select)·2·==·if{·(L:Generic-Inputs_RotaryChange)·(L:AAO_Inputs_Shift)·9·*·1·*·+·(>L:Generic-Autopilot_ChangeHeading)·1·(>K:Generic-Autopilot_ChangeHeading)·}·els{·(L:AAO_Inputs_Rotary_Select)·5·==·if{·(L:Generic-Inputs_RotaryChange)·(L:AAO_Inputs_Shift)·0.9·*·0.1·*·+·(>L:Generic-Avionics_ChangeNavFrequency)·1·(>K:Generic-Avionics_ChangeNavFrequency)}·els{·(L:AAO_Inputs_Rotary_Select)·6·==·if{·(L:Generic-Inputs_RotaryChange)·(L:AAO_Inputs_Shift)·0.9·*·0.1·*·+·(>L:Generic-Avionics_ChangeComFrequency)·1·(>K:Generic-Avionics_ChangeComFrequency)}·els{·(L:AAO_Inputs_Rotary_Select)·7·==·if{·(L:Generic-Inputs_RotaryChange)·(>L:Generic-Avionics_ChangeBarometer)·1·(>K:Generic-Avionics_ChangeBarometer)}·}}}}


    Das ist natürlich der selbe Code -nur lässt er sich extrem schwierig lesen und verändern. Wie macht ihr das?



    Falls es hilft meinen Ansatz besser zu verstehen habe ich mal mein komplettes XML angehängt (da ist wie gesagt noch nicht viel drin, weil ich komplett neu angefangen habe)...


    UserScripts_MSFS.txt


    Viele Grüße,


    Thomas

  • Hallo Thomas,


    danke, das war schon aussagekräftiger. Oben für den dnor auf die Leerzeichen und die Notation achten. Zum Beispiel: Aus "3+5" wird "3 5 +". Wobei ich bezweifle, ob das so geht. Ich würde da immer direkt eine Variable ansprechen.


    Zur Übersichtlichkeit vielleicht noch der Hinweis, dass du nicht zwingend mit "els" arbeiten musst. Das Skript könnte auch lauten (nur Bedingungen):

    (L:AAO_Inputs_Rotary_Select)·0·==·if...........

    (L:AAO_Inputs_Rotary_Select)·1·==·if...........

    (L:AAO_Inputs_Rotary_Select)·2·==·if...........

    (L:AAO_Inputs_Rotary_Select)·3·==·if...........

    usw.


    Dann ist es nicht so verschachtelt - dann hast du einfach nur 7 Bedingungen. Vielleicht beschafft du dir (wenn kein Stream Deck) so ein 55 Euro Behringer X-Touch Mini. Das arbeitet hervorragend mit AAO zusammen. Da kannst dir auch Schablonen drucken lassen.


    Je nach Flugzeugtyp kann man zum Erhöhen des gewünschten Wertes dann auch das äußere oder innere Drehrad ansprechen. Oder tatsächlich mit Long- oder Shortklick arbeiten.

    Herzliche Grüße :)

    Oliver

  • Mit dem Einsparen des Else hast Du natürlich recht! Werde ich umsetzen!


    Ich glaub ich hab da im Code einmal * und + vertauscht - muss ich mir aber nochmal in Ruhe anschauen, kann das jetzt nicht testen.

    Eine allgemeine Frage zu RPN:

    3 * 1000 + 500 lässt sich auf zwei Arten in RPN schreiben:

    3 1000 * 500 +
    500 3 1000 * +


    Ich denke es ist egal - oder doch nicht?

  • Hallo Thomas,


    ich selber hab die RPN-Sprache auch nicht gelernt, kenne das selbst nur, weil ich mir das im gewissen Umfang für AAO angeeignet habe.

    Also ich bin nicht viel weiter wie du. :)


    Die erste Zeile sieht richtig aus, untere Zeile kommt mir komisch vor. Im Zweifel das einfach in den Editor hauen und das Ergebnis überprüfen (Test-Funktion). Ich weiß auch nicht, wie das in RPN mit Punkt vor Strich ist.

    Herzliche Grüße :)

    Oliver

  • Guten Tag,


    täglich lernen wir etwas zur rpn-Sprache (Reverse polish Notation) dazu.


    Wer sich näher mit dieser Sprache beschäftigt hat, kennt sicherlich die rpn-Abhandlung für Prepar3D, die auch auf den MSFS übertragbar ist. Lange Zeit war es das wichtigste Nachschlagewerk für dieses Thema.


    Heute möchte ich den Interessierten nur kurz weitergeben, dass sich auch die entsprechende Abhandlung für den MSFS mächtig gemausert hat. Ein wirklich sehr gutes Nachschlagewerk und fast unerlässlich zum Lernen der Sprache.

    Herzliche Grüße :)

    Oliver

    2 Mal editiert, zuletzt von plerzelwupp ()

  • Servus zusammen,


    wie bereits jemand (ich glaub es war Oliver) schon mal gesagt hat, besteht der größte Aufwand darin, die richtigen Events oder Variablen zu finden, die die gewünschte Aktion auslöst.

    Warum sollte jeder für sich selbst diesen Aufwand betreiben? Wenn es doch schonmal wer gefunden hat, dann können doch alle davon profitieren...


    Es gibt ja den Thread zur Verfügungstellung der kompletten Profile. Finde ich klasse - aber das funktioniert halt nur, wenn man auch das gleich Equipment hat. Ansonsten ist man auch wieder am bauen (kann natürlich einige Dinge abschauen, klar).


    Ich habe mir für alle genutzten Funktionen RPN Scripts gebaut (und werde noch mehr bauen - allein die Zeit...). Alle haben sie einen Input Parameter. Im einfachsten Fall 0 für off und 1 für on. -1 für toggle.


    Beispiel: VS Mode


    (L:Generic-Autopilot_VerticalSpeedMode)·-1·==·if{·1·(>K:AP_PANEL_VS_HOLD)} -- wenn Input -1 => toggle

    (L:Generic-Autopilot_VerticalSpeedMode)·0·==·if{·1·(>K:AP_PANEL_VS_OFF)} -- wenn Input 0 => off

    (L:Generic-Autopilot_VerticalSpeedMode)·1·==·if{·1·(>K:AP_PANEL_VS_ON)} -- wenn Input 1 => on



    Der Parameter lässt sich beim "assigned Button" ja einfach auswählen:



    Wer statt toggle einen On/Off Schalter benutzt trägt dann halt eben 0 oder 1 als Parameter ein. Damit ist das Script doch sehr flexibel einsetzbar.



    Beim Autopilot Master hab ich kein on/off gefunden sondern nur den toggle - aber das Verhalten des RPN Scripts ist genau gleich:


    (L:Generic-AutoPilot_Master)·-1 ==· -- wenn Input -1

    (A:AUTOPILOT·MASTER,·Bool)·(L:Generic-AutoPilot_Master)·!=·or· -- oder wenn Input und aktuelle Einstellung nicht gleich (wenn on gewünscht aber ist schon on oder wenn off gewünscht aber ist schon off, dann einfach keine Reaktion)

    if{1·(>K:AP_MASTER)} -- => dann toggle


    Also auch hier funktionieren damit dann -1, 0 und 1 als Input.
    Damit lässt sich der Master als Toggle z.b. auf die Autopilot-Taste legen - den disconnect-Button am Yoke habe ich aber dann nicht mit toggle sondern mit 0 (off) getriggert.



    Bei Aktionen mit rauf/runter habe ich +1 und -1 als Parameter genutzt.


    Bespiel Change Barometer setting:


    (L:Generic-Avionics_ChangeBarometer)·-1·==·if{·1·(>H:AS1000_PFD_BARO_DEC,·Number)} -- wenn Input -1 => Baro Einstellung eins runter

    (L:Generic-Avionics_ChangeBarometer)·1·==·if{·1·(>H:AS1000_PFD_BARO_INC,·Number)} -- wenn Input +1 => Baro Einstellung eins rauf



    Das ganze lässt sich noch ausbauen, z.b. bei den Flaps:


    (L:Generic-FlightControls_Flaps)·-2·==·if{·1·(>K:FLAPS_UP)} -- wenn Input -2 => Flapps voll einfahren

    (L:Generic-FlightControls_Flaps)·-1·==·if{·1·(>K:FLAPS_DECR)} -- wenn Input -1 => Flapps eine Stufe einfahren

    (L:Generic-FlightControls_Flaps)·1·==·if{·1·(>K:FLAPS_INCR)} -- wenn Input +1 => Flapps eine Stufe ausfahren

    (L:Generic-FlightControls_Flaps)·2·==·if{·1·(>K:FLAPS_DOWN)} -- wenn Input +2 => Flapps voll ausfahren



    Und beim Einstellen der Nav-Frequenz:


    (L:Generic-Avionics_ChangeNavFrequency)·-2·== if{ 1·(>K:NAV1_RADIO_WHOLE_DEC)} -- wenn Input -2 => Mhz runterzählen

    (L:Generic-Avionics_ChangeNavFrequency)·-1== if{ 1·(>K:NAV1_RADIO_FRACT_DEC_CARRY)} -- wenn Input -1 => Khz runterzählen

    (L:Generic-Avionics_ChangeNavFrequency)·1 == if{ 1·(>KNAV1_RADIO_FRACT_INC_CARRY)} -- wenn Input 1 => Khz hochzählen

    (L:Generic-Avionics_ChangeNavFrequency)·2·== if{ 1·(>K:NAV1_RADIO_WHOLE_INC)} -- wenn Input 2 => Mhz hochzählen

    Ich glaube mit dieser Art von "Schnittstelle" kann sich jeder einfach die Funktion auf den Button legen, der ihm zusagt.


    Ich hab noch ein paar mehr - das waren jetzt nur ein paar Beispiele, damit ihr versteht, wie ich mir das so gedacht habe.

    Die Scripte können durchaus auch ein wenig komplizierter werden - der, der sie benutzt, muss nur den Namen kennen und welche Parameter das Script erwartet und kann sie nutzen.



    Jetzt meine Fragen an Euch:


    - Besteht überhaupt Interesse an diesen Scripten? Ich bin gerne bereit zu teilen - aber wenn es keinen interessiert, dann brauch ich mir die Arbeit nicht machen :)


    - Wo sollte man diese Scripte denn ablegen? Es wird vermutlich immer wieder zu Erweiterungen oder auch Korrekturen kommen. Da wäre eine "das hier ist der aktuelle Satz" sicherlich hilfreicher, als irgendwelche Threads nach den neuesten Versionen zu durchsuchen. Da ich kein großer Forengänger bin hab ich hier keine Erfahrung.


    - Die Scripte werden nicht für alle Flugzeuge passen. Manche werden bei einigen Flugzeugen nicht benötigt (z.B. Gear Up bei der Cessna 172) - das ist aber ja kein Problem, dann wird das Script halt einfach nirgendwo aufgerufen. Oder die Events/Variablen sind bei anderen Flugzeugen einfach anders. Dann müsste man eben die passenden Events/Variablen für das jeweilige Modell heraussuchen (was zugegebenermaßen sehr aufwändig sein kann - falls jemand zufällig gerade weiß, wie ich den FLC beim G1000 der Cessna 172 ein/ausschalte wäre ich dankbar :-))

    Ich stelle mir aktuell einen "generischen" Satz von Scripten vor, der in den meisten Modellen funktioniert - und dazu dann halt modellspezifische Scripte, die statt der jeweiligen "generischen" bei dem jeweiligen Flugzeug genutzt werden. Hier hoffe ich aber auf Ideen/Vorschläge von den erfahreneren Kollegen, wie man so etwas am geschicktesten organisiert.

    Ich kann aber sicher nicht alle möglichen Modelle selbst abdecken. Gibt es hier welche, die da mitmachen würden? Es könnte sich ja auch "Paten" für ein bestimmtes Modell finden :)


    - Sollten die Scripte dann auch "erläutert" werden? Sprich: Hilfe für die, die RPN selbst lernen wollen? Oder besteht daran kein Interesse? Einfach nur benutzbar sein?


    Hier als Beispiel das aktuelle "Elevator Trim" Script (wobei ich das evtl. nochmal umbauen werde, muss ich nochmal drüber nachdenken):


    (L:Generic-FlightControls_ElevatorTrim)·d·d·1·==·r·-1·==·or·if{·0.0015·0.0135·(L:AAO_Inputs_Shift)·*·+·*·(A:ELEVATOR·TRIM·PCT,·Percent·Over·100)·+·16384·*·(>K:ELEVATOR_TRIM_SET)}·els{·(>K:ELEVATOR_TRIM_SET)}


    Ich bin kein RPN Guru oder sonstwie etwas besonderes. Und ich bin auch kein Pilot (bin ITler...). Wenn mich etwas interessiert, dann lerne ich gerne dazu und teile auch gerne, was ich weiß. Auf diese Weise kommen wir alle voran.


    - Fertige Profile könnte man trotzdem noch im Profilthread posten :)



    Und jetzt bin ich gespannt auf Euer Feedback...



    Gruß,

    Thomas

  • Jetzt meine Fragen an Euch:


    - Besteht überhaupt Interesse an diesen Scripten?


    - Sollten die Scripte dann auch "erläutert" werden? Sprich: Hilfe für die, die RPN selbst lernen wollen? Oder besteht daran kein Interesse? Einfach nur benutzbar sein?

    Also ich hätte Interesse - und würde mich daran aktiv beteiligen.


    Wie man sowas aufbaut müsste überlegt werden. Ob insbesondere eine Forensoftware dafür das geeigneste Mittel ist.


    Kurze Erklärungen wären m.E. super. Das hilft einem im Zweifelsfall ja auch bei der Erstellung anderer Skripte.

  • Klar, darum sollte es hier gehen :)

    Herzliche Grüße :)

    Oliver

  • Ok, ich poste mal, was ich aktuell habe. Erläuterung nur dort, wo es meiner Meinung nach etwas zu sagen gibt. Die Settings habe ich alle auf der Asobo Cessna 172 G1000 getestet - inwieweit andere Modelle damit funktionieren, kann ich noch nicht sagen.

    Ich bin kein Pilot und habe auch nicht wirklich viel Background Know-How. Wenn man Scripte besser anders benennen oder einsortieren sollte, dann nehm ich das gerne entgegen - aber dann bitte gleich, bevor es an zu vielen Stellen geändert werden muss..


    Vorhandenen Scripte:


    Schalter:

    - Autopilot_AirspeedHold (-1, 0, 1 = toggle, off, on) - funktioniert nicht, habe noch nicht die korrekten Variablen/Events gefunden

    - Autopilot_AltitudeHold (-1, 0, 1 = toggle, off, on)

    - Autopilot_ApproachMode (-1, 0, 1 = toggle, off, on)

    - Autopilot_BackCourse (-1, 0, 1 = toggle, off, on) - konnte ich noch nicht testen

    - Autopilot_CurrentToAP (-1, 0, 1 = toggle, off, on) - überträgt aktuell aktuelles Heading in den AP - will ich noch erweitern um z.B. aktuelles Heading -> OBS1, ...

    - Autopilot_HeadingHold (-1, 0, 1 = toggle, off, on)

    - Autopilot_Master (-1, 0, 1 = toggle, off, on)

    - Autopilot_NavMode (-1, 0, 1 = toggle, off, on)

    - Autopilot_VerticalSpeedMode (-1, 0, 1 = toggle, off, on)

    - Avionics_SwapFrequency - keine Parameter, aber globale Variable - Erklärung bei "Rotary_Select"

    - Electronics_Alternator (0, 1, 2..5 = off, on, ...) - Erklärung unten

    - Electronics_Avionics (0, 1, 2..5 = off, on, ...) - Erklärung unten

    - Electronics_Battery (0, 1 , 2..29 = off, on, ...) - Erklärung unten

    - Electronics_Magnetos (0,1,2,3,4 = off, right, left, both, start) - wird noch erweitert wie die 3 davor

    - FlightControls_ParkingBrakes (-1, 0, 1 = toggle, off, on) - Ich weiß, sind keine "Flight" Controls. Aber ich wollte nicht zu viele Kategorien definieren.

    - Lights_Beacon (0, 1 = off, on)

    - Lights_Landing (0, 1 = off, on) - Erweiterung für mehrere Landing-Lights geplant

    - Lights_Navigation (0, 1 = off, on)

    - Lights_Strobe (0, 1 = off, on)

    - Lights_Taxi (0, 1 = off, on) - Erweiterung für mehrere Taxi-Lights geplant


    Die o.g Scripte sollte klar sein - bis auf die "Electronics". Auf die will ich hier deshalb nochmal genauer eingehen.


    Zur Erklärung das Battery Script. Die anderen sind von der Idee gleich.

    Es gibt 4 Battery Events. Ich wollte das Script so gestalten, dass man alle gleichzeitig, aber auch jede Batterie einzeln schalten kann (für die, die ganz viele Schalter haben :) ). Und die Idee wollte ich dann auch bei den 2 Alternator und 2 Avionic Switchen und... überall, wo es mehr als nur ein einzelnes Element gibt. Extrembeispiel dürften die FuelPumps in der 747 werden, das sind schon einige... :)


    Idee war: 0: alle aus, 1: alle an. Und wie bekomme ich die einzeln an?

    Batterie 1 hat den Wert 2

    Batterie 2 hat den Wert 4

    Batterie 3 hat den Wert 8

    Batterie 4 hat den Wert 16

    aus = 0, an = 1


    Will ich also Batterie 1 einschalten, schicke ich den Wert 2+1 = 3

    Will ich Batterie 2 ausschalten, schicke ich den Wert 4+0 = 4

    Will ich Batterie 3+4 einschalten, schicke ich den Wert 8+16+1 = 25

    Ihr versteht schon...

    Damit wären alle an also 2+4+8+16+1=31 und alle aus 2+4+8+16=30. Das funktioniert auch.

    Aber: 1. wollte ich gerne 0 und 1 beibehalten (einheitliches "Look&Feel") und 2. würde sich "alles an bzw. alles aus" verändern, wenn wir in Zukunft mal eine 5. Batterie dazunehmen müssten (ok, eher unwahrscheinlich, aber ich will das Schema ja mehrfach verwenden - und da könnte uns das vielleicht doch passieren). Dann wären wir nicht mehr abwärstkompatibel.. Deshalb habe ich 0 auf 30 und 1 auf 31 gesetzt..


    Jetzt der Code:

    Code
    (L:Generic-Electronics_Battery) d 65534 & 0 == if{ 65534 |} sp0
    l0 1 & if{ l0 2 & if{ 1 (>K:BATTERY1_SET)}
               l0 4 & if{ 1 (>K:BATTERY2_SET)}
               l0 8 & if{ 1 (>K:BATTERY3_SET)}
               l0 16 & if{ 1 (>K:BATTERY4_SET)}}
          els{ l0 2 & if{ 0 (>K:BATTERY1_SET)}
               l0 4 & if{ 0 (>K:BATTERY2_SET)}
               l0 8 & if{ 0 (>K:BATTERY3_SET)}
               10 16 & if{ 0 (>K:BATTERY4_SET)}}

    Das sieht vermutlich ziemlich strange aus. Deshalb hier Erklärungen dazu

    Der ganze Input wird als Bitfolge interpretiert. Bit 0 steht für an/aus, Bit 1 für Batterie 1, Bit 2 für Batterie 2 usw.


    Batterie 4
    Batterie 3Batterie 2Batterie 1an/ausBinärdarstellung
    Dezimal
    00
    0
    1
    1
    00011
    3
    00
    1
    0
    0
    00100
    4
    11
    0
    0
    1
    11001
    25
    111101111030
    111111111131


    Der Windows-Taschenrechner kann im Programmierer-Modus auch Binärzahlen - wer es nachrechnen will...


    Lasst mich die Funktion mal am Beispiel 25 erklären.


    BefehlStack
    (L:Generic-Electronics_Battery)25
    d25 25
    65534 (das ist 1111111111111110)
    25 25 65534
    & (damit wurd aus der Zahl davor das Bit 0 ignoriert, aus 000000000001101 wird damit 000000000001100 (=24) nur bei 0 und 1 kommt dabei 0 heraus, bei allen anderen Werten etwas anderes)
    25 24
    025 24 0
    == (prüfen, ob 24 = 0 ist)
    25 False
    if{  } (ist nicht True, also keine Ausführung
    25
    sp0 (in einer internen Variable0 speichern, da wir den Wert noch ein paar mal brauchen)
    leer
    falls 0 rauskommen würde...  65534
    0 oder 1 65534
    | (setzt alle Bits auf 1, bis auf das Bit 0, aus 0000000000000000 wird 1111111111111110, aus 0000000000000001 wird 1111111111111111. Das sind nicht 30 bzw 31, sondern ich habe damit schon für 15 "Batterien" vorgesorgt :)
    65534 oder 65535
    sp0 (in einer internen Variable0 speichern, da wir den Wert noch ein paar mal brauchen)
    leer
    l0 (das holt den Wert aus der Variablen 0 wieder raus, ohne sie zu löschen)
    25
    125 1
    & (Hier wird nur das Bit 0 geprüft, also "an oder aus"
    1
    if{ (wenn 1 rauskommt, dann ausführen - wir haben also "an" ausgewählt)
    leer
    l025
    225 2
    & (Hier wird das Bit 1 geprüft - also ob Batterie 1 gewählt wurde)
    0
    if{ (nein, wurde nicht gewählt...)
    leer
    ...
    l025
    8 (Bit 3, also Batterie 3)
    25 8
    &8
    if{ ja, Batterie 3 wurde gewählt. Ich mache mir hier zunutze, dass 0 beim if{ als "falsch" und alles andere als "richtig" gewertet wird)
    leer
    ... (Rest sollte jetzt klar sein)


    So - ich hoffe nach der Erklärung ist das ganze jetzt nicht mehr so wirres Zeugs :)


    Das Script funktioniert mit 1, 2, oder bis zu 15 "Batterien". Der selbe Code lässt sich also für die Avionic-, Alternator-, Batterie-, Fuel-Pumps und was weiß ich noch für Schalter einsetzen, bei denen es mehrere Geräte gibt, die u.U. trotzdem einzeln geschaltet werden sollen. Und wenn man nachträglich von 2 auf 3 oder mehr erweitert, bleiben die Werte für alle (0,1) sowie die Zahlen für die bisherigen Geräte gleich - ist also abwärtskompatibel. Deshalb habe ich das so ausführlich erklärt...


    Drehregler oder vergleichbar:

    - Autopilot_ChangeAirspeed (-1, 1 = eine Einheit runter, eine Einheit hoch)

    - Autopilot_ChangeAltitude (x = Altitude um x Einheiten runter (<0) oder hoch (>0). x muss vielfaches von 100 sein)

    - Autopilot_ChangeCourse (x = Course1 um x Einheiten runter (<0) oder hoch (>0). Erweiterung für Course2 geplant)

    - Autopilot_ChangeHeading (x = Heading um x Einheiten runter (<0) oder hoch (>0))

    - Autopilot_ChangeVerticalSpeed (x = VerticalSpeed um x Einheiten runter (<0) oder hoch (>0). x muss vielfaches von 100 sein)

    - Avionics_ChangeBarometer (-1, 1 = Barometer Setting auf PFD um 1 Einheit runter bzw hoch. Erweiterung für weitere Höhenmesser geplant)

    - Avionics_ChangeComFrequency (-2, -1, 1, 2 = COM1 Mhz 1 Einheit runter, Khz 1 Einheit runter, Khz 1 Einheit hoch, Mhz 1 Einheit hoch) - Erweiterung für COM2 geplant

    - Avionics_ChangeMapZoom (-1, 1 = Zoom MFD Map eine Einheit runter, eine Einheit hoch)

    - Avionics_ChangeNavFrequency (-2, -1, 1, 2 = NAV1 Mhz 1 Einheit runter, Khz 1 Einheit runter, Khz 1 Einheit hoch, Mhz 1 Einheit hoch) - Erweiterung NAV2 geplant


    - FlightControls_ElevatorTrim (-1, 1, x) - Erklärung unten

    - FlightControls_Flaps (-2, -1, 1, 2 = Flaps voll einfahren, eine Stufe einfahren, eine Stufe ausfahren, voll ausfahren)



    Die Erklärungen für die u.g. 3 "Inputs" und die damit zusammenhängenden "Change" Funktionen kommt morgen - ich hab jetzt schon so lange geschrieben, jetzt ist mal gut für heute :)


    - Inputs_RotaryChange

    - Inputs_RotaryPos

    - Inputs_Shift


    Hier mal noch die Scripts... Und nein, ich bin noch nicht fertig, das ist noch nicht final. Nur mal als Einstieg...

    UserScripts_MSFS.zip


    Gruß,

    Thomas

  • So, jetzt den Rest der Erklärung...


    Ausgangspunkt ist die Tatsache, dass ich nicht so viele Knöpfe und Drehregler habe, wie im Flugzeug. Wird wohl für die meisten von uns gelten. Der Bravo Throttle hat das z.B. derart abgebildet, dass am linken Drehregler ein Element ausgewählt wird, das mit dem rechten Drehregler dann hoch- oder runter gedreht wird.


    Genau das bilden Inputs_RotaryPos und Inputs_RotaryChange nach. Aber auch hier wollte ich es flexibel und erweiterbar halten. Und ich wollte gerne mehr also die 5 vom Bravo vorgegebenen Elemente (Alt, VS, Hdg, Crs, IAS) mit dem linken Drehregler steuern (z.B. die Com/Nav Frequenzen oder auch die Barometer Settings...).


    Deshalb habe ich mir im ersten Schritt überlegt, welche Elemente ich steuern will - und sie einer Zahl zugeordnet. Diese Liste kann prinzipiell beliebig erweitert werden...


    0 - unused

    1 - Altitude

    2 - Vertical Speed

    3 - Heading

    4 - Course

    5 - Indicated Air Speed

    6 - Nav Frequency

    7 - Com Frequency

    8 - Baro

    9 - Range

    10 - Flight Management System


    Die ersten 5 kann man ja direkt aus der Position des linken Drehreglers zuordnen. Wie mache ich das mit den Elementen 6-10?


    Dazu habe ich mir einen weiteren Button gegönnt. Das kann z.b. einer der 8 Switches des Bravo sein (habe ich aktuell nicht genutzt, denke ich aber gerade ernsthaft darüber nach).

    Beispiel: Switch 1 unten: Dann bewegt sich der linke Drehregler in den Positionen 1 bis 5. Switch 1 oben: Dann bewegt sich der linke Drehregler in den Positionen 6-10. (Als Idee: Schalter 2 dann 11-15, ...). Ich selbst habe aktuell den oberen weißen Knopf des Alpha Yokes dafür genutzt. Den habe ich "Shift" genannt und nutze ich für mehrere Funktionen...



    1 beim Drücken, 0 beim Loslassen.

    Das zugehörige RPN Script ist trivial und speichert den aktuellen Status (eben 0 oder 1) einfach nur in einer lokalen Variablen:


    (L:Generic-Inputs_Shift)·(>L:AAO_Inputs_Shift)


    Der linke Drehregler ruft nun das Script "Inputs_RotaryPos" auf (die Bilder für die Pos 2-4 hab ich mir gespart, die sind klar):


    ...


    Damit gestaltet sich der Code für den linken Drehregler wie folgt:


    (L:Generic-Inputs_RotaryPos)·5·(L:AAO_Inputs_Shift)·*·+


    Ich nehme also den Wert aus dem Parameter (0 - 4) und falls ich gleichzeitig auf meinen Shift-Knopf gedrückt habe, addiere ich 5 (um genau zu sein addiere ich immer 5*0 oder 5*1). Damit komme ich auf die Positionen 0-9.

    Warum habe ich das mit dem "Shift" so gelöst und nicht mit "Assigned Combo"? Die Antwort ist einfach: Faulheit. So muss ich die 5 Buttons vom linken Drehregler einmal zuordnen. In einer Combo hätte ich das 10 mal machen müssen. Und wenn ich mehr also 10 Positionen abbilden will, dann noch öfter. Vom Ergebnis wäre das aber das gleiche.


    Es gibt aber einen Haken bei der Sache. Sobald ich den Shift-Button loslasse wird die Drehregler-Position neu berechnet. Und ich bin statt auf 5 sofort wieder auf 0.

    Deshalb musste ein kleiner Trick herhalten: Die neue Drehregler-Position wird nur gespeichert, wenn die Stellung des Drehreglers sich ändert - nicht wenn sich der "Shift" Button ändert.

    Die neue Position und die alte Position müssen sich also unterscheiden - und zwar bezogen auf die Schalterstellung (0-4) und nicht die "Position" (0-9 oder sogar noch mehr).

    Das geht einfach über einen modulo 5 Vergleich:


    (L:AAO_Inputs_RotaryPos)·(L:AAO_Inputs_Shift)·*·+·5·%·(L:AAO_Inputs_RotaryPos)·5·%·!=·if{....}


    Die neue Position mod 5 und die alte Position mod 5 müssen unterschiedlich sein - nur dann gehen wir in den if und speichern die neue Position ab.


    Jetzt haben wir also die Werte 0-9 in der "AAO_Inputs_RotaryPos" Variablen gespeichert. Darauf werden wir dann im "Inputs_RotaryChange" zurückgreifen (im Stil von "If AAO_Inputs_RotaryPos = 0 then Heading ändern, if 1 then VS ändern, ...).

    Aber vielleicht möchte nicht jeder die Drehreglerpositionen in dieser Reihenfolge haben. Oder vielleicht manche gar nicht, dafür andere drin.


    Um das zu ermöglichen mache ich jetzt nochmal eine Zuordnung von Drehreglerposition zu den o.g. Elementen. Bei mir ist das (aktuell) 1:1


    PositionElement
    01 (Alt)
    12 (Vs)
    23 (Hdg)
    34 (Crs)
    45 (Ias)
    56 (Nav)
    67 (Com)
    78 (Baro)
    89 (Rng)
    910 (FMS)


    Es lässt sich aber auch komplett anders zuordnen:

    PositionElement
    01 (Alt)
    12 (Vs)
    23 (Hdg)
    34 (Crs)
    45 (Ias)
    58 (Baro)
    67 (Com)
    711 (xxx)
    86 (Nav)
    912 (xxx)


    Das habe ich mit einem case statement gelöst


    10·9·8·7·6·5·4·3·2·1·10·(L:AAO_Inputs_RotaryPos)·case


    Bedeutet: es gibt 10 (die zweite 10, nicht die erste!) Schalterstellungen und abhängig von (L:AAO_Inputs_RotaryPos) wird einer der 10 Werte davor ausgewählt (beginnend mit der 1). Bei 0 wird also die 1 ausgewählt, bei 1 die 2 usw.


    Für die Zuordnung gemäß der zweiten Tabelle, müsste dann das Statement einfach wie folgt geändert werden:


    12·6·11·7·8·5·4·3·2·1·10·(L:AAO_Inputs_RotaryPos)·case


    Und wenn jemand mehr als 10 Position hat (z.B. 13) dann


    14·9·15·12·6·11·7·8·5·4·3·2·1·13·(L:AAO_Inputs_RotaryPos)·case


    (hier würden also die "Elemente" 15 auf die Schalterstellung 11, 9 auf die 12 und 14 auf die 13 gelegt werden.

    Damit kann sich jeder selbst die gewünschten "Elemente" in der gewünschten Reihenfolge auf den Drehregler legen.


    Wir dürfen jetzt beim "RotaryChange" aber nicht mehr die Schalterposition abfragen, sondern das gewählte "Element". Und das speichere ich deshalb in der Variablen AAO_Inputs_RotarySelect. Es ist wichtig, dass ihr den Unterschied zwischen RotaryPos und RotarySelect verstanden habt, sonst werft ihr das durcheinander...


    Zusammengesetzt gibt das ganze dann den folgenden Code

    Code
    10·9·8·7·6·5·4·3·2·1·10·
      (L:Generic-Inputs_RotaryPos)·5·(L:AAO_Inputs_Shift)·*·+·
      d·5·%·(L:AAO_Inputs_RotaryPos)·5·%·!=·
      if{·d·(>L:AAO_Inputs_RotaryPos)·case·(>L:AAO_Inputs_RotarySelect)}
    c

    Die zweite Zeile berechnet die neue Position.

    Da wir die zum Setzen nochmal brauchen und ich sie nicht nochmal berechnen will, trage ich sie doppelt auf dem Stack ein (d) und mache dann den modulo-Vergleich mit der alten Position (Zeile 3)

    Zeile 4 speichert dann die neue Position und übersetzt mittels des case statements die Position in das gewünschte Element und speichert es in der Variablen AAO_Inputs_RotarySelect ab.

    Damit wären wir eigentlich fertig. Falls jedoch der if{ nicht ausgeführt wird, dann haben wir noch die Zahlen 10 9 8 7 6 5 4 3 2 1 10 sowie die berechnete neue Position im Stack liegen. Das ergibt keinen Fehler, ist aber nicht "sauber". Deshalb lösche ich am Ende mit c nochmal alles vom Stack (es würde reichen das in einem els{ zu löschen, aber warum komplizierter machen als nötig?).



    Fortsetzung im nächsten Post, Nachricht ist zu lang...

  • Und hier die Fortsetzung...



    So, jetzt fehlt noch der "Inputs_RotaryChange":

    Code
    (L:AAO_Inputs_RotarySelect) 1 == if{ (L:Generic-Inputs_RotaryChange) (L:AAO_Inputs_Shift) 900 * 100 + * (>L:Generic-Autopilot_ChangeAltitude)·1·(>K:Generic-Autopilot_ChangeAltitude) }
    (L:AAO_Inputs_RotarySelect) 2 == if{ (L:Generic-Inputs_RotaryChange) 100 * (>L:Generic-Autopilot_ChangeVerticalSpeed) 1 (>K:Generic-Autopilot_ChangeVerticalSpeed) }
    (L:AAO_Inputs_RotarySelect) 3 == if{ (L:Generic-Inputs_RotaryChange) (L:AAO_Inputs_Shift) 9 * ++ * (>L:Generic-Autopilot_ChangeHeading)·1·(>K:Generic-Autopilot_ChangeHeading) }
    (L:AAO_Inputs_RotarySelect) 4 == if{ (L:Generic-Inputs_RotaryChange) (L:AAO_Inputs_Shift) 9 * ++ * (>L:Generic-Autopilot_ChangeCourse)·1·(>K:Generic-Autopilot_ChangeCourse) }
    (L:AAO_Inputs_RotarySelect) 5 == if{ (L:Generic-Inputs_RotaryChange)·(>L:Generic-Autopilot_ChangeAirspeed) 1·(>K:Generic-Autopilot_ChangeAirspeed) }
    (L:AAO_Inputs_RotarySelect) 6 == if{ (L:Generic-Inputs_RotaryChange) (L:AAO_Inputs_Shift) ++ * (>L:Generic-Avionics_ChangeNavFrequency)·1·(>K:Generic-Avionics_ChangeNavFrequency) }
    (L:AAO_Inputs_RotarySelect) 7 == if{ (L:Generic-Inputs_RotaryChange) (L:AAO_Inputs_Shift) ++ * (>L:Generic-Avionics_ChangeComFrequency)·1·(>K:Generic-Avionics_ChangeComFrequency) }
    (L:AAO_Inputs_RotarySelect) 8 == if{ (L:Generic-Inputs_RotaryChange)·(>L:Generic-Avionics_ChangeBarometer) 1·(>K:Generic-Avionics_ChangeBarometer) }
    (L:AAO_Inputs_RotarySelect) 9 == if{ (L:Generic-Inputs_RotaryChange)·(>L:Generic-Avionics_ChangeMapZoom) 1·(>K:Generic-Avionics_ChangeMapZoom) }


    Das Grundprinzip sollte verständlich sein (wie ihr seht ist 10 aktuell noch gar nicht implementiert...).

    Der rechte Drehregler wird einfach an das Script gebunden mit den Werten -1 und +1



    Der if{ Teil im Code berechnet jetzt einfach den Parameter, der benötigt wird und ruft das zugehörige Script auf. Das einfachste Beispiel ist "ChangeBarometer"


    (L:AAO_Inputs_RotarySelect) 8 == if{ (L:Generic-Inputs_RotaryChange)·(>L:Generic-Avionics_ChangeBarometer) 1·(>K:Generic-Avionics_ChangeBarometer) }


    Wenn das Element 8 gewählt ist, dann nimm den Parameter vom rechten Drehregler (-1 oder +1), speichere ihn in der Parameter-Variablen vom ChangeBarometer Script und rufe das Script auf.


    Das "ChangeVerticalSpeed" z.B. will nicht +1 oder -1 sondern Vielfache von 100. Also +100 bzw. -100. Also wird der Wert einfach mit 100 multipliziert, bevor er übergeben wird:


    (L:AAO_Inputs_RotarySelect) 2 == if{ (L:Generic-Inputs_RotaryChange) 100 * (>L:Generic-Autopilot_ChangeVerticalSpeed) 1 (>K:Generic-Autopilot_ChangeVerticalSpeed) }


    Beim Altitude nutze ich jetzt zusätzlich noch meinen Shift-Button: wenn ich den Drehregler drehe, verändert sich die Altitude in 100er Schritten, drücke ich gleichzeitig meinen Shift-Button (und deshalb muss ich den an der linken Hand haben :) ) verändert sich die Altitude in 1000er Schritten (900 * Shift (also 0 oder 1) + 100 = 0+100 (also 100) oder 900+100 (also 1000).

    Genau gleich verfahre ich beim Heading bzw. Course - nur da in 10er Schritten und nicht 100er. Wem 10er nicht passen ändert das einfach auf 4 (für 5er Schritte) oder was auch immer einem selbst genehm ist :)

    Bei Nav/Com Frequenzen nutze ich den Shift-Button um zwischen Khz (ohne Shift) und Mhz (mit Shift) zu unterscheiden (Das Script will -2 bzw +2 für Mhz Änderungen, -1 bzw +1 für Khz Änderungen).


    Wer für jede benötigte Funktion einen eigenen Button hat oder wem die 5 linken Drehregler-Positionen ausreichen bzw. die zuvor dargestellte Idee nicht nutzen möchte, der kann alles in diesem Beitrag bisher geschriebene einfach ignorieren und die jeweiligen Scripte aus dem vorigen Beitrag direkt über entsprechende Zuweisung (in Kombination mit Combo Assignments) direkt aufrufen...


    Wer seinen hoch/runter Drehregler mittels anderer Schalter selektieren möchte, kann sich das Inputs_RotarySelect Script sparen und bastelt sich ein eigenes Script, das die Variable AAO_RotarySelect gemäß den eingangs gelisteten Werten setzt und kann dann trotzdem das "RotaryChange" Script nutzen.


    Oder man nimmt das ganze nur als Idee und bastelt sich komplett was eigenes.



    Würde mich echt interessieren, ob Euch das ganze weitergeholfen hat...





    Den "Shift" Button nutze ich auch beim Elevator Trim: ohne Shift in kleinen Schritten, mit Shift in größeren Schritten.


    (L:Generic-FlightControls_ElevatorTrim)·d·d·1·==·r·-1·==·or·if{·0.0015·0.0135·(L:AAO_Inputs_Shift)·*·+·*·(A:ELEVATOR·TRIM·PCT,·Percent·Over·100)·+·16384·*·(>K:ELEVATOR_TRIM_SET)}·els{·(>K:ELEVATOR_TRIM_SET)}


    Der Wert ist hier in von -16384 bis +16384 anzugeben, ausgelesen wird er aber in % - einen "Tick" (es gibt auch das Event "einen Tick hoch/runter") habe ich als 0.15% (also 0.0015) empirisch herausgefunden, mit Shift drehe ich immer um 10 Ticks (also 0.015 = 0.0015 + 0.0135 * Shift (0 oder 1).




    So, das war's jetzt erstmal von meiner Seite.

    Ich hoffe das hilft den Interessierten weiter. Für Hinweise oder Vorschläge bin ich dankbar, ansonsten werde ich halt weiter "vor mich hin wurschteln", so wie es die Zeit halt zulässt :)


    Für den, der das ganze mal bei sich ausprobieren möchte, hab ich mein Setup mal als Template für die Cessna 178 mit G1000 hier angehängt, also Scripte und Controller Assignments. Das ist nur zum Testen gedacht, ich will in diesem Thread keine fertigen Profile hochladen. Genutzt wird der Alpha Yoke und der Bravo Throttle. Wer das nicht hat, kann sich einfach die Scripte vom vorigen Post herunterladen und das Mapping auf seinen Controller entsprechend selbst vornehmen...


    Cessna 178 Beta.zip



    Gruß,

    Thomas

  • Hallo Oliver,


    du hast Recht.

    Ich fliege mit den Honeycomb‘s noch auf meinem iMac, bei dem die Grafikkarte nicht sehr performant und nicht austauschbar ist.


    Dzt. tischlere ich ein 2-sitziges Cockpit, dafür werde ich einen eigenen Windows Rechner zusammenstellen und dann plane ich alles über AAO zu führen. Der Hemmschuh sind aktuell die Preise der Grafikkarten; bin nicht bereit, Goldpreise dafür zu zahlen.


    Wenn mein neues System steht, wirst du es sicherlich merken, dann werden eine Menge Fragen bez. AAO aufkommen.

    LG Karl

  • Also bitte nicht falsch verstehen - ich rege nur an, die Entscheidung liegt bei dir. Da du AAO durch deine Stream Deck Tätigkeiten schon recht gut kennst, wäre das für dich naheliegend. Du weißt ja - das ist schon eine tolle Sache. Und ja klar - natürlich helfe ich gerne dabei. :)

    Herzliche Grüße :)

    Oliver

  • Oliver, du hast mich überzeugt, werde gleich auf AAO starten. Man kann ja - glaube ich - die Profile ex- und importieren, damit ich sie dann beim Umstieg mitnehmen kann. Du schätzt aber meine Kenntnisse zu AAO zu hoch ein ;) habe bisher nur Streamdeck durchgeleitet und einige Scripts versucht, aber noch keine Tasten oder Achsen konfiguriert, werde mich einarbeiten.


    Ich hänge dzt. ohnehin bei der Gemischregelung für die KingAir 350, in den Steuerungsoptionen bewegen sich die Balken (sowohl für die 0-100% Achse, als auch für die -100% - 100% Achse. Im Flieger tut sich aber nichts. Keine Ahnung.


    Werde das gleich einmal mit AAO versuchen.

    Sollten alle weitere Konversation im Thread zu AAO führen, muß ihn ohnehin mal durchackern, ist sicher viel Wissenswertes für mich dabei.

    LG Karl

  • Hallo Karl,


    also ich finde das gut.


    Vielleicht so als Tipp: Am Anfang eher kleinere Profile anlegen, die kannst du dann zu größeren Profilen "verheiraten" (in AAO "merge").


    So könnte ein Profil z.B. heißen "Pedale", oder "Höhenrudertrimmung". Am Ende könnte dann größeres Profil "KingAir 350" dastehen, das all diese kleineren Profile beheimatet.


    OK, zur King Air (Gemischregulierung): Meinst du in den Steueroptionen von AAO? Links werden Achsen, rechts Schalter angelegt. Die normale Gemsichregulierung ist als Preset dabei, da musst du nicht nach Variablen suchen. Moment - ich steige in den Flieger, mache einen Screenshot und editiere den Beitrag gleich nochmals. Bin eben gerade früher als erwartet Heim gekommen. :)


    Wenn das hier weiter geht, können wir das eher in einem AAO-Thread machen. Das betitelte Problem hier scheint gelöst zu sein(?)


    Bild 1:

    • Neue Achse anlegen

    Bild 2:

    • Achse wählen (in diesem Fall einfach - normale Steuerungen sind bereits vorgegeben - für komplexere Steuerungen (oder auch H- oder L-Vars) dann über das Event.
    • Achse bewegen (sollte automatisch erkannt werden)

    Bild 3:

    • Gegebenenfalls muss die Achse noch "umgekehrt" werden
    • Bei Bedarf auch die Empfindlichkeit eingestellt werden (anklicken und mit dem Mausrad einstellen)
    • Sowie die Extremzonen und die Totzone (Totzone mit dem Mausrad in der Nähe des Pfeils mit dem Mausrad vergrößern/verkleinern - mit Pfeil verschieben).

    Die mit dem Mausrad erscrollten Werte für die Empfindlichkeiten können unter Smoothness und Filter Strenght verfeinert werden (Bild 4)


    PS: Die Totzone in der Mitte ist für eine Achse von 0 bis 100 natürlich Blödsinn. Ich wollte es nur allgemein (für andere Achsen) und zur Vollständigkeit zeigen. Das trifft auch auf die Empfindlichkeit zu - diese Achse kann/sollte natürlich linear sein.

  • Hallo Oliver


    danke für die Anleitung, habe gestern schon einige Achsen und Schalter des Bravo konfiguriert und funktionieren auch.


    Der Hinweis auf ein Problem mit den Gemischreglern der KingAir stammt noch von meiner früheren Baustelle (Bravo über nativ MSFS Steuerungsoptionen) : beim Betätigen der Hebel des Bravo bewegen sich auch die Balken in den Steuerungsoptionen, im Cockpit tut sich aber nichts. Habe ich vorerst ad acta gelegt, werde es mit AAO mal wieder versuchen.


    Habe aber ein anderes Thema:

    Möchte beginnen, mit AAO kleine Brötchen zu backen, habe mir daher die Cesna 172 vorgenommen. Schalter - soweit notwendig - funktionieren, Schubregler auch.

    Mit der Gemischregelung bin ich nicht zufrieden. Die Macht in der Neutralstellung des Bravo Hebels bereits das CutOff. Das ist während eines Fluges natürlich unerwünscht, kann aber schnell passieren. Im Cockpit gibt es da eine Taste an der Gemischstange, ich vermute, das ist die Sperre, die bekommen ich aber mit AAO nicht hin.

    Als Lösung stelle ich mir vor, dass der echte Weg der Gemischstange aus dem Cockpit am Bravo von Max bis Min konfiguriert wird, da liegt dann die Nullstellung dazwischen und die hat eine Rasterung. Somit gäbe es ein CutOff erst wenn man explizit den Hebel aus der Nullstellung nach unten drückt.


    Kennt jemand dafür eine Lösung?

    LG Karl

  • Hallo Karl,


    dazu fällt mir spontan ein - entweder schalten (so wie in anderen Flugzeugen die Achse auf Umkehrschub oder Feather umschalte), oder die Achse segmentieren.


    Für derartige Segmentierungen gibt es ein sehr gutes Einführungsvideo von JD. Es lohnt sich, das mal ganz anzuschauen. Da baut er ein komplettes AAO Profil für die 747 und da gibt es auch mehrere Segmentierungen der Achsen. Außerdem erklärt er einige Grundfunktionen für Tasten- und Achsenfunktionen mit AAO.


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    Vielleicht wird es hinterher klarer.


    Übrigens: Auch der Warthog Throttle kann angehoben und dann ganz nach hinten gezogen werden. Dabei wird aber kein Signal ausgelöst. Diese Funktion kann ich nicht zuordnen (zumindest ist es mir nicht gelungen).

    Herzliche Grüße :)

    Oliver

  • @ Karl ja das mit den Condition Levers ist ja scheinbar mit dem Update gekommen, ist jetzt im Flusi keine Achse mehr sondern ein Schalter mit 3 Zuständen. Das ist auch der Grund warum ich mich gerade mit AAO beschäftige und es mir auch holen werde. So wie ich es verstehe müsste das ja mit der Segmentierung der Achse ich AAO funktionieren.

    Danke Oliver für den Link.


    Eine Frage zur Zuordnung hätte ich noch: ich hab gesehen dass man die Templates einem Flugzeug zuordnet. Werden die dann Automatisch mit dem Flugzeug erkannt?

    Also AAO erkennt mit welchem Flugzeug ich am Gate/Parkplatz stehe?

    Liebe Grüsse aus der Schweiz

    Marco

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!