Beiträge von Joker

Zitat von nik

Vielleicht findest du mal die Zeit und gibst uns eine kurze Anweisung per TeamViewer, das wäre bestimmt hilfreich , um schneller ans Ziel zu kommen.

Hi Nik und Breaker,

wie siehts Samstag oder Sonntag abend so gegen 22:00 aus?

Habe einen neue Version in die Dropbox gelegt, der Original-Post wurde aktualisiert.

• 040 ist die Version mit den Neuen Features und Fixes
• 041 die Version in der außerdem die FSharp Komponenten entfernt wurde

041 kann von allen verwendet werden, da die FSharp Komponente stand heute nur für mich im Development-Moduls im Einsatz ist.

Weitere neue Features siehe dort...

Hi Bikeman,

kann dir so nicht adhoc sagen, was da nicht passt.

Als Workaround werde ich diese Komponente aus meinem Release entfernen, da die damit zur Verfügung gestellte Funktionalität noch nicht benötigt wird.

Lass mir bitte mal die genaue Fehlerausgabe zukommen, vielleicht werde ich daraus schlau.

Ausserdem wären deine Systems-Specs interessant (Windows Version, 64/32 Bit, Installierte .NET-Runtimes usw.)

Gruß
Joker

Die Dogfights sind in der Basis real gedrehte Szenen mit vereinzelt hinzugefügten CGI Effekten
Außedem wurden large-scale Modelflieger verwendet.

http://warbirdsnews.com/warbirds-news/dunkirk.html

https://www.usatoday.com/story…kirk-dogfights/513407001/
https://movies.stackexchange.c…e-any-cgi-used-in-dunkirk

Hallo Jungs,

das immerwährende Gefrickel bzw. Gerechne mit den DX-Buttons, Device-Offsets und des Shift-Layers in der manuellen Konfiguration der Keyfiles, da dies alles in der Falcon UI nicht berücksichtigt wird und der Fakt, dass bei jeder Speicherung in der Falcon UI die Gliederung des Keyfiles zum Teufel geht, haben mich dazu bewogen, in meinen langen Winterurlaub einen eigenen kleinen Editor zu schrieben, der sich dieser Probleme annimmt.

Jetzt könnt man natürlich auf den Keyfile-Editor von Kolbe verweisen, der einen Teil der angesprochenen Probleme auch löst, aber irgendwie bin ich mit dem Teil nie warm geworden da mir hier die Übersicht gefehlt hat - außerdem hasse ich Excel-Macros. Also habe ich bei meinem Editor ein Augenmerk daraufgelegt, dass er einfach zu verstehen und bedienen ist, ohne vorher eine 50seitige Anleitung lesen zu müssen (hoffentlich isses mir auch gelungen).

Version 0.5:

• Generieren von Tastaturlayouts im PDF Format (1)
• Filtern von Callbacks anhand Joystickutton Eingaben (2)
• Alle Filter (Gruppe, Callback, Device usw.) werden nun miteinander kombiniert.
  Bisher führte das einsetzen mehrere Filter gleichzeitig zu einer inkonsistenten Anzeige)
• Weitere kleine Bugfixes.

Version 0.4.1:

• Es können nun DirectX-Assignment auf Basis des gerade angewählten Keyboard-Shortcuts erfolgen. Das bildet im Prinzip exakt die Vorgehensweise der Falcon UI ab. So müssen neue Dx-Assignments nicht komplett neu erstellt werden bzw. der entsprechende Callback aus der Dropdown-Liste gesucht werden. Mit dieser Funktion wird er automatisch vom aktuellen Keyboard-Shortcuts kopiert (Neuer Button in Callback-Editor)

• Text-Editor ist jetzt beschreibbar. Änderungen können wahlweise direkt im Keyfile TextEditor-Fenster erfolgen und mit den Callback-Listen abgeglichen werden. (Neuer Button in Text-Editor)

• Weitere kleine Bugfixes und FSharp-Komponente entfernt (Bikeman-Fix)

Version 0.3.0:

• Schneller Überblick durch Gliederung/Gruppierung und Direktanwahl der einzelnen Gruppen
• Suche/Filterung nach Callbacks und Assignments
• Anzeige/Filterung von Doppelbelegungen
• Key-Shortcut und DX-Button Assignments wie in der Falcon UI direkt im Editor (wenn die Joysticks angeschlossen sind, ansonsten manuell)
• Berechnung des Button-Index bei DirectX Belegungen unter Berücksichtigung der Device-Position und des Shiftlayers
• Blockweise Umkonfiguration von Shiftlayer und Devices (bei gewollte und ungewollter *1 Änderung der Device-Reihenfolge)
• Unterstützt im Keyfile-Manual beschriebenen erweitertet Konzepte wie z.B. InvocationBehaviour, ButtonEvent, die speziell für Pitbauer interessant sind.
• Sämtliche im Keyfile abgelegten Wert können über beschreibenden Werte in Dropdowns editiert werden (gibt den Zahlen im File einen Sinn und verhindert Fehleingaben).

*1 wenn man mehrere identische Devices angeschlossen hat, kann die Datei devicesorting.txt diese nicht unterscheiden, das sie offensichtlich nach Maufacturer-GUID und nicht nach Seriennummer-GUID scannt.

Würde mich freuen, wenn der Editor einigen von euch eine Hilfe ist und wenn ihr mir Feedback geben würdet, ob man das Ding so verwenden kann bzw. wo es noch hakt oder was man noch verbessern kann, dann würde ich das Programm auch im BMS-Forum anbieten.

Macht eine Sicherheitskopie von eurer Konfiguration. Es wird zwar nichts geschrieben, wenn ihr nicht auf Save drückt und auch dann wurde bisher bei mir noch kein Keyfile zerstört. Aber der Teufel ist ein Eichhörnchen...

Dropbox: FalconKeyfileManager v0.5.0

Update 19.03.2020:

Version 0.7.0:

• Neue Callbacks für BMS 4.34 / U1
• Hotas Warthog Button Mapping - Work in Progress / Preview

Dropbox: FalconKeyfileManager v0.7.0

Viele Grüße
Joker

Auch von mir Frohes Neues an alle!

Hi Sven,

sorry, dass ich Dir erst jetzt antworte und danke Dir für den Hinweis aber das mit der Pin-Nummerierung ist kein Fehler, sondern so gewollt und von der PoKeys-API direkt übernommen. Siehe PoKeys User Manual Kapitel 14.17. SetOutput. Nummerierungen in Programmierschnittstellen sind in der Regel Zero-based und da ich diese Schnittstelle ja direkt anspreche, habe ich das für meine Konfig-Files auch so übernommen. Zugegebenermaßen ist das erstmal etwas verwirrend, da die Nummerierung auf der Platine und den Diagrammen mit 1 beginnt.

Ich sollte diesen Umstand vielleicht in der Oberfläche etwas hervorheben bzw. beschreiben, damit in Zukunft keine weiteren Verwirrungen auftreten.

Viele Grüße
Christian

Hallo Jungs,

hab hier einen kleinen Helfer gebastelt, der in Zukunft vermeiden soll, dass wir uns beim Host-IP-Adresse eingeben immer vertippen.
Das Programm erstellt anhand der im TeamSpeak angemeldeten Leute direkt in Falcon BMS eine neue Kontaktliste mit allen benötigten Daten. Dazu muss das Programm vor dem Start von BMS einfach nur kurz aufgerufen werden und Sync gedrückt werden.

ACHTUNG: Das Programm überschreibt im Moment das vorhandene Telefonbuch. Eine Merge-Funktion wird folgen.

https://www.dropbox.com/s/v4m2…61/BMSSmartComms.zip?dl=0

Gruß
Joker

Kann aushelfen
host: saturn.gtidev.net
pwd: 5zu1

Konnte die Ursache nun eingrenzen und habe das Problem lösen können!

Wie schon erwähnt, beruht mein Flackern nicht auf irgendwelchen Probleme mit MFDE von Lightning. Die von BMS exportierten Instrumente kann man ja nur einmal positionieren, eine Mehrfachausgabe auf mehreren GPUs gleichzeitig kam also nie in Frage.

Bei mir kamen die Probleme auf, sobald ich irgend ein zusätzliches Instrument der von BMS zum Export zur Verfügung gestellten (RWR,DED,MFD etc.) ausgeben wollte und mehr als eine GPU im System aktiv war. Dabei war es egal, auf welchem Screen die Instrumente dargestellt werden sollten bzw. an welcher GPU die einzelnen Screen angeschlossen waren (habe sämtliche Kombinationen durchgetestet). Sobald eine zweite GPU da war, trat das Flacker auf allen Screens auf. Selbst eine neuere Zweit-GPU, in meinem Fall eine GTX 750 Ti (anstatt der GT 640) konnte das Problem nicht lindern.

Die Lösung war dann letztendlich weder schwer noch nahe liegend: Einfach in Win7 das Farbschema auf Basic einstellen - fertig, das Flackern ist weg. (Basic - das ist der Modus ohne Windows-Aero, also ohne die Transparenzeffekte auf dem Desktop)

Würde bei bfm auch gerne mitmachen. Muss aber noch sehen wann und wie oft ich Zeit habe.

Danke für die Infos simpit. Habe das Interesse an diesem Thema nicht verloren aber aus Zeitgründen etwas zurückgestellt.
So wie es aussieht reden wir hier aber von unterschiedlichen Problemen. Mein flackern (nicht ruckeln) entsteht bei den über BMS exportierten MFDs.
Ich benutze zwar auch MFDE, aber mit diesem habe ich keine Probleme und er beeinflusst auch nicht das MFD-flacker-Problem.
Verwende nur einen Rechner, also kann ich auch ein Networking-Problem ausschließen.

Werde es, sobald es die Zeit zulässt, mit einer anderen zweit-GPU und dann ggf. mit einem neuen Netzeteil testen. Mein 530W Netzteil hat dann doch nicht mehr allzuviele Reserven wie ich erst angenommen hatte.

Trotzdem nochmal danke für die Hilfsbereitschaft.

Gruß
Joker

Nein, leider nicht. Das Bord ist auch schon etwas älter. Was pci angeht: ich erinnere mich, das mein Systeme nach dem Einbau der Karte 3 neue devices gefunden hat. Eines davon war ein pci 3 sonstnochwas controller. Muss wohl nochmal nachschauen, was der da genau gemacht hat... Gesendet von iPad mit Tapatalk

Danke für die schnelle Reaktion. Da ist eigentlich ein Netzteil drinnen mit genügend Reserven. Die zweite Gpu ist noch dazu eigentlich eine sehr sparsame passiv gekühlte Karte. Und es betrifft auch nur den MFD Output. Alles andere flackert nicht. Werde aber trotzdem nochmal die Last auf dem Netzteil prüfen und ggf tauschen... Gesendet von iPad mit Tapatalk

Habe bisher in meinem Rechner eine einzelne Nvidia GTX 670 gehabt, an welcher ich den Hauptbildschirm über HDMI und einen zusätzlichen kleineren Bildschirm über VGA angeschlossen habe, auf welchem ich die MFDs über die BMSeigenen Exportfunktion ausgegeben habe. Das hat bisher alles bestens funktioniert.

In Vorbereitung auf meine Cockpit-Erweiterung habe ich nun eine weitere GPU eingebaut, an der ich zwei einzelne 10" Displays für die MFDs anschließen wollte. Hierbei handelt es sich um eine ältere und schwächere NVidia GT 640.

Die Ausgabe funktioniert im Prinzip trotz der schwachen Karte auch mit ausreichend viel FPS. Das Problem, welches nun aber auftritt ist: die MFDs flackern jetzt wie sau - nicht nur auf den über die schwache Karte neu angeschlossenen Screens, sondern jetzt auch auf meinem bisherigen Zweitscreen, der nach wie vor an meiner großen GPU hängt und bis dato keine Probleme gemacht hat.

Hab auch schon im BMS Forum gesucht, da gab es einen ähnlichen Fall, der hatte aber wohl was mit eine SLI Konfiguration zu tun, die ich ja bei mir nicht habe. Hab zwar auch zwei NVidias drinnen, aber diese können und sollen ja auch explizit nicht im SLI Betrieb laufen.

Hat irgendwer von euch eine Idee?

Gruß
Joker

Zitat von Korbi

hast du einen Account auf Viper-Pits?

Hab bereits mehrfach einen angelegt. Das letzte mal vor 2 Wochen. Wird aber leider nicht vom Admin bestätigt....
Scheint etwas gegen mich zu haben....

Hab mir ne Demo von AutoCAD 16 runtergeladen. Das kann auch IGS Dateien öffen. Läuft 30 Tage. Bis dahin muss ich die Daten herausgemessen haben.

Hab erstmal AutoCAD genommen, weil ich da die Bedienung kenne, werde mir aber auch nochmal die freien Alternativen zu AutoCAD ansehen. Danke für die Tipps Stern und Sebi...

Gruß
Joker

Hi Korbi,

kannst du mir das in deimen Screenshot abgebildete Model des Cockpits als DWG zur Verfügung stellen?

Gruß
Joker

Vielen Dank Rampage. Das mit dem FCR ist wohl der richtige Tipp und wurde mir auch gerade im BMS Forum klar gemacht. Wenn man hiermit ein Ziel aufschaltet hat man wieder die Möglichkeit CCRP zu verwenden und alles ist gut.

Das mit dem Laser haben wir eigentlich genau so gemacht, wie du es beschrieben hast. Trotzdem haben die Bomben verfehlt. Aber vielleicht lag es auch daran, dass wir die Bomben tatsächlich "blind" abgeworfen haben...

Hier der Link zur Diskussion im BMS Forum:
http://www.bmsforum.org/forum/…ad.php?25063-Buddy-Lasing

Am Mittwoch wurde im BMS 4.33 Training Buddy Lasing geübt.

Nachdem wir in der Theorie alle Aspekte des Buddy Lasing und des Gebrauchs des Laser Spot Trackers durchgegangen sind ging es ab ins Cockpit. Während des Flugs kam in meinem Team bestehend aus Iceman und mir die Frage auf, auf welche Weise die Bomben den auszulösen sind nachdem der Buddy begonnen hat das Ziel zu lasern. Hier wurden in den beiden Flights mehrere Ansätze verfolgt:

Ansatz 1: Der bombenwerfende Jet hat einen TGP dabei und schaltet das Ziel zumindest auch mit auf. Hier wird davon ausgegangen, dass beim TGP der Laser ausgefallen ist, man aber im CCRP-Mode den Consent zum Auslösen der Bombe geben kann, da das Ziel ja trotz allem aufgeschaltet ist uns sämtliche Cues im HUD vorhanden sind. Hiervon wird wohl im Trainigshandbuch, Kapitle 11.3. Buddy Lasing, Absatz 3 ausgegangen: [...] This is a buddy lasing tactic where one aircraft is unable to lase [...]

Ansatz 2: Der bombenwerfende Jet hat gar keine TGP-Funktionalität, entweder weil dieser ausgefallen oder gar nicht vorhanden ist. Hier stellt sich die Frage, wie in diesem Fall die Bombe auszulösen ist, der herkömmliche Weg über CCRP fällt in diesem Fall weg, da kein Ziel aufgeschaltet werden kann und damit eben auch kein "Continuously Computet Release Point" berechnet werden kann, woraufhin man seinen Consent zum Bombenabwurf geben kann. Hiervon wird u.A. im Trainigshandbuch, Kapitle 11.3. Buddy Lasing, Absatz 1 ausgegangen: [...] Your wingman may have a malfunction and has lost his TGP capability. [...]

Verweise auf diesen Ansatz finden sich auch in dem Buch "Storm over Iraq". Dort wird beschrieben wie im Golf-Krieg F15Es und F111Fs für F16s das "Buddy Lasing" durchgeführt haben weil schlicht nicht genügend TGP-Pods zur Verfügung standen und die F-16s deshalb nicht damit ausgerüstet wurden.

Ansatz 1 wurde von Hammer-Flight verfolgt, inwiefern dieser damit Erfolg hatte, kann ich nicht sagen, da wir aus Zeitmangel kein Debriefing durchgeführt hatten.

Ansatz 2 wurde von Shark-Flight verfolgt, dieser bestand aus Iceman und mir. Unsere Buddylasing-Versuche blieben leider erfolglos, weil wir zu Anfang schlicht nicht wussten, wie hier die Bombe auszulösen ist, da das Ziel ja eben nicht aufgeschaltet werden konnte. Auf die richtige Vorgehensweise bei dieser Abwurfart wird auch im Handbuch nicht näher eingegangen. Einzig eine Erwähnung im Dash 34-1 auf Seite 107 impliziert, dass dies durch ein simples Auslösen der Bomben ohne weitere Einstellung/Aufschaltung erreicht wird: [...] Buddy lasing can be done by simply dropping LGBs in the vicinity (LGBs basket) of a laser spot being fired from another human pilot’s laser [...]

Viper hatte auch die Idee es mit dem MAN-Mode zu versuchen. Hierbei ließ sich die Bombe, wie oben angedeutet, zumindest einfach auslösen, verfehlte aber leider trotzdem das Ziel.

Wir befanden uns bei diesem Versuch in relativ engen Formationsflug und ich bemühte mich den Releasepoint wie im Traningsscript auf Seite 102 beschrieben korrekt anzusagen. Laser war auf COMBAT und wir hatten auch mehrfach die Frequenz kontrolliert. Den Laser habe ich sofort nach Abwurf eingeschaltet, daran kann es also eigentlich auch nicht gelegen haben. Ich konnte auch die Einschläge in der Nähe des von mir aufgeschalteten Ziels sehen.

Da es sich um bewegte Ziele gehandelt hat, hätte ich nur noch die Idee, dass man bei einem solchen Angriff zumindest nicht entgegengesetzt zur Fahrtrichtung des Ziels anfliegen darf, da hier die Abweichung auf dem doch 15- bis 20-sekündigen Fall der Bombe zu groß wird und von ihr nicht mehr korrigiert werden kann.

Ich hoffe, ich kann bei der nächsten TGP-Session wieder dabei sein, bis dahin werde ich auch mal das BMS-Forum konsultieren...

Gruß
Joker

Ich will jetzt nicht meine Hand für die Korrektheit dieser Anzeige ins Feuer legen, aber mir sind bisher keine Unregelmäßigkeiten aufgefallen - dass will aber nix heißen . Wir sollten also heute Abend das 433 Training u.A. dazu nutzen, ein etwas genaueres Augenmerkt darauf zu legen wann und warum das ggf. auftritt.

Wenn ich heute Abend nicht mehr als CS angezeigt werde sondern als P2P, dann liegt das daran, dass ich bei mir endlich die Portweiterleitung eingerichtet habe !