Yurgon

Yes, that would be very helpful!

This is an odd problem indeed. In your track, I saw exactly what you described. After your check-in with the JTAC, the player stopped transmitting radio messages. I took control of the track and still was unable to transmit messages on either radio. I then ran the track again, took control immediately, and the radios worked just fine. At some point in the track I believe you switched the Frequency Selection Dial on the ARC-186 FM radio to the EMER FM position. On that position, you'd be transmitting and receiving on a dedicated guard frequency and no longer be able to talk to the JTAC. However, that should not stop transmissions from working at all, and should have 0 effect on the other radios. Given the hard to reproduce nature of this issue, if you can somehow isolate the one cause for this issue, that would go a long way to eventually getting it fixed by ED.

Wow that's really cool, thanks!

Da müsste @Lino_Germany mal schauen.

I've tried the Instant Action -> AH-64D -> Syria -> AH-64D Cold Start mission and for me the Autostart worked okay. Also ran the Autostart in Caucasus -> AH-64D Cold Start and again, no issues (in DCS 2.9.1.48111). I never noticed the "APU ON LIGHT MUST BE ON WITHIN 20 SEC" message that can be seen in your video. On top of that, I tried beginning the Autostart with a full up collective, but that was corrected as part of the sequence. I tried with a fully deflected cyclic, but that, too, didn't cause any issues and didn't prevent the APU from starting up okay. Does the issue occur for you every time you run the Autostart sequence? Can you try in another mission? You can try to repair DCS: Windows Start -> Eagle Dynamics -> Repair DCS World OpenBeta. If that doesn't do anything and the issue persists, you can try to rename your Saved Games\DCS.openbeta folder and try again with a minimum configuration. In any case you can later delete the newly created Saved Games\DCS.openbeta and rename your previous one back to get all your configs, keybinds and so on back. Let us know if any of this helps.

It's very well hidden. C:\Users\{Your Windows User}\AppData\Local\Temp\DCS{Version}\LastMissionTrack.trk

In many ways, I agree with your assessment. While I can't really speak to the F-16, for the simple reason that I'm a complete novice in it, I feel rather strongly that the workflow in the Hornet is also extremely clunky and error prone - compared to the A-10C. But that latter aspect may well be the source of the issue. Once we get to know and appreciate a nice and solid workflow, and once we've put in the time to learn it and make the best possible use of it, we tend to compare every other workflow against this one. Often times, what we learn later on appears to fall short - why isn't everything as simple and straightforward as in module XYZ? Of course nothing beats the A-10C workflow, period (short of maybe an F-35). And then there's the aspect of training and procedures. DCS training missions are designed for newish players with little to no background. I'm not aware of any "transition" trainings that teach Hornet pilots how to fight in the Viper or any other similar combination. What we do in DCS and how we do it may have little to do with how they do it in the real jet. Pilots don't usually show up at a battlefield and decide to take out targets of opportunity they just became aware of and cycle between weapons and acquisition methods. I'm sure it happens, but even then there'll be tons of planning ahead of time to be as prepared as one can be. CAS isn't a specialty for the F-16 community at large. Some squadrons train to it, others only do so when the need arises, and I believe yet others never train to it at all. Obviously, those that train to it will make sure all CAS qualified pilots have the workflow down, and they'll spend a lot of time on the range before they go into any theater. Is the DCS F-16C fully representative of its real life counterpart? I really don't know, but ED are usually working off the best information available and they tend to do a fantastic job of getting as close to the real deal as possible within the confines of a video game. There's not much reason to restrict access to, say, the DED workflow in a jet like the Viper. The quality of the TGP, radar acquisition range, exact frequencies and capabilities, sure, it makes sense to protect this information. How pilots interface with the systems, I believe that's probably very accurately modeled because there's just not much reason to classify or restrict this kind of information (then again, I have no clue how the US DoD makes its decisions regarding classification). Like Dragon1-1 also said, the F-16C Block 50 wasn't invented in 2005 (or whatever time period "our" F-16C represents); it builds upon a 30+ year legacy, and not everything is a blank sheet design. Which is also why I'm so fascinated with the A-10C: the people in charge of upgrading the A-10A went to all the other fighter communities and asked them what they liked, what they didn't like, what worked well and what didn't - and that shows in the A-10C. But of course the A-10 is a purpose built Air-to-Ground jet, with Air-to-Air being a side note, unlike true multipurpose jets like the F-16 that have to excel in both realms. Long story short, if we learned to fly the F-16C (F/A-18C, JF-17, take your pick) like the real pilots and following a multi-month curriculum, we might find the jet and the workflow to be super capable and totally natural.

Hab zwei verschiedene von Anker im Einsatz und bin im Prinzip zufrieden. Vor allem verwenden die nicht diese Micro-USB-Superspeed-Anschlüsse direkt aus der Hölle, die bei einem Billig-USB-Hub bei mir so labberig waren, dass gefühlt jeder Lufthauch die Verbindung zum PC unterbrochen hat. Aber, bei dem einen Anker-Hub war das Anschlusskabel mal gerade irgendwas um 50 cm kurz, fand ich eine ziemliche Sauerei. Tendenziell würde ich Anker also schon empfehlen, aber dann im Detail schauen, ob die Kabellänge passt, oder ein passendes Kabel dazubestellen.

Yes, indeed. It's just that pilots don't usually die from using bad NVGs, and their crewmates most certainly wont. Even if the pilot flying was blinding himself, there's still the dude on the other seat who can take control at a moment's notice. It's all a matter of crew coordination and supporting one another, which we can't simulate in single player. In single player, we also don't get a commendation for denying to fly a mission for the simple fact that it's a death trap and no aviator should be forced to fly under such circumstances. But the campaign does exactly that - it forces the player into an extremely dangerous scenario and then also denies the use of the best available tool to help them. I would say NVGs should be allowed, period. We're talking about flying in IMC in a non-IFR environment. If this was about a navigation exercise in complete darkness, with an extremely accurate flight plan that should keep the aircraft clear of all obstacles when followed closely - that would be a cool challenge, and I believe this kind of flying was actually practiced by some armies during the cold war. Of course they'd mapped every single powerline and knew exactly what they were doing, and they were only doing so because in case of WW III (and in case it lasted more than 20 minutes) it would be absolutely vital to have this capability. Sending a search and rescue helicopter (or is it a search & destroy mission? Not quite sure) into a mountainous region at nightfall with significant fog and a very generous "flight plan" that doesn't provide pilots with the required speeds and timings to be able to follow it with no visual references - that's a death trap. It's bad mission design. And I don't care if the helicopter has a working search light. This kind of flying just doesn't make any sense. Or rather... ordering pilots to do so should only be the case in absolutely extreme situations where the mission goal is more important than the crew. The briefing didn't indicate such circumstances. It sounded more like "Yeah the weather is bad, visibility is bad, it's mountainous terrain... we know, we know, you don't like it. Who cares, deal with it. Oh and BTW, if you use NVGs we'll shoot you in the back of your head". This is basically the 101 of bad mission design and is also the reason I don't care weather or not the search light used to work better before.

So there I was... finally getting back to the Argo campaign. When I first played it, I always got a CTD in mission 3. After I got a new graphics card, that CTD was gone, but I never got around to flying the campaign again - until a few days ago. Besides a few woes with the cargo in mission 3, I enjoyed it quite a lot. Now in mission 4, approaching Batumi, I just thought this looked absolutely fantastic and gorgeous. Since it was getting dark, and obviously going against the briefing, I went to check if the NVGs provided better visibility. They didn't, and I switched them off. A minute later, my screen went black. What the heck? I was forced to end the mission, checked the debrief... 3 of 4 crew members just died for no apparent reason. What the hell?! Ran the replay, took control before I had initially switched on the NVGs, and smoothly continued to the next turn somewhere in the mountains beyond Batumi. Switched on the NVGs to test a theory - yup, within a minute both pilots were dead. Well, cool, if that's the way you want to treat players, please allow me to verbalize my deep discontent with this design decision. What a glorious waste of my time, and who knows what the rest of the missions might bring in regards to "parenting" and punishing the players. Campaign uninstalled. Too bad, I had enjoyed it thus far. To end on a positive note: Some campaign creators decide to count a mission as "successful" whenever the player lands back at base, regardless of how well things went along the missions. Personally, I tend to prefer this way of giving players a lot of leeway. It doesn't take away from a good mission, and may actually allow players to work around a bad one. If the Argo campaign were to be updated in this fashion, I would greatly appreciate it! Of course nowadays we can just skip ahead to the next mission right from the campaign screen, but I found this "feature" in mission 4 so terribly disappointing that I'm really not looking forward to finding out what other questionable decisions await in the missions to come. (There goes the positive note... sorry.)

Hoppla, da haben wir ganz vergessen, das Forum zu informieren. Wir treffen uns heute um 18:00 im Restaurant "Die Schmiede" in der Schmiedestr. 39, wir haben einen Tisch für 4 Personen im OG. Aber falls jemand spontan kommt, kann man ja hoffentlich noch einen Stuhl dranschieben.

Tatsache! Ich war mir sicher, dass ich das mal ausprobiert hätte und es seinerzeit nicht ging; entweder wurde das also geändert, oder ich hatte es schlicht falsch in Erinnerung. Auf jeden Fall cooles Feature, und auch gut, dass LAlt + c immer die gleiche Tastenkombination ist, egal ob Flaming Cliffs oder DCS-Modul.

Soweit ich weiß sollte das immer der Fall sein; bei einem Triebwerksausfall dreht zwar (wenn der Schaden nicht katastrophal ist) vorne noch der Bläser, aber die Welle mit der Hochdruckturbine dreht nicht mehr mit hinreichender Drehzahl und das entsprechende Triebwerk kann keinen Luftdruck mehr bereitstellen, um den zugehörigen Hydraulikkreislauf unter Druck zu setzen. Fallen beide Triebwerke aus, sollte man also nach ein paar Steuereingaben keinen Hydraulikdruck mehr überhaben, und eine Notlandung im MRFCS ist dann nur unter absolut optimalen Bedingungen empfohlen. Ansonsten lieber mit dem Schleudersitz aussteigen. In DCS ist das seit Ewigkeiten anders umgesetzt, auch nach einem Triebwerksausfall wird der zugehörige Hydraulikkreislauf noch unter Druck gehalten und das Flugzeug lässt sich im Wesentlichen normal kontrollieren. Wenn also nur ab und zu auf einen Triebwerksausfall auch ein Ausfall des zugehörigen Hydrauliksystems folgt, scheint es da noch irgendeine Zufallskomponente zu geben, die dann Folgefehler provoziert - oder halt auch nicht. Das wäre dann ein klarer Fehler; muss ich mal ausprobieren und ggf. melden. Da würde ich am ehesten beim Hoggit-Wiki für die Simulator Scripting Engine schauen: https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation Grundsätzlich ist es aber so, dass die Scripting Engine auch nur Zugriff auf Eigenschaften hat, die irgendwie exponiert werden. Bei so grundlegenden Sachen wie Schäden am Flugzeug vermute ich, dass all das auch im ME-Interface verfügbar ist. Aber vielleicht hat man mit Scripting feineren Zugriff, einen Blick ist es sicherlich wert.

Gute Frage; ich kenne nur den HUD-Readout und den Backup-Altimeter, aber die beiden sind meines Wissens gekoppelt, denn wenn man am Backup-Altimeter den Luftdruck ändert, wirkt sich das auch sofort auf das HUD aus. Es wundert mich, dass irgendein Rechner im Flugzeug (zumindest in DCS) scheinbar Höheninformationen noch aus anderen Quellen bezieht. Zumindest in der A-10C bin ich mir recht sicher, dass allein der eingestellte Luftdruck für die Höhenberechnung verwendet wird, und da wird immer wieder drauf hingewiesen, dass das korrekte QNH eingestellt werden muss, weil das IFFCC sonst mit der falschen Höhe rechnet und die Waffenberechnungen entsprechend falsch wären. Aber gut, wenn ich A-10C und F/A-18C in Sachen Ergonomie vergleiche, drohen wir in einen Flamewar zu driften...

Yeah, could be! On the other hand, what are the odds of signal lights breaking between power cycles? They could also break in the air, but I'm not aware of any signal lights test after the Before taxi checklist.

Ich kann mich nur wiederholen: Faszinierend. Gerade getestet, bei Takeoff from ground steht für Wegpunkt 0 eine Höhe von 2000 Metern. Naheliegenderweise habe ich das zum Test im Cockpit auf 33 ft gesetzt (sollte für Kobuleti annäherungsweise passen) und hatte dann anschließend trotzdem das gleiche Problem. Ich bin mir nicht sicher, ob die Bombe tatsächlich zu kurz geworfen wird, es sieht fast eher so aus als wenn der Laser zu spät feuert. Ich habe in einem zweiten Anflug den Laser selbst gefeuert und das etwa 8 Sekunden, bevor es das Flugzeug getan hätte, und da hat die Bombe den Laser aufgefasst und konnte sich noch ins Ziel schleppen, obwohl der Anflug schon recht flach war (nach einem Abwurf aus 10.000 Fuß). Edit: Besten Dank @maikchaos für das weitere Experimentieren! Ich habe den Bugreport entsprechend ergänzt. Der Fix ist dann vermutlich eine super minimale Änderung am Code des Missionseditors, um die Höhe von Wegpunkt 0 bei Takeoff from ground anzupassen.

That certainly sounds plausible, thanks.

Sure, that all makes perfect sense. But my question is: with APU and APU Generator on, all of these Signal Lights are already working, to include the NMSP and the Homing Indicator Lights, the AoA Indexer Lights, the Refueling Status Lights and the GUN READY Light. I just want to figure out why the test of all these lights is moved all the way back to the Before Taxi checklist when it could just as well be performed as soon as APU and APU Generator are on - do you know if there's a specific reason for that, or is just "that's the way it was designed way back when, no particular reason"?

Good points all around! This one in particular I'm always wondering why the second test comes after engine start; with APU and APU Generator being on as part of the Prior to Engine Start checklist, it always seems more logical to me to move the second Signal Lights Test to this checklist. Do you know why it's part of the Before Taxi checklist instead?

Ich habe einen Bugreport bei den Closed Beta Testern eingereicht. Hier meine beiden Tracks aus 2.9.0.47168, falls da nochmal jemand reinschauen will (hab eine neue Mission gebaut, die der von Maikchaos aber sehr ähnlich ist): Track Takeoff from ramp, Treffer (2.16 MB) Track Takeoff from ground, verfehlt (2.67 MB)

Faszinierend! Mit deiner Testmission kann ich das Problem nachvollziehen. Takeoff from Ground, und egal aus welcher Richtung ich angreife, alle GBU-12 fallen zu kurz. Ich dachte dass vielleicht die Initialposition falsch im Flugzeug hinterlegt ist (so sieht es aus wenn man die initialen Koordinaten beim Alignment mit den Koordinaten beispielsweise aus der externen F2-Sicht vergleicht) und man die Koordinaten von Wegpunkt 0 anpassen muss, aber das hat in einem zweiten Test keine Veränderung ergeben. Außerdem habe ich versucht, zum Zeitpunkt der Zieldesignierung den Laser zu feuern, damit das Flugzeug die exakte Schrägentfernung zum Ziel und damit dessen Koordinaten sehr exakt bestimmen kann, aber auch das hat keine erkennbare Veränderung ergeben. Lasern während der Pickle-Timer runterzählt, also lasern beim Abwurf der Waffe, hat ebenfalls keine Veränderung gebracht. Ich habe zwar alle Ziele mit dem TPOD mittels TDC Depress designiert, aber nur für den Fall der Fälle habe ich die Höhe des Zielwegpunktes auf 30 Fuß runtergesetzt - auch das hat erwartungsgemäß keine Änderung gebracht (außer dass der TPOD bei WPDSG dann gleich beim Ziel ist ). Nach Hotstart auf der Runway kriege ich sofort einen Volltreffer. Wäre ich Mister Spock, würde ich jetzt eine Augenbraue zücken. Ich will mal sehen, dass ich ein paar Tracks mit Autostart aufzeichne, die so simpel und bis auf die Spawn-Art so identisch wie möglich sind, und dann einen Report einreichen.

Im englischsprachigen Teil des Forums schreibt Reflected dazu: Da sind ihm also tatsächlich die Hände gebunden, Eagle Dynamics ist informiert und wir können nur auf einen Fix warten. Mehr kann ich an dieser Stelle auch nicht sagen, aber solche Probleme, die Kampagnen kaputtmachen, werden meist relativ schnell behoben. Und Reflected sagt noch, dass die KI-Hubschrauber wohl irgendwann doch abheben, man muss da nur einige Geduld mitbringen - das kannst du ja mal ausprobieren.

Du müsstest vielleicht ein bisschen konkreter werden, um welche Kampagnen es geht und welche KI-Probleme dem genau im Weg stehen. Die Kampagnenersteller kämpfen da ein bisschen gegen Windmühlen, weil sich DCS ständig verändert und weiterentwickelt. Manches KI-Verhalten ist seit Jahren problematisch, anderes wird nach Meldung relativ schnell korrigiert. Grundsätzlich ist das Verhalten der KI-Einheiten in DCS schwierig und entsprechend müssen Missions- und Kampagnenersteller eine Menge Erfahrung sammeln, damit die KI wie gewünscht arbeitet. Einige Leute haben das zur Kunstform erhoben und lassen die DCS-KI Sachen machen, die ich für unmöglich gehalten hätte, andere lassen es bei sehr einfachem Verhalten. Aber so oder so, eine Änderung in DCS kann natürlich alles durcheinanderbringen. Gute Kampagnenersteller erkennst du ganz besonders auch daran, dass sie ihre Kampagnen dann korrigieren, und das auch Jahre nach der Erstveröffentlichung - obwohl die Kampagnen zum Zeitpunkt der Veröffentlichung recht sicher so funktioniert haben wie geplant und die Kampagnenersteller insofern Fehler ausbügeln müssen, für die sich nichts können. Große und grundlegende Änderungen der KI können noch Jahre auf sich warten lassen, andere vielleicht Monate. Wenn es um konkretes Fehlverhalten geht, kann man das aber mit entsprechenden Reports auf der Prioritätenliste weiter nach oben schieben. Insofern: Um welche Kampagnen und welche Probleme geht es dir konkret?

Als ich es das letzte Mal probiert habe, hat Lalt + c in FC3 gar nichts gemacht. Ich wüsste auch nicht, weshalb man den Mauscursor haben sollte, wenn man damit nichts manipulieren kann, insofern nehme ich an, dass man den normalerweise nicht einblenden kann und immer im Mouselook ist. Ja, gut möglich dass bei dem besagten Video dieser Mod zum Einsatz kam.

Versteh ich grad nicht. Mods liegen in Gespeicherte Spiele\DCS.openbeta\Mods. Das Verzeichnis kannst du da wegschieben und dann sind die Mods weg. Falls du noch Mods direkt im DCS-Installationsverzeichnis C:\Eagle Dynamics\DCS World OpenBeta haben solltest, dann ist das Mist, da gehören seit Jahren keine Mods mehr rein und die müssen alle nach Gespeicherte Spiele. In dem Fall: Wie von Caponi vorgeschlagen eine gründliche DCS Reparatur laufen lassen, die entfernt dabei auch alles aus dem Installationsverzeichnis, das da nicht hingehört. Was du beschreibst klingt aber danach, dass du 1000 Assets aus einer Mission entfernen willst, um konkret zu testen, warum bei dir die GBU-12 nicht treffen. Mach's doch einfach anders rum: Fang mit einer neuen und nackten Mission an, in der es genau dein Flugzeug und 1 Ziel gibt und prüf, ob das Problem weg ist. Und danach fügst du Stück für Stück Assets aus denjenigen Mods hinzu, die du im Verdacht hast, bis das Problem wieder auftritt, und danach prüfst du, ob eine nackte Mission mit deinem Flugzeug, einem Ziel und genau dem einen Asset wieder zum Problem führt - dann hast du recht sicher identifiziert woran es liegt und kannst dich mit dem Autor des Mods/Assets in Verbindung setzen.