Yurgon

Oh yeah, I'm aware there's always the question how much the JTAC should micromanage and how much freedom should be given to the flight to choose the best tactics and tools on their own. If time isn't critical down to a few seconds, I always see this as a dialogue where the pilot could recommend "Hawg 2 prefers Shooter-Cover, Dash 1 can rifle times two" and then the JTAC can roll with it, or insist on Shooter-Shooter for reasons that don't need to be debated then and there. The whole thing is a team effort and everyone should do their best to accommodate the others. When there's a chance for a debrief later on, pilots and JTACs can pass extremely valuable points to the other side; in DCS I've learned so much from working with others and getting a good debrief on my mistakes, or where they'd have preferred a certain tactic or a certain keyword. I imagine it's not that different out in the real world. Maybe there's a flight holding south of the target and a right pull was the JTAC's way to ensure deconfliction. After all, the JTAC owns the airspace. But again, you're right and I agree that the JTAC should give as few restrictions as possible and as many as necessary. Anything that's not actually necessary, leave it up to the pilots. Some really great examples, thanks! Now we're really down in the weeds, but with a flight holding east of the target (B8 in use in my example suggests keyhole is in effect and Point Echo is close to TRP Coors, since "1, 2, 3 B8" was given in my example), a FAH north to south or reciprocal would require the flight to maneuver several miles either northwest or southwest until they could turn onto their final attack cone and have enough distance to call IN, acquire a track and get cleared hot. With A-10s in particular, that would delay the attack by some 2 minutes or thereabout. Plus, I've heard repeatedly that friendlies should never be overflown during the run-in, and the attack cone (and anything behind that cone) should be well clear of friendlies in case of weapon malfunction or accidental weapon releases. With friendlies 600 meters south of the target, the FAH should be pretty much anything except north to south or reciprocal, is my understanding. Again down in the weeds. I understand "in north" to mean "in to the north", or does it mean "in from the north"? Personally as a flight lead I always verbalize "in to the direction, off to the direction, sort to the direction" so there's no ambiguity whatsoever. I've also made it a habit to put all 3 directions as "to" instead of mixing "in from ..., off to..., sort to..." which requires mentally flipping "from" and "to" within the same part of the F2F brief. Anyway, when you describe in from the north, then a left turn and then a sort to the west, the flight would have to overfly the target right after the attack to sort on the opposite side of it. That's probably not what you had in mind... That's a great example! I've never thought about this one before, but it makes all the sense in the world. I'll try to remember this and add it to the toolbox for when such a situation comes up.

All great points! I've heard from Rifle aka Hawg63 (former Canadian SOF JTAC) that he would sometimes shorten the workflow when he was satisfied that the pilots had built the proper SA and he had worked with them for a bit and had the warm and fuzzy feeling that everyone was on the same page. And I believe he was usually in the middle of it, so any targeting mistake would endanger him personally. Until a JTAC has built the foundation and gathered the experience to be confident in taking shortcuts, I'm right there with you that the full process of passing 9-lines and readbacks should be followed. And that leads me back to my original example. "Hitman, Hawg 2, tally two T-72 tanks approaching TRP Coors from the west, ready to engage with Mavericks on your request!" The idea was to provide an arbitrary scenario where naming targets or naming 9-lines would come in handy. Following up on this example, the JTAC would know where to look, would know that the pilots are confident to attack from their current position, that they think Mavericks would be the best possible weapon, and the JTAC could then punch out a 9-line in no time: Hawg 2, Hitman, CAS Brief H04. Gameplan: Type 2, Bomb on target, Shooter-Shooter Maverick. Hitman, Hawg 2 copies Shooter-Shooter Maverick, ready 9-line. Hawg 2, Hitman, 9-line: 1-2-3 B8, Elevation 560 ft, Target is two by T-72 eastbound, Location 200 meters west of TRP Coors, No mark, Friendlies South 600, Egress right pull to B8. Read back 4, 6 and 8. Hitman, Hawg 2, 560 feet, Target now passing TRP Coors eastbound, South 600. Hawg 2, Hitman, Make your final attack heading 220 clockwise 300, report leaving IP. Hitman, Hawg 2, leaving IP, in hot 260. Hawg 2, Hitman, Cleared Hot! [boom, boom] Hawg 2, Hitman, BDA, both targets destroyed! As long as we're ready to accept a relative line 6, as in "from your tally", "200 meters west of a reference point" and so on, I see no advantage in the flight passing lines 4 and 6 to the JTAC to then pass the same lines 4 and 6 back to the pilots. If the tanks were moving at any decent speed, a 6 digit grid would be outdated by the time the pilot passed it to the JTAC and would be all wrong by the time the JTAC passed it back to the pilot. My point is, the proximity of the target to a known reference point could serve as lines 4 and 6 in a dynamic scenario. Now if this was the first engagement with that particular flight, I would do a lot more to correlate the targets and obtain PID. But in that case the whole point of referencing a previous 9-line would be moot anyways. Also note how the pilot in this example assists the JTAC with correlation by reading back the current position of the targets ("Target now passing TRP Coors eastbound") instead of just reading back "200 meters west of TRP Coors". Finally, I'll have to note that all of this is my armchair take on JTACing and there's every chance this is not doctrinally in line with JP 3-09.3 or JFIRE. But in the DCS context I think it'll be just fine.

Ah, besten Dank für den Track, da haben wir's doch. Du hast keine Wegpunktaktion vergeben, die sofort beim Erreichen des Wegpunkts ausgelöst wird (also gleich zum Start der Mission, wenn es Aktionen für Wegpunkt 0 sind). Stattdessen hast du getriggerte Aktionen vergeben, aber keinen Trigger dafür gesetzt (also auf Deutsch keinen "Auslöser"). Will sagen, diese Aktionen sind für diese Einheit verfügbar, müssen aber erst ausgelöst werden. Zwei Optionen: Am einfachsten du machst es wie von razo+r oben schon beschrieben und setzt diese Aktionen stattdessen bei den erweiterten Wegpunktaktionen, dann sind sie sofort verfügbar. Oder du setzt eine Triggeraktion, z.B.: Type: ONCE CONDITIONS: TIME MORE(1) ACTIONS: AI TASK PUSH(GROUND-1 / 1. Set Frequency...) AI TASK PUSH(GROUND-1 / 2. Transmit Message(...)) (Die Condition "Time more" könnte man auch ganz weglassen, aber zumindest früher wurde empfohlen, eigene Trigger erst 1, 2 Sekunden nach Start der Mission auszuführen; das gilt besonders, wenn es sich um zahlreiche und komplexe Aktionen handelt). Damit habe ich den falschen Soundtrack in der Hornet. Pfui! Zu der Musik gehört eine Tomcat in die Mission!

Bei sowas am besten immer gleich die Mission hier mit hochladen (oder bei Google Drive, One Drive etc, und dann den Link mitschicken). Manchmal hapert es an Details wie der Modulation. Da kann man dann lange rätseln, oder man schaut sich das kurz in der Mission an und weiß direkt, wo der Fehler liegt.

When we talk about the DCS AI JTAC, then yes. When we talk about a human JTAC, it makes all the sense in the world to keep the previous target points or coordinates, as the JTAC and the flight can then very easily correlate threats: "Hitman, Hawg 2, tally two T-72 tanks approaching TRP Coors from the west, ready to engage with Mavericks on your request!" This assumes that target points are somehow named or at least enumerated; a quick and easy solution is to call them "target reference points" and either go TRP1, TRP2, TRP3 and so on, or give them ad hoc names, like TRP Coors, TRP Foster, TRP Budweiser or whatever both parties can easily use and recall. I would make it a habit to always keep previous target points and learn how to deal with the clutter. It'll come in handy in certain missions and of course when working with actual humans in the MP environment.

Für die Struktur der Ordner in den DCS-Verzeichnissen? Nein. Warum auch? Es handelt sich dabei um spielinterne Datenstrukturen, irgendwo muss der Kram ja schließlich gespeichert werden. Man wird aber sehr häufig im Forum Hinweise finden, dass in Ordner X oder Datei Y bestimmte Infos zu finden oder Änderungen vorzunehmen sind, um bestimmte Ziele zu erreichen. Mit etwas Tüfteln und Ausprobieren findet man dann auch recht viel darüber raus, was wo zu finden ist und welche Änderungen und Hacks man darin sinnvoll vornehmen kann, um DCS zu erweitern oder den eigenen Vorlieben anzupassen. Das Blöde ist: Wir neigen dazu, uns DCS damit kaputtzumachen, und das äußert sich dann in den absurdesten Problemen und Schwierigkeiten. Gerade gestern hatte ich von einem Spieler gelesen, bei dem in einer Kampagne eine bestimmte Aktion nicht funktionierte, bis er Überreste von VAICOM aus seinem DCS weggelöscht hat, und plötzlich lief die Mission normal und alle Trigger haben funktioniert. ED würde sich nur selber in den Fuß schießen, wenn das alles offiziell dokumentiert wäre. So eine Doku müsste natürlich mit jeder Änderung aktualisiert werden und der Aufwand stiege dann noch weiter an. Insofern gilt: Wir müssen uns selbst erarbeiten, wo man was findet bzw. machen kann. Alle manuellen Änderungen, die wir irgendwo in den DCS-Dateien und -Ordnern vornehmen sind nicht offiziell unterstützt, und wann immer wir ein wie auch immer geartetes Problem mit DCS haben, ist der erste Schritt, eine Reparatur von DCS durchzuführen und danach Gespeicherte Spiele\DCS umzubenennen und mit einer komplett nackten und sauberen Config anzufangen. Wenn das jeder Spieler mit Problemen machen würde, hätten wir wahrscheinlich 75% weniger Support-Anfragen und Bugreports im Forum und im Discord. Deshalb... ... finde ich das auf der einen Seite eine super coole Idee, denn in der DCS-Ordnerstruktur finden sich zahlreiche interessante Dateien und wir können da sehr viel coole Sachen machen. Die richtige Installation von Mods wäre sicherlich der erste große Aspekt. Auf der anderen Seite besteht dann eine gewisse Gefahr, dass noch mehr Leute experimentierfreudig werden, das Kleingedruckte wie immer überlesen und wir im Forum jahrelang ausbaden dürfen "Aber im Guide auf Seite 5 stand, ich soll Datei XYZ editieren und da passiert nichts Schlimmes?!" Außerdem kann sich diese Struktur jederzeit und ohne Ankündigung ändern. Hältst du den Guide die nächsten 10 Jahre auf dem Laufenden und/oder sammelst ein Team, das sich darum kümmert?

Frage ich mich auch gerade. Das gibt es seit Urzeiten und klingt nach genau dem, was @Jel sucht. Für Singleplayer kann man das gleiche als globale Option in den DCS-Einstellungen festlegen, das heißt wenn man sich selbst auf eine statische F10-Karte ohne irgendwelche Einheiten festnageln will, muss man das nicht für jede Mission einzeln erzwingen. Nicht dass ich wüsste. Wobei ich das eine fürchterliche Krücke finde, die ich eigentlich nur benutze, wenn ich nicht sicher bin ob ich richtig fliege, z.B. weil eine Mission sagt "fliege zum XYZ-Beacon auf 123 kHz" und es in dem Bereich 3 verschiedene Beacons gibt und keiner da liegt, wo ich glaube, dass ich hin soll, weil es aber auch keine Infos gibt, um das zu korrelieren (also ein vernünftiger Flugplan würde sowas sagen wie "fliege Heading 100 bei 90 KIAS für 5 Minuten, und das sollte dich ziemlich genau auf Beacon XYZ mit 123 kHz und dem Morse-Identifier XYZ -..- -.-- --.. führen oder so in der Art - schon sowas scheint die meisten Missionsdesigner gnadenlos zu überfordern und dann korreliere ich halt mit dem Kneeboard, ob ich wenigstens grob in der richtigen Richtung fliege). Wäre nice, wenn man das abschalten kann. Aber hey. Auf der anderen Seite sind wir auch als Missionsdesigner nicht dafür da, den Spielern vorzuschreiben wie sie DCS zu genießen haben. Wir können einen Rahmen vorgeben, den die Spieler dann ausfüllen. Wer da mit dem Kneeboard arbeitet - ich finde das völlig legitim.

In a campaign like this, it's a bit hard to capture every deviation players might do. Within the DCS multiplayer context I would usually allow trainee pilots to deviate and wait to see how long it takes them to figure out they're not where they're supposed to be, as long as I'm satisfied it's all safe (ie we're not violating someone else's airspace and we're still well above Joker fuel). So you could either blame the campaign for not being realistic for allowing you to deviate as much as you did, or you could praise it for the instructor being as relaxed as he is, until he's telling you in no uncertain terms how much you screwed up during the debrief...

When the campaign was first released, the A-10C had 3 different radios: VHF AM (aka "Front"), UHF AM (aka "Mid") and VHF FM (aka "Aft"). Back then, only one radio was able to receive and transmit in the UHF radio band and everything was perfectly clear and unambiguous. That said, the new ARC-210 replaced the front ARC-186 VHF AM and can work on the entire range of the VHF and UHF frequency bands and can even switch between AM and FM (depending on the frequency), so the ARC-210 is either called "ARC-210" or "Front". The old ARC-164 UHF radio is still only able to work in the UHF range and is thus still called "UHF" or "Mid". The "UHF Radio" is the ARC-164 UHF Radio. The default frequency is the frequency that it defaults to in the "MNL" or "manual" position, so basically when you switch it to MAIN or BOTH, it'll be on the default frequency. Anything you do to the selected frequency and it'll no longer be on the default frequency. Typically, that's the ARC-186 VHF FM radio, and you'll find the frequency in the briefing images and/or the briefing texts. For the first radio check, particularly in the first few missions, Biff will prefer the ARC-164 UHF radio for the first set of radio comms, because the ARC-164 only requires battery and inverter, whereas the ARC-186 and ARC-210 both require either the APU + APU Generator or left/right engine + associated generator or ground power. That should follow the first radio check on the ARC-164, and Biff will talk you through the steps required to get the Front radio up and running for the radio check ("Front" used to be ARC-186 AM in the A-10C module and is now the ARC-210 in the A-10C II module). Looks to be presets depending on the radio, with [1] through [7] being ARC-164 presets, the element freq probably being preset [1] on the ARC-186 VHF FM (Aft) and at the same time preset [21] on the ARC-210 (Front) and 128.000 AM being preset [22] on the ARC-210 (Front).

There are a few lighting controls that are non-functional in our DCS A-10C unfortunately. I believe this is one of them.

How would you remove a weapon station from a profile and then save the profile?

Only if you discard the first 19 years of its existence. I suppose only military aviation historians can tell us to a high degree of accuracy how much General Dynamics is in the F-16C Block 50, but probably more than a little. It was a simple, straightforward design for a very specific purpose. And you're right, it's a bit hard to understand how it was then used in a variety of roles that had little or nothing to do with intercepting bombers and fighters.

Should be: TSD -> B4 ROUTE -> L4 DIR -> R2-4 Select waypoint from the route If I'm not mistaken, you could also select a waypoint via L1 ?> and set that as your direct-to if you don't have the waypoint in a route.

Yup, I'm pretty sure I read on the forum before that this is the exact reason: To ensure proper minimum spacing/separation between bombs, stations 5 and 7 can not release in pairs (and 5+6 or 6+7 should not be loaded simultaneously anyway). In DCS we can certainly do as we like. IRL pilots wouldn't start to taxi while performing important steps on the avionics. I think that's a complete non-issue: while DSMS (or any of the other items) is being loaded (aka transferred from the data cartridge, that we don't yet have in DCS), pilots wouldn't do much else and most definitely wouldn't taxi. If you look at somewhat official checklists, these steps are pretty far apart, and after LOAD ALL pilots will of course confirm that everything was loaded okay and there are no errors. Also, taxi-out is usually accompanied by a quick brake-check and a quick wiggle of the nose wheel to ensure all these are working fine. In my squad we once had a pilot bump into the tail of another aircraft during a bit of a hold-up on the taxiway because his rudder pedal toe brakes weren't working or there was a controller conflict or whatever. IRL it could be a hydraulic issue within the brakes, so always ensure critical systems are working before you need them. Fiddling with the displays during taxi, that's a great way to damage millions of dollars worth of equipment and create a safety hazard. Again, in DCS we can do whatever we like, but I find that many steps out of real life checklists actually translate well to DCS, though the reason for failure might be different (hydraulics leak vs. controller conflict, for instance).

Dann müsste man GBU-12 als ungelenkt klassifizieren, weil sie dumm vom Flugzeug fällt und erst später (hoffentlich) den Laser auffasst. Aus meiner Sicht ist und bleibt die "AGR"-Klassifizierung ein Widerspruch in sich.

And Windows would never have become the best selling Operating System in history if it was bad. Better not go down the road of "if it sells, it must be good"...

Korrigier mich wenn ich mich täusche, aber die Menüs haben doch in deutsch und englisch lokalisierten DCS-Installationen exakt die gleiche Struktur, oder? Lediglich die Beschriftung wird entsprechend der Lokalisierung angepasst. Und das bedeutet halt, dass es sich nicht um einen Übersetzungsfehler handelt und es sinnvoller wäre, im internationalen Teil des Forums darum zu bitten, die APKWS zu den Missiles zu schieben.

In the context of DCS, that certainly creates a sterile mission. The Raven One campaigns pay a lot more attention to comm discipline that most other campaigns. And while they're extremely well written and have great arcs within and across missions, I do find them to feel sterile at times because the player doesn't communicate unless it's necessary. Somewhere between full real and Hollywoodish there's got to be a balance where missions are realistic, yet entertaining. After all, most of our missions take less than 4 hours and don't include aerial refueling, though IRL missions might take even longer and totally require AAR in many cases. Personally I take more issue with badly written dialog or pseudo-realistic details that are just wrong, like "Squawk 5469" when the transponder can only set octal values, or players having to engage a column of SA-9s protected by Tunguska (that was in a free Apache coop-campaign from the user files; after that mission, we stopped playing that campaign...). A well written dialog, even though probably unrealistic, can elevate a mission, convey important information and deliver immersion and entertainment. In the large scheme of things, I'm all for that.

Chances are I'm going to recommend exactly one of the campaigns that annoyed you... There's "Operation Piercing Fury" which was a good campaign IMO, but the author abandoned it and it's now defunct. However, some really awesome community members keep it alive and it's now available in the user files for the A-10C II (with permission of the original campaign creator, as far as I'm aware). Then there's The Enemy Within 3.0 by Baltic Dragon, which (when it was 1.0) was the very first official 3rd party campaign in DCS. Besides major updates (2.0, 3.0) Baltic Dragon also fixes issues as they are reported and goes through entire campaigns to update them when things change in DCS. TEW 3.0 was recently updated because of radio changes in DCS, and all mission were test-flown. The latest version is available in 2.9.1 Stable and OpenBeta. On the other hand, TEW isn't that much action oriented. There will be action, but for the most part the campaign is story-driven, so it may or may not be what you're looking for. And if you like to get to know the A-10C II deeper than ever before, I've heard great things about the Maple Flag training campaigns and I can totally recommend Iron Flag Part I; all rounds fired will be on the training range, and missions can be quite long (around 1.5 hours). But there's tons of great info on the A-10C and outside of the multiplayer environment you'll be hard pressed to find a more realistic environment to fly in. Other than that, most A-10 campaigns I haven't flown and can't comment on. I'm sure I'm doing many of them injustice here by not mentioning them, but hopefully other forum members will chime in with some great suggestions and recommendations. And finally, besides the abandoned campaigns (only Piercing Fury as far as I'm aware right now), the campaign authors are usually actively monitoring the forums for bug reports and will work very hard to fix issues when they are reported. With the large number of missions and campaigns, even with a solid team of testers, they (in some cases we, as I'm a campaign tester) just can't test all the campaigns all the time to check if the latest DCS update changed or broke something that's essential to the campaign. Bug reports are always appreciated so that missions can be fixed for all players!

Ja, aber das ist nicht aufzulösen. Im Englischen bezeichnet der Begriff "Missile" eine gelenkte Waffe; typischerweise assoziiert man damit Raketen, aber auch manche modernen Gleitbomben werden als "Missile" bezeichnet (z.B. die Air-to-Ground-Missile AGM-62 Walleye), und wenn ich mich richtig erinnere, kann sich "Missile" sogar auf gelenkte magische Speere oder Geschosse in der Fantasy beziehen, die wir nie als "Rakete" klassifizieren würden. Die "Rocket" hingegen ist im militärischen Sinn typischerweise eine ungelenkte Waffe mit Raketenmotor. Auch hier gibt es Widersprüche, weil Raketen für die Raumfahrt selbstverständlich gelenkt sind, aber als "Rocket" und nicht als "Missile" bezeichnet werden - es sei denn es handelt sich um Waffen, die in eine Umlaufbahn geschickt werden, um anschließend wieder in die Atmosphäre einzutreten, dann ist doch wieder von "Missile" die Rede (etwa ICBM: Intercontinental Ballistic Missile). Aus mir unerfindlichen Gründen ist APKWS als "Guided Rocket" klassifiziert (Air-to-Ground-Rocket AGR-20), was auch im Englischen ein Widerspruch in sich ist. Ich meine ich hätte mal gehört, das sei eine Art Taschenspielertrick gewesen, um bestimmte Budgets anzapfen zu können oder die Befindlichkeiten einer Teilstreitkraft zu umschiffen oder so. Da wir im Deutschen sowohl "Missile" als auch "Rocket" mit "Rakete" übersetzen (uns also komplett ein Wort für "Missile" fehlt), muss DCS im Deutschen die Unterscheidung zwischen "Lenkraketen" und "Ungelenkte Raketen" machen, sonst wären beide Kategorien schlicht als "Raketen" zu bezeichnen. Und dann kommt es zwingend zu lasergelenkten Raketen als Untermenüpunkt der ungelenkten Raketen. Das lässt sich nicht auflösen, es sei denn auf US-Seite würde man die AGR-20 in AGM-20 (oder AGM-wasauchimmer) umdefinieren. tl;dr: Das eigentliche Problem ist, dass es bereits im englischen Original den Widerspruch gibt, der sich dann nur 1:1 ins Deutsche überträgt.

Grundsätzlich würde ich immer folgende Unterscheidung vornehmen: Was öffentlich im Forum gepostet wird, kann auch öffentlich zitiert werden. Was in einer Privatnachricht gepostet wird, sollte immer als privat und persönlich behandelt werden, auch wenn die Informationen an sich nicht besonders vertraulich wirken. Eine kurze Nachfrage per Privatnachricht, ob es okay ist, den Nachrichtenverlauf öffentlich zu zitieren, ist dann immer eine gute Idee. Solange man keine persönlichen oder vertraulichen Informationen verrät, kann man ansonsten natürlich immer auch zusammengefasste und nicht wörtlich zitierte Informationen öffentlich weitergeben, ohne den konkreten Autor zu nennen: "Mir wurde gesagt, dass...", "Ich habe aus einer mit dem Sachverhalt vertrauten Quelle erfahren, dass..." oder so in der Art. Es ist dann (wenn man nicht sicher weiß, ob es okay ist, das öffentlich zu machen) immer möglich, dass man künftig keine solchen Infos mehr mitgeteilt bekommt, weil die Veröffentlichung nicht im Sinne der anderen Person(en) war. Eigentlich ist es ganz einfach. Stell dir vor, dass Informationen, die du anderen Personen im persönlichen Gespräch oder in einer Privatnachricht mitgeteilt hast, unter Nennung deines Namens/Pseudonyms irgendwo im Internet zitiert werden. Wenn du das grundsätzlich und immer okay findest, dann spricht vermutlich nicht viel dagegen, dass du das selbst genau so machst. Wenn du hingegen findest, dass private Nachrichten tendenziell als privat zu behandeln sind, dann solltest du vermutlich auch anderer Leute Nachrichten nicht einfach so veröffentlichen.

This! Depending on the intended effect on the target, a RPL SGL with sufficiently short spacing might also do the trick - that works with all stations. Good question! I'm not sure about NWS, but that sounds like something the pilot shouldn't touch while people are working on the jet. It would make sense NWS is prohibited during weapons upload; there might be a safety pin that's inserted (or never pulled) before weapons upload. But this is 100% guesswork on my end. I'm not aware of UFC functions being blocked during weapon upload. Do you have a concrete example of something not working while (re-) loading is in progress?

Awesome! So now we're down to three options. Your DCS installation is broken Your method of starting the jet is flawed You found a bug in DCS (Or a combination of the above) Unless your intention of starting this thread was purely informational in nature, I'm going to assume you are looking for help in order to get the issue resolved. In which case: First, run a DCS repair (Windows -> All Programs -> Eagle Dynamics -> Repair DCS World) If that doesn't solve the issue, I'd take the brute force method of renaming Saved Games\DCS, launching DCS with the absolute bare minimum configuration and trying again. If that doesn't solve the problem, I'm at a a loss. Either way, DCS will create a new Saved Games\DCS folder; you can then delete this new one and rename your old one back. And then try to isolate which setting or which mod may cause the issue at hand. What version of DCS are you running? Share a track with us where the issue is clearly visible. The shorter the better. If you can't be bothered to take these steps, that's fine. Just let us know and we'll stop investing any more time.

In that case the usual repair steps are probably a good idea. First, run a DCS repair (Windows -> All Programs -> Eagle Dynamics -> Repair DCS World) If that doesn't solve the issue, I'd take the brute force method of renaming Saved Games\DCS, launching DCS with the absolute bare minimum configuration and trying again. If that doesn't solve the problem, I'm at a a loss. Either way, DCS will create a new Saved Games\DCS folder; you can then delete this new one and rename your old one back. And then try to isolate which setting or which mod may cause the issue at hand.

Not sure I understand your report. I cross-checked all your tracks in the latest 2.9.1 against my old Stable installation of 2.8.4 from May this year, and both versions show the exact same behavior; all of these assume Master Arm armed and Maverick EO already aligned: Maverick not selected: DSMS shows STBY on black background Maverick not selected but MAV-page visible on other MFCD (or via DSMS Quick Look): DSMS shows RDY on black background and MAV-page displays "SENSOR" along left side Maverick selected: DSMS shows STBY on white background Maverick selected and MAV-page visible on other MFCD (or via DSMS Quick Look): DSMS shows RDY on white background Maverick selected, MAV-page visible on other MFCD (or via DSMS Quick Look) and actively tracking target: DSMS shows RDY on inverted green background Which of these does not happen for you, and/or which of these do you think is wrong? All looking good here and the Mavericks launch just fine for me.