Beiträge von cuca

Same here👍

Ja, ich beobachte das auch.

Mal mit dem Debug Mode des Browsers betrachtet, dauert der erste GET Request beim Laden der Startseite teilweise bis zu 7 sekunden, und danach klappern alle Inhalte relativ schnell nach.

Das Laden von Forums-Unterseiten (wie zB. dieser Thread hier) geht bei mir schneller, etwa eine viertelsekunde. Die Images (z.B. die ganzen Smileys) brauchen dann hinterher nocheine halbe bis dreiviertelsekunde hinterher. Das finde ich soweit in Ordnung und fühlt sich ok an.

Wenn natürlich einmal alles gecachet ist, dann geht der Seitenaufbau rasend schnell, davon darf man sich in der Beurteilung der Ladezeiten natürlich nicht veräppeln lassen.

Ja, aus Sicht meines SEAD-Flugs war das natürlich übelstes Versagen von meiner Seite.

Wir sind total dämlich in den Threat Circle reingeflogen, und haben uns da wegpflüclen lassen wie in Vollnarkose.

Einen Gameplan hatte ich, aber war vom Mindset total hinter dem Jet und der Aufgabe.

Völlig unabhängig davon - ich schwör - biete ich am Sonntag ein SEAD-Training an. Das hatte in der Tat bereits VOR dem fatalen Mini-Comao Flug erstellt.

Aber jetzt passt es aus meiner Perspektive PERFEKT als Nachsitzen für den letzten Flug.

Ich bin ein WinWing Benutzer, ich wecke beim Einstieg ins 3D den Throttle immer auf, und legen dann den Throttle "hinten" in Cutoff Position ab.

Hintergrund: ich hatte OHNE das Aufwecken früher (vor mehr als zwei/drei Jahren, noch mit einem Warthog Throttle) gelegentliche Hot-Starts, die deutlich öfter auftraten als der 2% Randomizer erwarten lässt.

Ich beobachte beim Aufwecken übrigens immer zunächt eine ruckende initiale Bewegung des virtuellen Throttles im 3D-Cockpit. Da ich von diesem Rucken befürchte, den Hot-Start zu begünstigen, und da es im BMS-Forum so empfohlen wurde, habe ich mir das so angewöhnt.

Anti-Icing stelle ich im Ramp-Start auf "Auto".

Zitat von Husar

Also, ich meine, dass auf der letzten oder vorletzten Buchenau ein Dev dazu gesagt hatte, dass diese Funktion rausgenommen wurde. Und nein, schriftlichen Beleg habe ich dazu leider nicht.

Sowas meinte ich, auch mal gehört zu haben, kann es aber nicht belegen.

Andererseits steht im BMS Training Manual nach wie vor in Kapitel "1.6.3 Hot Start" (Seite 29) beschrieben, es gäbe diese "kleine" random possibility.

Eine Frage - gibt es hier jemanden, der häufige Hotstart-Probleme hat, OBWOHL er VOR dem Engine Start einmal den Throttle über die gesamte Motion-Range bewegt und dadurch "aufzuweckt" und das alte "Throttle Mismatch" Problem auszuschließ?

Oder andersherum gefragt: Gibt es Leute, die den Throttle NICHT aufwecken? Wie sehen da die Erfahrungswerte mit Hot Start

(https://forum.falcon-bms.com/t…-start/19?_=1776976956263)

Ich mache, wenn ich offline für mich fliege - meist keinen Rampstart, aber durchaus mal welche, wenn ich TEs durchteste (und das sind bei einer TE z.B. für Buchenau durchaus eine größere Anzahl an Rampstarts und Flügen).

Dabei ist mir, in den vergangenen zwei Jahren, vielleicht EIN Mal mein Triebwerk abgeraucht. Bei diesem konkreten Fall kann ich mich aber erinnern, daß ich eine ganze zeitlang Heads-Down mit Flight-Lead-Admin-Aufgaben beschäftigt war, und die Instrumente nicht im Auge hatte. Ich habe mich danach gebührend über mich selbst geärgert, hier nicht richtig bei der Sache gewesen zu sein.

Ich habe daher mit "NEIN" abgestimmt.

Das bringt mich zu einem Gedanken - wir sind alle nicht perfekt, wir machen alle Fehler. Sinnvoll wäre es, um der Sache auf den Grund zu kommen, eine saubere Datenbasis zu schaffen. D.h. etwaige gemachte Pilotenfehler auch anhand einer Dokumentation transparent zu machen. (Ich nehme ja meine Flüge fast immer per ACMI und Video auf, ebenso schreibt mein BMS die Logfiles, bei jedem Flug mit. Das würde ich nebenbei gesagt, grundsätzlich allen Piloten ans Herz legen wollen, der Lerneffekt ist ungemein wertvoll.)

Es ist eine ganz andere Sache, in einer Umfrage anzuklicken:

"Mir ist das Triebwerk schonmal abgebrannt, ich finde, BMS ist schuld"

zu

"Mir ist das Triebwerk schonmal abgebrannt, die Analyse ergab, daß ein Pilotenfehler ausgeschlossen werden konnte, ergo ist BMS schuld"

Nebenbei gefragt. Mir ist im Hinterkopf noch bekannt, daß es einen (2prozentigen? 1,5 prozintigen?) per Zufallsgenerator gesteuerten Trigger gab, der einen Hot Start auch bei vollständig korrekter Bedienung auslösen konnte. Über den wurde im BMS-Forum seinerzeit viel diskutiert. Weiss jemand von euch sicher, ob dieser noch existiert, oder wieder aus dem Spiel genommen wurde? (Am besten mit Beleg BMS-Forumspost, Manual, Aussage eines Devs?)

Sagt eigentlich das Debug-Log irgendwas Interessantes zu dem Zeitpunkt, wo der Fehler auftritt?

Der, ich glaube, FWD Fuselage Tank ist bei den Zweisitzern kleiner als bei den Einsitzern - weil da ja der Platz fürs hintere Cockpit benötigt wird.

Dementsprechend ist bei den Zweisitzern die "FR"-Nadel im Normalbetrieb links von der "AL"-Nadel, genau andersherum als bei den Einsitzern.

In Folge dessen sind auch die "Überlapppungsfähnchen" an der "FR"-Nadelbasis andersherum gestaltet, weil Grenzwerte für Fuel Imbalance anders - und auch andersherum - sind.

Hi Bumi, meinst du vielleicht die Diagramme aus dem Dash-1?

..\Docs\02 Aircraft Manuals & Checklists\01 F-16\TO 1F-16CMAM-1 BMS.pdf

Diese hatte ich beim Schreiben der Mail auch im Hinterkopf, und habe gerade kurz nachgesehen. Auf Seite 48 ff wird das Fuelsystem der F-16 erklärt, da findet sich unter anderem dieses Bild hier:

Ich glaube, die DIfferenz liegt darin, daß die die beiden Reservoirs in der Betrachtung teils fehlen bzw mit dem FWD /AFT Tank verwechselt werden.. Die beiden Reservoirs sind etwas separates. Sie sind die letzten Durchlaufstationen des Sprits aus den beiden FWD/RIGHT- und FT/LEFT-Systemen . Die Reservoirs fassen zusammen auch noch mal knappe 900-1000lbs

Anders gesagt, die Summe des internal Fuel setzt sich zusammen aus

FWD

AFT

FWD RES

AFT RES

LWING

RWING

Sehr gutes Debrief👍

Ich hatte mich, noch in der Luft, schon ziemlich gegrämt, plötzlich alle drei Wingmen zu verlieren. RatCats Hinzukommen war daher eine große Freude und Erleichterung.

Also danke nochmal Bumi fürs schicken, und RatCat fürs rüberkommen!

Gut, Vipers Verlust ist auf ein Real-Life Problem (Bugs, Netz- oder Hardwareprobleme) zurückzuführen, da kann man als Lead kaum was dran ändern.

Aber daß ein Element einfach so stirbt, war schon ein Schreck.

Ihr kennt mich ja, ich bin dann der Typ, der sich fragt, wie das zukünftig zu verhindern sei - und weniger derjenige, der es als "ist bei der 47DF halt so" akzeptiert.

Daher, los gehts:

Leider habe ich für den Flug kein ACMI, aber im Debrief hat sich ja, durch Marvels Bericht, die Ursache herausgestellt. Und wurde die Minimum Abort Range missachtet.

Hinsichtlch der Frage - was hat dazu geführt oder dies begünstigt, daß die MAR hier unterschritten wurde.

Hätte man vielleicht im Briefing doch nochmal etwas mehr über die MAR sprechen müssen - oder war dieses Thema mit Wildhogs Briefing-Folien doch ausreichend behandelt?

Im Nachhinein betrachtet, habe ich während des Fluges wahrgenommen, daß Marvel auf 34kft angreift, er sagte dies zu Nik, nachdem dieser erneut ins 3D eingestiegen war.

Das sind 4kft über der von mir gebrieften Contract Altitude. Idealerweise hätte ich vielleicht noch was sagen sollen.

Z.B. daß sich damit die MAR mit zunehmender Flughöhe tendentiell noch vergrößert, oder das Element wieder auf 30kft herunterholen sollen, aber das kam mir nicht in den Sinn.

Ja, schade, daß ich das Training verpasst habe, ich hatte leider einen anderen Termin.

Ich hatte im Rahmen dieser Diskussion mal geprüft, was man in den Debug Logs zu den abgesetzten Tanker Funksprüchen - also die aus dem Comms Menu - sieht.

Leider ist es nicht so detailliert wie ich mir gewünscht hätte. Man sieht zwar, DASS jemand einen Comms Menu Funkspruch abgesetzt hat. Aber nicht, welchen.

Auf dem aktuellen Stand müsste man daher also die Debug-Logs aller teilnehmenden Player zusammenführen und auswerten, um dann doch nur teilweise Aufschluss darüber zu erhalten, welcher Pilot wann welchen Comms-Befehl abgesetzt hat.

Ich probier die Tage mal, was das Debug Log auf einem BMS-Server so ausspuckt, wenn man man in einem Online-Flug als Client ein Refuel anfordert.

Vielleicht lässt sich ja da herauslesen, was an Kommandos von den Spielern abgesetz wurde, und am Tanker ankam.

EDIT: Habs probiert, leider nichts in den Debug Logs zu sehen, was hinreichend für eine Vollständige Analyse wäre ausreichend wäre.

Ich habe Sonntagnachmittag vor unserem Rolling-Thunder Flug noch ein Video aufgenommen, welches sich mit der Planung von TEs beschäftigt, die definierte Takeoff, Push, IP, und TGT Zeitpunkte haben sollen, und zwar um mein OCD zu befriedigen, solche Zeiten, die auch in hh::mm:00 enden, also vollen Minuten.

Ich habe mir, wie vor ein paar Jahren schon einmal, eine Handvoll sog. "Static Objects" für TacView gebaut, um die Runways und ILS-Glideslopes sichtbar zu machen.

Wie man im Screenshot sieht, sind die Runways blau und die Glideslopes rötlich. Man kann damit sehr gut die Einhaltung des Glidepaths überprüfen, wenn man an seinen Landungen arbeiten will.

Nachdem ich in der ersten Briggs-Mission eine Airstrip-Landung versemmelt hatte, habe ich zuletzt etwas Zeit in das Thema investiert. (Das war mein Aufhänger)

Bisher enthalten sind die Bases: Aviano, Amendola, Casale, Falconara

Installation:

Die Datei Balkans 438 Cuca v02.txt muss man umbenennen in .xml (ich musste sie wegen Upload-Restriktionen des Portals in .txt umbenennen) und dann in den "Static Objects"-Folder von TacView kopieren.

Das wäre bei den meisten der Pfad

%appdata%\Tacview\Data\Static Objects

Mein Eindruck, wie es gestern gelaufen ist, in Runde 3

Es ist leider wieder das gleiche passiert wie die ersten beiden Male, nur diesmal aus einem anderen Grund - wir waren diesmal insgesamt zuwenige Piloten.

Pitbull hatte dankenswerterweise die MIssion neugebaut, damit sie sich nicht identisch anfühlt, vermute ich (?). Jedenfalls war sie auf drei vollbesetzte Foutships ausgelegt, wir dann zuguterletzt nur zu siebt am Start.

Das führte dazu, daß wir die geplante zahlenmäßige Überlegenheit von vier dedizierten SEAD plus vier ESCORTS so nicht herstellen konnten.

Dementsprechend waren Husar und ich als zweiköpfiger DEAD-Flight nach unserem ersten MAGNUM-Call schon zwischen zwei feindlichen FIghter-Groups sandwiched. An einer Richtung hat Pitbulls ESCORT mitgeholfen, an der anderen mussten wir alleine arbeiten, dies aufgrund der Positionierung zwischen dem SEAD und ESCORT.

Genau hier gehts schon los - Fehler wurden auch in dieser Mission genug gemacht:

Betrachte ich mir diese Phase des Fights nachträglich, hätte ich meinen Flight, also Husar und mich, anders positionieren müssen - nicht so offensiv im Sandwich zwischen zwei SA-5 und Fighter-Groups.

Sondern neben und parallel zum ESCORT. Es ging zwar bis hierhin in unserem Flight noch alles gut, und es waren am Ende beide anvisierten SA-5 down , aber das Risiko, das ich mit dieser Positionierung eingegangen, war total unnötig, und hätte die Mission hier schon zum scheitern bringen können. Soweit hatten wir also erst einmal Glück in SEAD Flight

Am Ende ist es daran gescheitert, daß die Bedrohung durch Fighter zu stark war, und wir den Punkt zum Abbruch der Mission verpasst haben. Als wir die Mission zuguterletzt aborten wollten, konnten wir uns nicht mehr vom Gegner lösen - wodurch wir dann wie die Fliegen fielen.

Angesichts der Tatsache, daß wir gestern statt als dreckiges Dutzend nur als glorreiche Sieben unterwegs waren, habe ich gestern trotzdem Spass gehabt, trotz aller Fehler.

Zitat von Husar

Das Problem ist auch gewesen, dass wenn der Tracking Radar strahlte, nur einer von uns diese im RWR sah. Der andere nicht! Das ist doch nicht realistisch.

Ich habe eine Gegentheorie - stell dir mal vor, was das für ein konzentrierter "Pencil Beam" ist, mit dem ein Tracking-Radar sein Flugziel anvisiert. Dieser Beam muss, zum aufrechterhalten des "Lock" ständig präzise nachgeführt und auf dem Flugziel gehalten werden. Der Radarwarner des anvisierten Flugzeugs reagiert nun genau darauf, mit einer hohen Konzentration gebündelter Energie angestrahlt zu werden, und zeigt das akustisch und optisch an.

Und der RWR eines anderen, sich woanders befindlichen Flugzeugs, welches sich nunmal NICHT in dem Tracking-Beam befindet, zeigt entsprechend eben...

...NICHTS an.

Dazwischen gibt es eine Grauzone, man könnte sich ja am Rand des Beams befinden, in einer Nebenkeule etc.....

Zum Thema Taktik - ich finde es auch geil, mit oldschool Waffen, NOE und Hardkill-Mentalität SAMs auszuschalten. Wenn man sich aber nochmal vor Augen führt, wo das Problem bei dieser Mission haupsächlich liegt:

Es besteht darin, die eigenen Tief-Flieger zu schützen, die sich in den SA-5 Threatcircles bewegen. Weil sich der ESCORT weiter oben, auf Air-to-Air-Altitudes, nicht frei genug bewegen kann, um einen angemessenen Schutz vor feindlichen Fighter Threats aufzubauen.

Ich kann gerade keine taktisch saubere Argumentationskette herleiten, die die These " es hat sich als zu schwierig herausgestellt, unsere Tiefflieger innerhalb der SA-5 Threatcircles zu schützen, also schicken wir da halt noch mehr Tieffieger rein" stützt - helft mir, wenn ich was übersehe?

Zu Marvels Aussage mit den Tankern - mir ist auch schon aufgefallen, daß es immer mal wieder schief läuft, und dann der Tanker vorgeblich "buggt".

Ich glaube aber ehrlicherweise, nach dem was man so vom BMS Team über das Tanker-Queue-Management vernommen hat, daß da eine erhebliche Menge an Bedienfehlern der Piloten vorhanden ist, und nicht überall, wo ein Bug vermutet wird, auch wirklich ein Bug drinsteckt.

Fehler können häufig beobachtet werden. Welche Tanker-Funk Kommando-Tasten man als Wingman zu drücken hat, und welche nicht. Daß so ein Flight auch wirklich erst dann am Tanker angemeldet wird, wenn alle Piloten da sind (und nicht dutzende Meilen hinterm Lead her-eumeln), oder der Lead gar selbst noch dutzende Meilen vom Tanker entfernt ist.

Ich würde ja vorschlagen, dann fraggt man als TE-Bauer halt noch ein paar weitere Tanker dazu - andererseits soll ja vorgekommen sein, daß Piloten dann die Tanker verwechseln und sich an Tanker A hinterherfliegend, an Tanker B anmelden, ihren Fehler bemerken, sich dann aber nicht bei A abmelden, sondern gleich bei B anmelden, und dann erst recht die Tanker strubbelig machen. ein Teufelskreis... wo war nochmal dieser Boomerang, der hat das doch so vortrefflich erklärt?

Gestern haben wir ja den zweiten Versuch der Rettung von Gen. Briggs gestartet, und das Ergebnis war schon deutlich besser als der simulierte erste Versuch.

Diese Entwicklung kann man sicher als Erfolg verbuchen... aber:

Dennoch, im Sinne des Auftrages ist die Mission eindeutig nicht erfüllt worden, und die beiden festsitzenden Personen sitzen immer noch fest. Da sie folglicherweise jetzt schon seit über einer Woche keine frische Unterhose mehr gewechselt haben, wird demnächst der Hygienebeauftragte der NRF einschreiten. Das wollt ihr nicht, Jungs.

Daher schlage ich vor, es NOCH EINMAL zu probieren.

Die Neuerungen unseres Game-Plans (zu größten Teilen von Pitbull) aus der letzten Mission würde ich wieder übernehmen:

• Eingeteilter MC
• Zuständigkeiten
• Keywords
• Ablauf
• Aufgabe des Low-Level nach dem ersten Schuss

Was wir mMn ändern sollten: vermehrt darauf achten, die gefährliche Kack-Situation

"Escort Flight kämpft unter stetigem SA-5 Beschuss gegen SU-27, um eigene tief herumkrebsende Striker zu schützen"

zu vermeiden.

Es muss klar sein, daß entweder die balburische SAM- oder die CAP-Bedrohung sauber weggemacht werden muss, damit hier mit Aussicht auf Erfolg agiert werden kann.

Daher gibt es drei resultierend drei Hauptaufgaben:

• Ein Escort Flight - SU27 weghauen
• Ein DEAD Flight - mehrere SA-5 weghauen
• Ein Strike Flight - zwei ZSU-23 und ein paar andere Fahrzeuge

..und ein paar von diesen Maschinen haben halt einen zweiten Sitz für die Rettung.

Von daher schlage ich vor, Vodoo zum Strike zu machen - die sollen sich die Base halt selbst freischießen, statt daß zwei Flüge um die Base eiern müssen, also nur noch einer.

Intruder kriegt HARMs und wird zum DEAD Flight.

Damit haben die drei Flights klare Rollen: Escort, DEAD. Die einzige verbleibende Swing-Role ist Voodoo mit Strike+CSAR

Zum Vergleich - die bislang praktizierte Swingrole war Cobra Escort/DEAD. Diese musste mit vier Maschinen gefühlt alles , was ernsthaft zurückschießt, alleine stemmen. Während ZWEI weiter Flights sich mit potentiell gesamt 32 Mavericksum zwei läppische ZSU-23 stritten.

Weil es gestern schon als Vorschlag schon gefallen ist - was ist mit GBU-39 SDB? Ich bin dagegen:

Ich sage mal so, die sind 20 Jahre jünger als das HARM-Modell, die wir in BMS 4.38 fliegen

Damit auf SA-5 - die aus den 60ern stammen, loszugehen.. hmm wie soll ich es sagen, dann lasst uns konsequenterweise gleich auf "Robbenbabies tot hauen umsatteln".

SDB sind natürlich super, und super einfach. Leider ist "Ziele im 2D Recon raussuchen, hinfliegen, Pickle , heimfliegen" halt furchtbar öde und.

SDB benötigen als Würze einen TE-Bauer, der ein passendes Szenario mit JTAC oder FAC, Koordinaten aufschreiben oder Datalinken, Laserblinken, drumherum baut.

So ist diese Mission aber nicht angelegt.

Man erinnere sich, die HARM war in BMS 4.32 auch mal so. Eine super feine Altherrenwaffe, auf der Buchenau-LAN beliebt. Leicht einen sitzen habend, schön ein Bier in der einen Hand, und dann mit 100% Treffergarantie Ziele im HAD auswählen und als foursship dann acht SA-10 wegräumen, vor dem Threat Circle umdrehen, als erste an der Bar sein.

Heute berücksicht BMS 4.38 dagegen die INS-Drift in der AGM-88, sie fliegt nicht todsicher auf eine Koordinate zu wie einer GPS-guided SDB. D.h. sie benötigt zumindest für einen Teil der Flugdauer ein aktiv strahlendes Ziel. Dazu erfordertsie einen sauberen Handoff, dazu ein wenig Switchology und Parameterwissen. Und taktische Anwendungswissen run um Weaseling, Hunter-Killer Taktiken sind gefragt.

SEAD ist wieder "You-gotta-be-shitting-me". Geil. Macht Spass.

Das hätte ich gern weiterhin in dieser Mission, nur halt mit ein paar mehr Piloten.

Nach meinem ersten Flug unter "Advisory" Regeln noch eine Anmerkung.

Es zu Beginn der Mission, während des Rampstarts, Unstimmigkeiten. Einige Flights spulten die althergebrachte Sequence U2 > U3 >U4 > U6 durch, während ich unter Advisory verstehe: U3 > U6. (und beim RTB zum Ende der Mission: U6 > U3)

Das beachtend, was Pitbull richtig als Herleitung argumentiert hat, macht es für mich unter "Advisory" keinen Sinn, zu Beginn der Mission anders zu verfahren als während der Landung.

Was das zuletzt nur ein "Gewohnheitsfehler" während des Rampstarts oder seht ihr das anders?

Kenne ich auch so. Im Balkan Ausprobiert mit NATO F-16-50 vs. FRY SA-20 - feuert nicht.

Ich finde Pitbulls Zusammenfassung gut, da er letztlich die von uns angewandten verschiedenen Verfahren mit Namen benennt, und an den richtigen Stellen verfeinert (z.B. durchgängig U3 bei Advisory).

Ein TE-Bauer entscheidet also, wenn ich es richtig verstehe, welches Verfahren in der TE gilt: Advisory – Unrestricted – Full KI ATC – human ATC

Sollte es kein ausreichend ausgearbeitetes Briefing geben, dann entscheidet hat MC oder wir diskutieren eben es vor dem Flug aus hauptsache es ist festgelegt, bevor wir in 3D gehen.

Ich finde übrigens , auch vom Normalpiloten kann man erwarten, daß er seine Anflug-Absichten im Funk kundtut, KI, und/oderden anderen Piloten zuhört, und ein vorher definiertes Anflug-Verfahren abfliegt. Mehr ist hier vom Piloten ja auch nicht verlangt.

Gegenbeispiel: Wenn einer stumm, taub und mit einem irgendwie adhoc selbstausgedachtem, vom Briefing abweichenden Verfahren zur Air Base zurückkommt, dann ist das für mich ein Emergency, dem ich aus dem Weg gehe, indem ich meinen Anflug abbreche.

Von den vier Verfahren Pitbulls kann ich übrigens gleich ausmachen, welches mir am besten gefällt

Marvel offenbar auch, denn sein Gegenvorschlag ist aus meiner Sicht keiner, da er eigentlich lediglich Pitbulls "Advisory" mit anderen Worten beschreibt. Marvels Vorschlag, die Landerichtung generell auf "ILS-Richtung" festzulegen, möchte ich ablehnen, denn:

A.: Das sollte dem TE-Bauer, oder dem ersten landenden Flieger überlassen sein

B.: Wäre hier eine Regelungslücke bei Airbases, die ILS in mehrere Richtungen besitzen

C: Wäre hier eine Regelungslücke bei Airbases, die gar kein ILS haben

Ich fände super, wenn wir noch mit aufnehmen, wie wir bei Go-Arounds und Emergencies verfahren - da diese ehrlicherweise bei uns ja an der Tagesordnung sind.