Beiträge von Joker

...ich bin dran. Hab auch gleich eine neue SharedMem DLL vom 17.11. eingebunden. siehe https://github.com/lightningvi…55d744bff0423b768d31709a0
Habe den Code der neuen Version von BmsCockpit auf .NET8 aktualisiert. Leider macht mein Development Rechner im Moment übelst Probleme.
Seit ich den auf Win 11 gehoben habe (mit einem on the fly update, was ich eigentlich nie machen wollte, nachdem mich Microsoft mit seinen Reminder-Popups über ein 3/4 Jahr genervt hat), habe ich jetzt täglich 2 bis 3 Blue-Screens-Of-Death.
Werde den in den nächsten Tagen komlett neu aufsetzten und werde dabei auch die Hardware leicht aufrüsten. Dann hoffe ich, bekomme ich den Rest des Updates etwas zügiger hin.

Bis dahin, Guten Rutsch!

Supi: Thread erfolgreich ge-hijackt - na was soll's...

Zur dynamischen Kampagne in DCS hat sich der CEO von ED erst vor ein paar Tagen geäußert. Hier bin ich echt gespannt, da er auch explizit erwähnt hat, dass sie hier auf keinen Fall BMS nachbauen wollen.

Auch bei BMS freue ich mich sehr auf die Neuerungen wie die neue Terrain Engine und vor allem Mixed Reality, dass ich in Buchenau bereits bestaunen konnte.

Ich denke, da kann BMS wieder gewaltig Boden gut machen. Ich hoffe nur, dass das Team, das ja um einiges gewachsen ist oder Teile davon sich nicht irgendwie verrennen und dass es dadurch zu erhöhtem Bugaufkommen oder gar zu schlimmeren kommt.

Ich beziehe mich hier auf einen Post aus dem BMS-Forum: https://forum.falcon-bms.com/topic/25861/how-bms-team-works.

Dort steht mehr oder weniger sinngemäß: Da das alle Entwickler für umme in ihrer Freizeit machen, darf/kann halt jeder machen was er will - und da frage ich mich wie das sinnvoll gemanaged werden kann.

Sind in Buchenau in der aktuellen Version über ein, zwei Dinge gestolpert, wo Dunc auch meinte: Nanu, das haben wir doch schonmal gefixt.

Ich wünsche BMS auf jeden Fall weiterhin viel Erfolg, genau wie ED. Konkurrenz soll ja bekanntlich gesund sein.

Zitat von nik

Weiß jemand ob ich auf die letzte spielbare Version 2.8XXX zurückpatchen kann, damit ich wenigstens offline ein wenig herumfliegen kann?

Das kann ich dir gerade auch nicht sagen, aber wenn alle Stricke reißen sollten besteht ja im Moment noch die Möglichkeit, von OpenBeta auf Stable zu wechseln. Das ist im Moment noch auf 2.8

das hört sich doch alles recht vielversprechend an:

https://forum.falcon-bms.com/t…icroprose?_=1692884603319

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.

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

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.

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.

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.

So, habe nun in mehreren Nachtschichten meinen Cockpit Extractor soweit durchgedrückt, dass zumindest meine momentanen Anforderungen umgesetzt sind:

Die Controller für die MFDs selbst sind noch nicht eingebaut, da verwende ich im Moment noch den original RTT Client, da ich hinter den Kulissen erst noch etwas umbauen muß um die R-PI Controller zu verstauen.

Im Moment sieht es hinter dem Pit nicht gerade so aus, wie ich mir "embedded" vorstelle:

Wenn das Zeug hier sinnvoll verstaut ist, bin ich meinem Ziel, dass irgendwann nur noch ein Netzwerkkabel (und vlt. ein USB Kabel) ins Pit reingeht, wieder ein Stück näher.

Weitere Details dazu gibts hier: BMS Cockpit Extractor / Yet Another YAME

Gruß

Joker

Nach ziemlich genau zwei Jahren stop and go bei der Entwicklung, hab ich meine Vorstellung eines MFD-Extractors endlich zu einer gewissen Produktreife gebracht. Da er nicht nur MFDs extrahiert, habe ich ihn sinnvollerweise "BMS Cockpit Extractor" genannt.

Die ursprüngliche Idee war, einen der vorhandenen Extraktoren das Laufen auf CreditCard sized Devices also RaspberryPi und Konsorten beizubringen. Mit Dot-Net Core auf Windows IOT den bekannten MFDE zum Laufen zu bringen hat sich aber als Sackgasse erwiesen.

Noch dazu fand ich die Idee sinnvoll, auf Bordmittel von BMS aufzubauen und nicht noch eine weitere Serverkomponente betreiben zu müssen, wie es zum Beispiel auch bei YAME der Fall ist.

Womit es dann auf eine komlette Neuentwicklung des/der Clients hinausgelaufen ist, die sich dann auch nicht zuletzt durch ein wenig technischer Unterstützung und auch Weiterentwicklung des RTT-Protokolls duch Dunc in die Tat haben umsetzen lassen.

Da YAME zwischenzeitlich nicht mehr weiterentwickelt wurde, habe ich den Code ab diesem Zeitpunkt immer auch Windows-kompatibel gehalten, sodass mein Extractor heute ganz normal auf Windows laufen kann, um die Instrumente auszugeben.

Inwiefern es nun Sinn macht, den Windows Client weiter zu entwickeln oder ob ich diesen Aufgrund der Tatsache, dass Dunc wohl die Weiterentwicklung des ursprunglichen YAMEs übernimmt, fallen lasse, ist bei Dunc gerade in Klärung. Ich warte gespannt auf Antwort.

Jedenfalls habe ich nun das von mir benötige Setup zumindest Software-technisch fertig und habe gleich ein paar Helper dazu entwickelt, damit solche R-Pi Clients für nicht Linux-affine Interessenten einfach aufzusetzen und zu betreiben sind.

Die Texturen für das CP stammen aus BMS selbst und sind mit einigen Schatteneffekten angereichert worden. Es fehlen noch ein paar Feinheiten wie Flags aber die Grundfunktion ist gegeben:

Während das RWR bereits in einer neueren Version mit Hintergrundtextur verbaut ist,

habe ich die eingentlichen MFDs noch gar nicht im Cockpit selbts konfiguriert sondern nur in der Teststellung ,da ich hier noch an der Monatge im Cockpit arbeiten muß.

Mit diesem Tool werden alle Raspberry-PI Devices automatisch im lokalen Netzwerk gefunden und können von hier aus gesteuert werden:

Installation

Die Software läuft zwar auch auf R-Pi 3, die neueste 4er Verssion ist aber dringend empfohlen, das hier der OpenGL Hardware Renderer des verbauten Chips verwendet werden kann.

Für die 3er Version fällt die Render-Engine auf die Software-Implementierung zurück, was sich in den Bildwiederholraten bemerkbar machen kann, jenachdem wie groß die Bildschirme und wie hoch dadurch die Auflösung der darzustellenden Elemente ist.

Was die erforderliche RAM-Größe angeht, so reicht bereits die kleinste Version des R-Pi 4 mit 1GB für die Darstellung der Instrumente aus.

Nachdem ein Raspberry-PI fertig mit RaspberryPI OS aufgesetzt wurde (siehe hier https://www.raspberrypi.com/software/)

muß nur ein weiteres Paket auf dem Device installiert werden, welches von den Exportern benötigt wird:

Die Exporter selbst und die Steuer-Software werden dann durch eine weitere Befehlseingabe auf das Device heruntergeladen und eingerichtet:

Danach werden diese automatisch von der Administrations-Software gefunden, welche sinnvollerweise auf dem BMS Windows Rechner gestartet wird. Sie kann aber auch auf jedem beliebeigen anderen Gerät im Netzwerk betrieben werden.

Hierbei ist es egal, welche Komponente zuerst gestartet wir. Man kann die Devices mit zuvor konfigurierten Autostarts auch generell ganz ohne Admin-Software laufen lassen und z.B. zum Umkonfigurieren den Administrator kurz laden und nach der Konfiguration der Devices wieder schließen.

Die Position der Instrumente wird im Moment durch simple Textfiles, ähnlich der des BMS RTT-Clients konfiguriert. Diese Konfiguration kann dann mit dem Admin-Tool auf das Device geladen werden.

Einen rudimentären Helper, mit dem man die Kontur des Instruments mit den Pfeiltasten über den Bildschirm bewegen kann um die genaue Position und Größe eines Instruments zu bestimmen, gibt es bereits.

Eine Windows-Distribution werde ich in den kommenden Tagen paketieren, falls Interesse besteht MFDE oder YAME abzulösen oder auch einfach so

Gruß

Joker

Hummer, vielen Dank für das Update!

Bumerang, Viper Ich werde versuchen, BMSCockpit die Tage zu aktualisieren.

Viper, danke auch nochmal für deinen Tip, das wäre warscheinlich auch eine Lösung gewesen, hat sich durch Hummers Einsatz ja jetzt aber erledit.

das Problem mit den neuen BIT ist, dass mein BMSCockpit eine Abhängigkeit zur SharedMem.dll von lightningviper hat, seines Zeichens Ersteller des MFDExtractors.

So wie es aussieht, hat er die Arbeit an diesem Tool und der DLL wohl eingestellt bzw. zumindest pausiert (letzte Änderung September 22, habs gerade eben nochmal gecheckt)

Im Moment kann ich die neuen ECM Daten nicht abbilden, solange die DLL das nicht hergibt.

Habe mich auch bereits mit Hummer diesbzgl. ausgetauscht, da er ein gleichgelagertes Problem mit BMSAIT hat.

Vielleicht bekomme ich einen Lösungsansatz hin, der die Daten auf dem selben Weg entgegennimmt, wie auch meine in C/C++ geschriebenen Anbindugen für mein DED und GaugePanel usw.

Die DLL muss ich dazu aber komplett neu schreiben, es wäre keine kleine Anpassung wo einfach nur 3, 4 Bits hinzugefügt werden. D.h., dass wird voraussichtlich etwas dauern.

Ich sehe mal, was ich machen kann. Ich bin den kompletten Februar über mit meinen Kindern in einer Kurklinik in den Bergen. Meinen Entwicklerlaptop, der zufällig auch eine BMS Installation hat, werde ich mitnehmen.

Vlt. kann ich dort vorhandene Zeit sinnvoll nutzen

Da ich traditionell etwas Probleme habe, bei extremen Winkeln die Funktionstüchtigkeit meines TrackIR sicherzustellen und es darum immer wieder zu Aussetzern kommt, leidet die Übersicht im Nahbereich oft gewaltig,

z.B. wenn ich beim Landeanflug aus der Formation falle und versuche meinen Flight wiederzufinden oder auch beim ausparken nach dem AAR.

Dadurch, dass ich in VR ganz sicher, ohne Aussetzer, mit eins-zu-eins Übersetzung, überall hinschauen kann, sind mir solche Manöver auf Anhieb in VR einfacher gefallen.

Ich könnte mir auch vorstellen, dass das aus diesem Grund auch ein Quantensprung im Dogflight darstellt, wenn man auf Padlock verzichtet. Aber da fehlen mir komplett die Erfahrungswerte

Was diesen Vorteil im Moment auch für mich mehr als aufwiegt, ist aber (noch) die Cockpit-Problematik, die auch Hummer und Bumi schon angesprochen haben.

Ich bin aber gespannt auf die hoffentlich nicht allzufernen Mixed-Reality Ansätze - auch wenn das bedeutet, dass ich mir dafür in 3 Jahren ein neues VR Set zulegen muß...

Aus gegebenem Anlass will ich nochmals eine Art von Tool Erinnerung rufen, welches eigentlich aus der Softwareentwicklung kommt, ich sei 4.32 auch für die BMS Config einsetze und das mir den Schrecken jeglicher Updates weitestgehend genommen hat:

Falcon BMS 4.32 - Update 2

In dem dort abgebildeten Screenshot wählt man einfach den Config-Ordner beider BMS Versionen an und sieht so auf einen Blick alle Änderungen in der Config und kann selektiv eigene Einstellungen dateiweise oder zeilenweise übernehmen.

Zitat von nik

Hat jemand eine Idee, wie man mit dem geringsten Aufwand den alten Zustand wieder herstellen kann? Meine Key File Sicherung war es schon mal nicht.

Was in meinem alten Post nicht steht, was wir damals aber aus gleichem Anlass im TS besprochen haben und in einem Update Szenario komfortabel als Backupmechanismus herhalten kann, ist eine Vorgehensweise, die ich nur nochmals jedem ans Herz legen kann:

Wandelt den kompletten User/Config-Ordner mit all seinen Dateien in ein GIT-Repository um. Das Verzeichnis ist dann nach wie von BMS verwendbar bzw. lesbar, es werden dann aber sämtliche Änderungen getrackt, sowohl die eigenen als auch die, die von BMS gemacht werden.

Jegliche Änderung kann später haarfein mit oben beschriebenem Tool nachvollzogen werden und man kann ggf. entweder auf Verzeichnisebene, auf Dateieben oder Zeilenebene auf einen älteren Stand zurückgreifen der zuvor mit nur einem Click erstellt wurde.

Das gilt auch für Binär-Dateien die man selbst nicht lesen kann, wie das Axismapping z.B. was mir gerne mal von BMS zerschossen wird, wenn ich vor dem Starten vergessen habe alle Devices einzuschalten.

Gerne stelle ich die Vorgehensweise und die benötigten Tools in einer TS Session nochmal vor.

Dann kann ich aber auch weiter den alten Starter benutzen…