Hardware bindings

[hbeni]

Bernhard told me he has issues figuring out how to wire his hardware autopilot controls to the new KAP-140 simulation.

I think the project should also supply a xml or nasal script that shows how to link the buttons to external devices.

[hbeni]

Ich hab mir als Beispiel die GUI angeschaut. Dort werden die Knöpfe ja (nochmals) definiert, es hängt aber noch Kontrolllogik drin.

So spontan fällt mir ein, dass es vielleicht eine gute Idee sein könnte, das nochmal neu zu designen:

• Knopfdruck speichert ausschließlich den aktuellen Timestamp in den button-press-property
• Knopfauslassen resettet das auf -1

Der Rest an logik müsste dann in die proprules migriert werden:

• Wenn -1: evtl anfallende Aufräumarbeiten starten und dann auf 0 setzen
• Wenn >0: Drück-Logiken und Checks umsetzen

Das hätte den Vorteil, dass man die Knöpfe direkt so von überall her (nasal, andere XML-Proprules, Telnet, ...) ansteuern könnte, ohne die Steuerungslogik kennen zu müssen.

[reiszner]

Ich weis es schaut blöd aus, aber das hat einen Grund. Beim drücken der Button hab ich einen eindeutigen Event und der löst nur einmal eine Aktion aus. Wenn ich das mit Prop-Filter mache, laufen die Filter ständig und verbrauchen Ressourcen. Zusätzlich kann ein Filter zwar mehrere Outputs haben, aber nur ein und den selben Wert in alle Outputs schreiben. Wenn mehrere Outputs bedient werden sollen mit unterschiedlichen Werten, brauchst du mehrere Filter und (anders als viele annehmen) hast du keinen Einfluss auf die Reihenfolge in der die Filter verarbeitet werden. Es könnte durch diese Race-Condition zu inkonsistenten Werten führen die ich beim Single-Shot Event vermeide.

BTW: schau dir die Dialog-xml an, da ist auch alles drin was ein Event auslöst. Da gibt es glaub ich nur wenige die mehrere Trigger haben.

PS: in Nasal kann man das leicht durch 'if' Statements machen, aber Nasal wollte ich eben meiden da es weit mehr Ressourcen frisst.

[reiszner]

Hab jetzt im issue #13 geantwortet, da dort in englisch geschrieben wird und Volador es aktive nutzen will und wir dadurch auch gleich einen schönen Testfall haben. Wichtig ist nur, dass die Hardware button-press und button-release im Property-Tree umsetzen kann. Dazu reichen schon reine boolean-props die dann ein script (mittels listener) überwacht und die nötigen Aktionen umsetzt. Wenn das einwandfrei funktioniert, kann man auch die interne Steuerung ändern damit die Animations-Datei (xml) nicht so überladen ist.

Ich grübel noch über die Drehknöpfe. Die sollten eventuell einen Zähler setzen der vom Script weitergereicht und wieder auf Null gestellt wird. Mal schauen ob das funktioniert.

[reiszner]

Hab jetzt im Issue #13 ein update bekannt gegeben. Wäre toll wenn du einen Dev-Branch in der C182s aufmachst mit den neuen KAP 140, dann kann Chris es testen. Aber eigentlich sollte es ohne Probleme funktionieren, da auch die Animationen in der XML die neuen Properties verwenden und da funktioniert alles. Ausserdem wurde die XML dadurch stark eingedampft.

PS: ich bin kein Nasal-Guru. Vielleicht kann man die Funktionen auch eleganter umsetzen.