Beiträge von Joker

wenn du willst, können wir morgen gerne mal im Discord zusammen draufschauen.

Nach zweieinhalb Jahren Abstinenz habe ich mal wieder etwas Zeit gefunden an meinem Cockpitprojekt weiterzuarbeiten. Das eigentliche Bauen hat sich zwar in Grenzen gehalten, aber ich habe meine Raspberry Cockpit Display Software etwas weiter entwickelt.
Gleichzeitig habe ich mich etwas um den Kabelsalat gekümmert, der mich schon seit zwei Jahren stört (siehe oben).

Die Raspberries sind jetzt alle mit einem POE-Shield versehen und in ein eigens für diesen Zweck designtes, selbst gedrucktes Rack gesteckt. Ein entsprechender Router ist nun direkt mit verbaut. So können die Raspberries über die UI des Router remote ein/ausgeschaltet werden, was vorher nur einzeln mit Schaltern am jeweiligen Netzteil ging. Das Cockpit wird nur noch mit einem Netzwerkkabel verbunden. Ein weiterer Schritt zu weniger Kabelsalat war der Austausch der Standard HDMI Kabel gegen selbst-konfektionierte Flachband Kabel mit genau angepasster Länge.


      

Werde nun auch versuchen die verbauten WEMOS-Chips (Engine Gauges und Fuelflow) auszutauschen und eine kabelgebundene Lösung zu finden, nachdem das ja auf der vorletzten Buchenau LAN über WIFI eher mittelprächtig bis gar nicht funktioniert hat.

Zusammen mit meiner oben verlinkten Software habe ich nun das komplette Set an MFDs und Instrumenten, die man überlicherweise im Simpit auf LCDs anzeigt, auf Raspberri-PIs "ausgelagert" und benötige nun nur noch einen Anschluss an der GPU meines Rechners für den Main Screen bzw. VR.

Im Rahmen des Updates auf 4.38 habe ich meine Raspberry Pi Display Software etwas weiter feingeschliffen, sodass das Setup nun noch einfacher gelingt.

Auf einem 4er oder 5er PI benötigt man nun nur noch Pi OS Light und nicht mehr die Version mit der kompletten Desktopumgebung welche 1GB unnötig auf dem PI verschwendet.

Wenn man sich anschließend per SSH auf seinem PI anmeldet, muss man genau 2 Befehle eingeben und die Kiste läuft.

Die Distributionsplattform für Installation und Updates registrieren:

Die Erforderlichen Pakete runterladen, welche danach und bei jedem PI Neustart automatisch starten:

Für Display Extraktion:

Für Instrumente ala YAME oder MFDE:

Auf dem Raspberry PI befindet sich nach der Installation unter /var/lib/bms-cockpit für jeden der beiden Extraktoren eine Konfig-Datei in welcher man definieren kann welche Displays bzw. Instrumente man wo sehen will.

bms-cockpit-gauges.conf

bms-cockpit-displays.conf:

Über den weiter oben abgebildeten CockpitHub können die einzelnen Raspberry PIs im Netzwerk gefunden, fernkonfiguriert und ein/ausgeschaltet werden. Eine genauere Beschreibung zum Hub plus Download-Link liefere ich noch nach.

Beide Programme benötigen den bei BMS mitgelieferten RTT Server. Dis Displays benötigen den normalen RTT Export. Die Instrumente bekommen ihre Daten über das leitgewichtigere UDP Multicast auf.

https://gtishare.s3.eu-central…s_Theater_16K_Terrain.exe
https://gtishare.s3.eu-central…eater_16K_Terrain.nsisbin

Zitat von marvel_master

Wie bringe ich Falcon 4.38 bei, dass er wieder "richtig" zählt?

Das Device Sorting ist übrigens das selbe wie bei Falcon 4.37.

das macht die Config set "g_nButtonsPerDevice" welche früher einmal standardmäßig 32 war und vom neuen Launcher jetzt der Einfachheit halber auf 128 gesetzt wird um wirklich jedes momentan erhältliche Device unterstützen zu können. D.H. es wird einfach angenommen, dass jedes Device 128 Knöpf haben kann, ob die nun verbaut sind oder nicht spielt keine Rolle.

Aber ich würde echt ganz einfach den neuen Launcher nehmen und alles einmal neu konfigurieren. Ich habe mich auch lange gesträubt, aber die Vorteile sind nicht von der Hand zu weisen. Dinge die früher ohne manuelles Nachbearbeiten des Keyfiles nicht möglich waren, wie zum Beispiel Trigger on Button-Release gehen mit dem neuen Launcher mühelos. Das ganze Zuweisen von Buttons und Achsen ist insgesamt viel kompfortabler. Man muß sich auch keine Gedanken mehr um das DeviceSorting machen, oder darum, dass einem die komplette Axis Konfig zerhauen wird, wenn man vor dem Starten von Falcon mal vergisst eines der erwarteten Eingabegeräte anzuschließen. Der neue Launcher schreibt bei jedem Start eine komplette, gültige Konfig Keyfile/AxisMapping/DeviceSorting raus, basierend auf den gerade angeschlossenen Geräten. Funzt einfach problemlos.

Tja, mein neuer Glasfaser ISP Giganetz scheint tatsächlich seit heute Mittag IP-Adressen zu sperren - unter anderem die, die zu dem in der Schweiz ansässigen Provider https://www.xelon.ch/ gehören, bei welchem die Loginserver von DCS gehostet werden.

Ich hoffe mal, dass es sich hier um ein technisches Problem handelt, das die nächsten Tage behoben wird und keine vorsätzliche IP Sperre darstellt. Werde morgen mit dem Provider telefonieren und hoffe, dass ich bei Teil zwei dabei sein kann.

Zitat von marvel_master

Wo kann man die 16K Texturen runterladen?

VG

Für Korea kann man das vor der Installation im Setup anklicken, dass sie während der Installation runter geladen werden sollen. Für Balkan gibt es ein zusätzlichen, optionalen Torrent Link: https://drive.google.com/open?…fjR88Xq3uQnb&usp=drive_fs

Zitat von Hummer

Weiß jemand, ob man nachträglich die Auflösung der Texturen ändern kann? Ich habe mal den Standard installiert, möchte aber mal testen, wie sich die HiRes aus die Systemperformance auswirken.

Der bereitgestellte Downloader hat ja eine komplette offline Installation runtergeladen. Ich hatte mit dem Gedanken gespielt (auch wegen des o.g. Fehlers), bevor ich viel Einrichte, einfach eine weitere saubere Installation mit der anderen Auflösung vorzunehmen um das direkt vergleichen zu können.

Zitat von Wildhog

Ich schließe mich ChatGpt und Gemini an.

Einzig den RAM würde gleich höher updaten.

Mind. 64. GB

Ich habe bei mir 64GB. Gundsätzlich würde ich auch immer wieder eher 64 als 32 GB nehmen, wenn auch eher für DCS als BMS, aber eine Erfahrung würde ich diesbezüglich als Bedenken anmerken:
Je mehr RAM, desto schwieriger/enger wird es auch mit dem Timing. Bzw die Auswahl der möglichen RAM Chip Kombinationen wird geringer. Wenn man da was falsches kauft bzw. einstellt, stürzt der PC auch gerne einmal mehr ab.

bei mir ist der Installer beim Download der Hires Tiles hängengeblieben. Starten konnte ich aber trotzdem.

Beim durchklicken durch die neue Oberfläche hatte ich nach 2min direkt einen CTD.

Die Simulation selbst scheint soweit zu laufen. Die neue Landschaft sieht schon schick aus...

...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.