Beiträge von Joker

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…

Hab noch was zu VR ergänzt. Dir auch einen Guten Rutsch!

* VR sieht super aus, auch wenn ich hier noch etwas optimieren muß. Ganz ruckelfrei ist es noch nicht.

* Der neue Soundtrack ist geil.

* Endlich Fullscreen / hochauflösende 2D UI. Ist zwar nicht sonderlich schön, erfüllt aber seinen Zweck.

* Der neue Launcher geht mir aber jetzt schon auf die Ketten:

Das Einstellen der Achsen ist zwar komfortabler aber dabei zerhaut er ohne Not den Rest der Konfig. Man kann aber genau so gut mit dem alten Launcher starten und BMS so konfigurieren wie bisher.

Der neue Lancher überschreibt jedes mal einige Settings, daruner auch ShiftMagnitude und ein neues Setting MaxDXButtons, das könnte man zwar in der BMS User Config wieder mit den eigenen Werten überschreiben,

was allerdings nicht behebbar ist, ist die Tatsache dass, auch die komplette DeviceSorting.txt umsortiert wird und somit der komplette Keyfile unbrauchbar wird, weil die Offsets der DX Buttons dadurch verschoben werden - und hierfür gibt es keinen User Override.

Man kann natürlich einmalig alles im neuen Launcher neu machen, dann hat man den "single-point-of-truth" bezüglich seiner Konfig aber von diesem Zeitpuntk an im Launcher und nicht mehr in den BMS-Keyfiles, die werden dann bei jedem Start neu geschrieben - nicht mein DIng.

Nochmal TL/DR: Wenn man den alten Launcher verwendet, der nach wie vor an der gleichen Stelle ist wie bisher, kann man auch die alten Keyfiles weiterverwenden.

Es sind ein paar neue Callbacks hinzugekommen:

Den VR-Recenter habe ich mir für jetzt erstmal schnell manuell in meinen alten Keyfile reinkopiert.

Mehr konnte ich mir in meiner Mittagspause noch nicht ansehen....

https://www.falcon-bms.com/downloads/

Ich bin gerade dabei mein neues Glareshield für den Druck vorzubereiten. Hier fehlen mir noch einige Maße der einzelnen Eyebrow-Komponenten.

Hab mir bis jetzt mit diversen Fotos von Pegasus und mit dem Modelviewer von DCS beholfen um eine einigermaßen Vorstellung zu bekommen.

Wie man sieht, sieht man da nicht sehr viel - oder eher etwas zu viel .

Wenn mir hier aber irgendwer "echte" Daten zur Verfügung stellen könnte, wäre ich sehr dankbar. Korbi, du sitzt doch sozusagen in der Quelle

Ich hab mir nun die bei Ebay für ca. 5 Euro zugelegt. Sind heute gekommen. kowalski Dein Caution Panel Board übrigens auch! Vielen Dank nochmal dafür!

Prozessor: In meinem Arbeitsrechner, ist ein Ryzen 5 3500 verbaut. Habe in den letzten 3 Jahren noch bei keinem einzigen Programm Probleme damit gehabt. AMD ist halt um einiges billiger. Gegenüber Intel hatten die Ryzen eine ganze Zeit mehr Kerne, dafür waren diese individuell etwas langsamer. Gerade bei Spielen und ganz speziell bei DCS, welches bisher weitestgehend singel-threaded war/ist, hatte man darum bisher gesagt: Kauf dir lieber einen Intel. Aber auch Intel erhöht nun eher die Anzahl der Kerne als die Taktfrequenz. siehe i9.

In meinem Sim Rechner ist darum im Moment auch noch ein Intel i7 verbaut, allerdings ein 7700K, erschienen Anfang 2017, also auch schon etwas in die Jahre gekommen.

siehe auch: https://cpu.userbenchmark.com/…D-Ryzen-5-3600/3647vs4040

RAM: Ich hab neulich gelesen, dass die Tendenz bei Power/Gaming PCs in Richtung 64GB geht. Habe selbst "nur" 32GB aber mein PC ist auch fast 4 Jahre alt.

Heute würde ich mir auf jeden Fall 64 kaufen. Verglichen zur GPU bekommt man RAM ja fast nachgeschmissen.

Bei den immer höheren Auflösungen mach viel RAM denke ich Sinn, da die eben auch immer höher aufgelösten Grafikdaten irgendwo hin müssen. Mit 32GB kommt man vielleicht nicht schon morgen an die Grenzen, aber in so 2 Jahren.

Den Effekt von genügend RAM kann ich bei mir z.B. ganz deutlich in den Ladezeiten von DCS sehen. Beim ersten Start dauert das laden bis zum Menü ca. 2 Minuten. Bei jedem nachfolgenden Laden 10 bis 20 Sekunden.

GPU: Die GTX 1080 ist von 2016, wenn du jetzt eine neue GPU kaufst, solltest du dir die 4000 Serie ansehen - sprich 4070, 4080, 4090. Zu AMD Radeon kann ich nix sagen, bin in Team "grün".

Schau auf jeden Fall, dass du mindestens 12GB Speicher hast. Hab das mal bei DCS gemessen, bei meiner RTX 3080 TI 12GB sind selbst die bei medium Grafikeinstellungen sofort vollgeladen.
Die neuen RTX 4080 gibt es auch mit 16GB. Wenn ich mir jetzt eine GPU kaufen würde, würde ich wahrscheinlich die nehmen.

HD/SSD: Anstatt einer gewöhnlichen SSD solltest du dir einen NVME .M2 Stick zulegen, der ist ein klein wenig teurer aber auch doppelt so schnell. (https://www.pcwelt.de/article/…-ist-der-unterschied.html)

Da NVME im Prinzip eine PCI Anbindung ist, gehen dir bei Verwendung eines solchen Sticks dabei zwar ein paar PCI Lanes verloren, die ansonsten von der GPU verwendet werden könnten, aber in der Praxis macht sich das nicht wirklich bemerkbar, weil die GPU Leistung die verfügbare Bandbreite in der Regel nicht ausschöpft. Es sei denn, du kaufst dir eine TITAN RTX 4090 TI SLI hastenichtgesehen für 5999 Euro.

Main-Board: Sollte ein oder zwei .M2 Slots haben, hat aber glaube ich heute fast jedes Board. Ansonsten habe ich akut keine Tipps, außer dass man auf RAM-Kompatibilität und RAM-Timing achten sollte, auch im Zusammenspiel mit dem gewählten Prozessor.

Da hat jeder Bord-Hersteller Listen auf der Homepage. Hatte schonmal daneben gegriffen und konnte in der Folge mein RAM nicht im optimalen Modus laufen lassen, da das System dann instabil wurde. Damit habe ich dann 10-15% Leistung eingebüßt.

Bei Windows bin ich im Moment vorsichtig. Hab zwar auch einen Win11 Notebook auf dem BMS grundsätzlich läuft, habe aber mal gelesen, dass Win11 durch einige der neu implementierten Sicherheitsmechanismen hardwarehungriger ist als Win10.

UPDATE:

VR: Ich hatte früher eine Oculus Rift und habe mir letztes Jahr eine HP Reverb G2 zugelegt, da diese eine wesentlich höhere Auflösung hat und gerade das bei Mil-Flug-Sims wichtig ist, um den einzelnen PIxel am Horizont, der dich sonst in den nächsten zwei Minuten vom Himmel holen wird, auch erkennen zu können. Das war mit der Rift nicht möglich. In allen anderen Games hatte mir die Rift bis dato ausgereicht, die lief auch mit wesentlich kleinerer Hardware gut, was man von der HP jetzt nicht unbedingt sagen kann. Das wäre auch ein Grund für eine aktuelle Grafikkarte.

Das neue Terrain! (ich weiß, das kommt erst in .38+)

4.37 EOY 2022 - kann sich ja nur noch um Stunden handeln...

Sehr schön. Wo hast du die Max 7219 gekauft? Bei Reichelt habe ich die für 14 Euro das Stück gesehen. Sind die wirklich so teuer? Ich würde vorsorglich schonmal Interesse an einer Platine bekunden ...

Zitat von Hummer

Sehr cool. Kannst Du mir bei Gelegenheit mal erklären, wie man als extern Client die BMS RTT anzapft? Das klingt nach einem tollen Ansatz,

Wir können uns die Tage gerne im TS treffen und mal das Netzwerkprotokoll durchgehen bzw. uns meinen Code ansehen.

Je nach Einsatzzweck gibt es da mehrere Module: Für einfache SharedMem Werte reicht es, Multicast Pakete entgegen zu nehmen. Das geht relativ einfach mit C/C++ auf "normalen" PCs und auf Micro-Controllern.

Wenn man RTT Daten verarbeiten möchte oder eine dedizierte Verbindung von seinem Client zu BMS anstrebt (anstatt Multicast), dann muß man sich zusätzlich mit dem Raknet-Protokoll auseinandersetzen.

HIerfür habe ich bereits eine an BMS angepasste Raknet-Lib. Das läuft dann aber auch nicht mehr auf Arduinos und dergleichen, sondern nur noch auf PC.

Ich hätte grundsätzlich die nächsten Tage spätestens ab 21:00 abends immer Zeit. Sag mal bescheid, wann du kannst...

So, hab mal wieder ein wenig an meinem Cockpit geschraubt bzw. in diesem Fall programmiert.

Das Projekt ist schon seit langem in der Mache und nimmt nun endlich Formen an, die einsetzbar sind.

Habe mein HSI nun auf meinen in Arbeit befindlichen Raspberry PI Export (YAMEmbedded) umgestellt.

Wie auch bereits bei den Engine Gauges, dem DED und ebenso dem RWR, bekommt die Client-Software die nötigen Daten

direkt vom BMS-RTT Server übers Netzwerk und benötigt keine weitere Server-Software auf dem BMS Rechner.

Die Client-Software läuft auf Windows, Linux und vorzugsweise auf Raspberry PI (jedenfalls entwickele ich sie primär für diesen Einsatz).

In meinem Fall kommt ein R-PI Compute Module 4 zum Einsatz, was nochmals nur halb so groß ist wie die herkömmlichen R-PIs

und auf einer Trägerplatine läuft, welche den benötigten HDMI Anschluß für das 4" Display enthält.