Rätselfrage

    Wer weiß was?

    Kleines Ratespiel.

    Gestern hatte ich wohl durch einen BMS CONFIG Chrash das Phänomen,

    dass meine DX- Buttoms in der 3-D nicht funktioniert.

    Ergo, beim HOTAS funktioniert nur die Achsen, aber weder Bugradsteuerung, UHF- Sendetaste

    oder gar der Weapons Pickle Buttom funktionierten.

    Mein Auftrag bestand darin ein Ziel zu bombardieren.

    Befehl ist Befehl und so lieferte ich meine Zuladung entsprechend aus.

    Aber wie habe ich das ohne den Weaponspickle auf dem Sidestick gemacht?

    Bomben waren die GBU -31.

    Ich hatte das gleich Problem auch schon mal gehabt. Bei mir lag es daran, dass sich die Pinky-Shift-Funktion irgendwie für die Session permanent eingerastet hat.

    Somit waren alle Standardbelegungen auf dem Stick nicht mehr erreichbar. Nach einem Neustart der Sim war das Problem behoben.

    Ich glaube mich dumpf daran zu erinnern, dass damals der Offset für den "Un"shift-Callback im Keyfile nicht zur g_nHotasPinkyShiftMagnitude-Konfig gepasst hat.

    Das Problem ist, dass durch meine Arbeiten am Cockpit Windows die Controller anders sortiert hat. DX vom Cougar liegt jetzt bei 1000irgendwas und nicht bei 1.

    Im Setup ist alles ok, aber im Spiel funktionieren die Tasten nach kurzer Zeit nicht mehr.

    Bin mir über das Vorgehen noch nicht ganz schlüssig. Mit dem Alternate Launcher kann ich das Problem fixen, aber der erkennt den Virtuellen Controller des Trimmpanels nicht.

    Nützt es, wenn ich alle Controller abstecke und den Cougar auf einen neuen USB anmelde. Hat der dann wieder DX1?

    Meinen MFDs gehts genau so.

    Oder soll ich einfach im Device Sorting die Reihenfolge ändern, also Cougar nach ganz unten....

    Umstecken kann dazu führen, dass der Cougar in Windows an einer anderen Stelle in der Liste der USB-Devices angeordnet wird.

    Aber m.E. ist dieses Verhalten undefiniert. Ich würde also nicht versuchen, den Cougar über eine Umsteck-Orgie auf Platz 1 zu bekommen.

    Um den Cougar in Falcon wieder zuverlässig auf die DX1 zu bekommen mußt du den einfach in der DeviceSorting auf die erste Stelle setzten. Leider wird diese Datei vom neuen Launcher auch immer wieder mit zerhauen wenn man Falcon darüber startet. Des weiteren setzt der neue Launcher im Moment die "Buttons pro Device" von 32 auf 256, was im Moment nicht konfigurierbar ist und die Indexe aller nachfolgenden Devices in die Höhe schnellen läßt.


    Ich persönlich verwende den neuen Launcher im Moment nicht, weil mir da zu viel ungefragt in der FalconBMS.cfg festgelegt wird.


    Aber grundsätzlich sollte es auch kein Problem darstellen, wenn der Cougar andere DX Nummern jenseits der 1000 hat, solang diese auch entsprechend an den Callbacks konfiguriert sind.

    So Problem gelöst.


    Problem:

    Nach kürzester Zeit gingen in der 3-D Welt die DX Buttoms nicht mehr


    Ursache:

    Windows hat die Reihenfolge der Controller geändert. Dadurch ist der Cougar nicht mehr Device 1 (Windows 0) sonder Device 8 (Windows 7)

    Ursprünglich waren die geshifteten DC Befehle in die Keyfile für Device 0 geschrieben.

    Wenn jetzt ein geshifteter DX Buttom gedrückt wurde kam BMS durcheinander.


    Lösung:

    Mittels alternate Launcher geschaut als wievielter Controller der Cougar jetzt geführt wird

    geshiftete DX Buttoms neu in die Keyfile kopiert. Jetzt aber für Device 7

    Dafür habe ich Kolbes alte Excel Anwendung verwendet.

    Zitat von Joker

    Um den Cougar in Falcon wieder zuverlässig auf die DX1 zu bekommen mußt du den einfach in der DeviceSorting auf die erste Stelle setzten. Leider wird diese Datei vom neuen Launcher auch immer wieder mit zerhauen wenn man Falcon darüber startet.

    Ja, leider, leider ist das manuelle Editeren der devicesorting.txt mit dem AL deswegen nun sinnfrei.

    Ich hatte auch schon versucht, die Datei auf readonly zu setzen: No joy... (im Wahrsten sinn des Wortes :D)

    Der AL sortiert die trotzdem um. Ich würde den Weg trotzdem weiterrverfolgen, bin aber dafür nicht fit genug in Windows (Security).

    Idee: Diese Datei dem Super-User root(?) - oder wieauichimmer der hier heisst - schenken, so dass der normale User (des AL) die Datei garantiert nicht mehr schreddern kann.

    Wäre das ein Weg?

    Zitat von RightStuff

    Wäre das ein Weg?

    Ich würde ganz klar zu "nein" plädieren. Die Indexe, die in den Keyfile geschrieben werden, ergeben sich ja aus der Sortierung in der DeviceSorting.txt. Wenn diese nun nicht mehr mit aktualisiert werden kann und die Software nicht entsprechend darauf reagiert (und da verwette ich jetzt als Software Entwickler meinen ...) paßt am Ende gar nichts mehr.

    Sollte die interne Logik das tatsächlich unterstützen, wüßte ich wirklich nicht, warum die Software dann nicht gleich die Finger vom DeviceSortings.txt File läßt um weniger intrusiv zu sein.

    Sagen wir es mal so: Bis 4.36 hat das readonly setzen der devicesorting.txt ganz sicher funktioniert. Es gab hier no issues danach bei Zuweisung oder Nutzung.


    Ggf. funzt das auch noch bei 4.37 wenn man nicht über den AL startet.

    Da ich aber nur noch den AL nutze, hab ich die alte Startmethode nicht mehr weiter betrachtet, werd‘ ich aber nachher mal testen.


    Anyway: Werauchimmer als Progger da nun meint, die Datei nochmal neu sortieren zu müssen, obwohl der User sich bei der manuellen Sortierung ja sicher was gedacht hat, hat hier eher einen Rückschritt gemacht. Und ich bin mir auch sicher, dass in einem der Manuals explizit erwähnt ist, dass man die devicesorting.txt al gusto anpassen darf.


    Dass der Joystick nun zwangsweise zB ab DX-Button vierhundertdrölf liegen *muss*, ist irgendwie schräg, wenn man das seit 20 Jahren eigentlich anders kennt…

    Zitat von RightStuff

    Sagen wir es mal so: Bis 4.36 hat das readonly setzen der devicesorting.txt ganz sicher funktioniert.

    Ich sage ja auch nicht, dass das read-only setzen generell nicht funktioniert. Es macht nur keinen Sinn bzw. führt zu einer inkonsistenten Konfig, wenn eine nachfolgende Routine (das automatisch rausschreiben des Keyfiles durch den AL) von einem anderen Sorting ausgeht. Bis 36 war der AL ja nicht offiziell. Und Callback-Zuweisungen die mit einer gepinnten Sortierung in BMS oder manuell vorgenommen wurden, wurden dann eben mit den entsprechenden Indexen in die Keyfiles geschieben. Darum war das bis 36 kein Problem.


    Die Funktionalität des AL ist ja eigentlich sehr gut und übertrifft die Bordmittel von BMS bei weitem. Aber die Art wie er in die offizielle Auslieferung integriert wurde, die benötigten Anpassungen in der FalconBMS.cfg und wie die nötigen Änderungen kommuniziert wurde, finde ich suboptimal um es mal diplomatisch auszudrücken.

    Zitat von RightStuff

    Und ich bin mir auch sicher, dass in einem der Manuals explizit erwähnt ist, dass man die devicesorting.txt al gusto anpassen darf.

    ..und das ist einer der Punkte, die ich mit suboptimaler Integration und Kommunikation meine: Das "offizielle" Keyfilehandling ohne AL wurde in den Manuals detailliert dokumentiert. Und jetzt wurde die ehemalige ThirdParty-Software AlternativeLauncher mit 37 in die offizielle Auslieferung aufgenommen was natürlich annehmen läßt, das das alles schön zusammen paßt. In Wirklichkeit macht es aber einen gehörigen Teil der offiziellen Dokumentation obsolet bzw. irreführend...


    Meiner Meinung nach hätte man den AL schon mit ausliefern sollen aber nicht als Standard-Launcher sondern mit einem "opt-in" Verfahren, in welchem ausdrücklich auf die Implikationen bzw. Änderungen in der Konfig und den Keyfiles hingewiesen wird.