Yurgon

Kannst du uns eine Beispielmission hier hochladen? Das Problem klingt tendenziell so, als wenn entweder deine DCS-Installation beschädigt sein könnte oder Mods das Problem verursachen. Insofern wären die üblichen Schritte: Repariere DCS (Windows Startmenü -> Eagle Dynamics -> Repariere DCS World) Benenne den Ordner Gespeicherte Spiele\DCS um und versuch es nochmal Wenn die Reparatur das Problem behebt, super! Wenn nicht: in Gespeicherte Spiele\DCS (oder Gespeicherte Spiele\DCS.openbeta) liegt deine gesamte DCS-Konfiguration, und auch Mods werden heutzutage dort installiert. Durchaus möglich, dass da etwas durcheinander ist und das Problem verursacht. Wenn du den kompletten Ordner umbenennst, legt DCS beim nächsten Start einen neuen an, in dem nur die nackte Minimalkonfiguration liegt. Je nachdem was bei dem Test rauskommt, kannst du später den automatisch neu angelegten Ordner löschen und deinen alten wieder umbenennen, dann hast du deine ganze Konfiguration und all deine Einstellungen wieder zurück (und ggf. auch das ursächliche Problem ).

@EagleEye das wäre dann auch ein Thema für die Übersetzer.

Ich habe das Navigations-Training für die A-10C (nicht-II) gemacht; möglich, dass für die A-10C II ein anderer Flughafen bzw. eine andere TACAN-Station genutzt wird.

Das Highlight liegt falsch, der Text (in der englischen Version der Trainingsmission) sagt aber, dass du die "1" mit dem rechten Drehrad einstellen sollst. Macht ja sonst auch wenig Sinn, weil du links gerade erst die 3 eingedreht hast und der Kanal für Senaki die "31X" ist. Du kannst jederzeit in der Mission ESC drücken und dir die Historie aller (Text-) Nachrichten anschauen, wenn du da nochmal was nachlesen willst. Stellt man "031" ein, geht die Mission für mich ganz normal weiter. Gibt es sonst stellen, wo Trainingsmissionen steckenbleiben?

I've seen this issue several times in the last couple of weeks and also heard from squad mates seeing the same issue (we're getting ready for our first class of trainees that will do the IQT on the C-101 instead of the aircraft they've joined us for, like A-10C or F/A-18C). Some notes regarding the attached track: DCS 2.9.1.48335 Stable MT Track length in-game is about 55 minutes I'm using fast forward a lot; watching the track should take some 15 minutes The jet is set to start from ramp and I'm using the autostart cheat (for time compression, and because it eliminates me doing something wrong during startup) Air Cond. is checked and verified to be on (didn't do it in the track, but just double-checked to be sure) Roughly 45 minutes after take-off, the battery TEM lights come on I then disconnect both batteries and also switch them off via the BATTERY switch Roughly 6 or 7 minutes later, the master caution and BATTERY caution light (70°BAT) illuminate even though the batteries are still disconnected (I might delete the track at some point in the future when it's no longer needed because 5 MB eats into my allowable uploads) It is worth noting that before recording this track I tried numerous times to get the battery overtemp to happen, but it only did when I had PITOT HEAT ON. With pitot heat off I did not get the overtemp in my tests, though that doesn't necessarily mean that only pitot heat on will cause the issue to appear. Either way, all checklists I've read say to put pitot heat on, so this should not result in a battery overtemp. If I've made any mistakes like too high N1 or N2 RPMs, too high ITT (I made sure to stay below 795° max continuous after take-off) please let me know so that I can re-check if the issue still happens without making those mistakes; I believe I flew the jet within allowable parameters, but I'm still fairly new to it and haven't (yet) studied the manual in detail. Please let me know if there are any questions regarding the track or how to reproduce the issue. C-101EB-Battery-Overtemp.trk

Don't put it there. That's the DCS installation directory, and user mods cannot run from this location. You'll only get an "authorization invalid" error message when you try this. The path from your screenshot is slightly wrong, Like AvgWhiteGuy says, just create a new folder "mods" there. Your wrong path: C:\Users\aron\Saved Games\DCS.openbeta\Aircraft The correct path: C:\Users\aron\Saved Games\DCS.openbeta\mods\aircraft\ Then inside of that, extract the C-130 mods in its own subfolder so that it looks something like this:

Das könnte vielleicht daran liegen, dass die deutschen Texte länger sind als die englischen; soweit ich weiß, nutzt die deutsche Version einer Mission "einfach nur" andere Audiodateien und andere Untertitel, nutzt aber ansonsten die gleichen Trigger. @EagleEye könnt ihr Übersetzer euch das anschauen? Klasse, wenn das reproduzierbar ist, dann sollte es leicht einzugrenzen sein. Ich schaue, ob das auch in der englischen Version auftritt (ich habe DCS nur auf Englisch installiert), dann sollte das ein einfacher Fix sein (kann dann aber trotzdem dauern, bis das gefixed wird). Ich sage auf jeden Fall Bescheid (und wenn nicht, hätte ich das im allgemeinen Chaos des neuen Jahres (lahme Ausrede, ich weiß ) vergessen, dann einfach die Tage nochmal nachhaken ).

I watched your track, but not all the way to the end (there's no way to know ahead of time how long the track is, and the random flying around didn't seem particularly noteworthy). That region has some mountains and the mission has some wind set. I'm pretty sure that DCS simulates some kind of turbulence close to the ground, to include turbulence in and near mountains. This particular mission doesn't have any turbulence set, but that's no guarantee that DCS doesn't simulate turbulent air according to the general wind settings and the ground. In a clean test mission over the Black Sea with no wind whatsoever and 20 miles from anything resembling a mountain and using fast forward, I did manage to observe the aircraft rolling right and then left a little. Even so I couldn't tell if maybe that was caused by the tiniest of inputs on my rudder pedals or the stick. For what it's worth, I flew a couple of hours in the C-101EB today and that aircraft is also impossible to trim perfectly. It requires very regular tiny inputs to keep it flying within the intended parameters. So in the A-10C, while there might be an issue with roll reversing without any input, it's still relatively minor, and more importantly we do have an autopilot that helps us in the A-10C. Barring real world flying experience, compared to other simulated aircraft the A-10C flight model feels pretty solid to me, and the fact it's not flying on rails and requires regular inputs makes it feel very much alive from my point of view. In order to call this behavior a bug, we'd need very solid evidence that there's something funky going on, which would probably require disconnecting all analog devices, removing factors like wind, and then showing that the aircraft is still exhibiting a roll-reversal tendency without any inputs and without any notable changes in attitude (as in: constant speed, constant altitude). As for the sensitivity of trim inputs, yeah, it would be nice if trim could be applied in finer increments. But I can't tell if the DCS A-10C is simply replicating real life behavior (which Snoopy suggests is the case) or if the real aircraft is easier to trim out well. Either way, the autopilot is a great tool to help us, unless we're changing both direction and altitude at the same time.

Just to clarify, in a steep dive with engines idle, they sometimes flame out. To avoid the issue, keep both throttles above idle (like at 25% of their full range of motion or thereabouts, or more).

It looks as if in both cases engine RPMs drop down to very low values, leading to both engine generators cutting out for a short moment, which in turn messes up your INS and then leads to follow-on faults like SAS and EAC cutting out as well. I had a dual engine flameout some years ago during a steep dive with engines idle. As far as I'm aware, that shouldn't happen and I haven't managed to reproduce it on purpose. However, I made it my personal SOP to always have the engines a fair bit above idle during steep descents. For whatever reason, that keeps them from spooling down and eventually flaming out altogether. Edit: And thanks for the videos, track and TacView, these are extremely helpful!

A track is a recording of all player inputs that can be replayed in real time within DCS. At the end of each mission, you get the debriefing dialog that allows you to "Save Track". The log files aren't tracks. Please keep such a track as short as possible, and don't use time acceleration during the mission that you use for the track. I thought it was very obvious what Bignewy meant by "please remove all custom mods and run a repair or verify if steam". "Vanilla", as far as I understand it, means something along the lines of "original and unmodified base game", and "Vanilla install" was referring to an installation that's clean and unmodified; it did not refer to the process of uninstalling and reinstalling all of DCS. In order to ensure you have a vanilla install, please remove all custom mods and run a repair or verify if steam. Can you use Google Drive or some other free service to upload the track and post the link here? Be sure to allow anyone with the link access. I'm about as far from an expert on the F-16 as it gets and don't know how sensitive the INS alignment is to control surface deflection. However, with the force sensing sidestick of the real aircraft, it would probably be rather rare for pilots to enter any accidental control surface inputs before the alignment is finished. So if this kind of input screws up the alignment, then don't input anything.

Klingt auf jeden Fall interessant, was du schilderst, und wäre für Einsteiger sicherlich sehr hilfreich. Änderungen an der Ordnerstruktur sind selten, aber sie kommen vor; früher gab es Mods\Aircrafts, das wurde dann in Mods\Aircraft (ohne das falsche Plural-s) umbenannt. Viel wichtiger: Früher lagen die meisten Dateien im DCS-Installationsverzeichnis, erst später ist ED dazu übergegangen, mehr und mehr Dateien nach Gespeicherte Spiele\DCS zu legen und ein virtuelles Dateisystem aufzubauen, in dem manche vorhandenen Dateien einfach in Gespeicherte Spiele nochmal vorkommen und damit Präzedenz haben können. Ältere Tutorials funktionierten dann entsprechend nicht mehr und die User mussten sich das selbst zusammenreimen. Oder manche Youtuber haben bei neuen Modulen bestimmte Vorgänge erklärt, die sich dann im Early Access geändert haben, aber noch lange danach fragen User, warum es nicht so funktioniert wie in dem Video. Deshalb würde es mich halt besonders freuen, wenn man so eine Aufstellung nicht als einmalige Arbeit begreift, sondern am Ball bleibt und Änderungen in die Übersicht selbst einpflegt - wenn auf Seite 5 ein Update oder eine Korrektur gepostet wird, haben User vielleicht schon Stunden verschwendet, weil sie gar nicht auf die Idee kamen, im Verlauf der Diskussion nach Updates zu suchen. Aber nur zum Klarstellen: Ich habe hier im Forum genau so viel und genau so wenig zu sagen wie alle anderen auch. Will nur ein paar Denkanstöße liefern, was man aus meiner Sicht berücksichtigen sollte. Stimmt schon, aber da wir hier Hobbysimmer sind, passt das doch ganz gut. Es gibt eine ganze Menge Wortschöpfungen hier, über die ich auch nur den Kopf schüttele. Manche Leute werfen vollkommen unnötig mit Abkürzungen um sich, andere schreiben am laufenden Band feststehende Begriffe falsch - die Liste ließe sich lange fortsetzen. Ich fand halt nur, dass gerade das A-10-Pit eher zu den recht eindeutigen Bezeichnungen gehört.

Je nachdem ob es in DCS schon ein fertiges Profil für deine konkrete Hardware gibt oder nicht kann alles schon "out of the box" korrekt belegt sein, oder DCS sieht einfach nur ein Gerät mit Buttons und Achsen. In letzterem Fall kann es immer mal vorkommen, dass du eine Achse umkehren musst, damit sie korrekt funktioniert.

Entschuldigen Sie, Sir - wenn der VP so ein VIP ist, sollten wir dann nicht die PK wegen der PR im WC abhalten? Dann sagt die MP zum KGB LMAA. Adrian Cronauer, Good Morning Vietnam (frei Schnauze aus dem Gedächtnis zitiert von Yurgon ) Das gesagt habend, die A-10 ist, zumal in diesem Forum, ein feststehender Begriff, und "Pit" als Kurzform von "Cockpit" sehr verbreitet, was sich dem Herrn Anno Domini/Analog Digital/Abteilungsdirektor/Actice Directory/Lufttüchtigkeitsanweisung/Andorra/Antidepressivum/Außendienst/Autobahndreieck/außer Dienst durchaus mit kurzer Recherche hätte erschließen können. Vielen Dank für das Video! Ist das ein Joystick-Analyzer von Thrustmaster? Dann sieht DCS ja vermutlich die gleichen komischen Werte. Ich hatte dieses TQS noch nie in der Hand, aber die meisten nagelneuen Joysticks und Schubregler müssen vor der Benutzung einmal kalibriert werden. Manche Hardware-Hersteller nutzen die Windows-Kalibrierung für Joysticks, andere erfordern ausdrücklich die eigene Software dafür. Hast du die Kalibrierung entsprechend der Anweisungen vom Hardware-Hersteller schon durchgeführt?

Excellent, thanks for the update! I've amended the report.

Soweit ich weiß nutzt der Server den gleichen Branch wie der Client, also @release oder @openbeta.

Sorry for the late response. I didn't watch the track because you said the issue only appeared at the end of a long mission. Do you remember if the "UHF" indication on the DED remained in inverted video like in your screenshot during the entire time that the problem persisted? So far I haven't received any feedback on the bug report, but if the "UHF" remains inverted, that would point to the outgoing transmission somehow being stuck, and thus blocking any further comms from going out. That would certainly be a very interesting aspect to add to the internal report.

Absolutely. I'm just referring to the use of the in-game, AI JTAC. I use LSS so rarely, for me it would be far from a deal breaker if all aircraft were on the same laser code. And I don't think I've ever been in an engagement where LSS and target illumination by different sources would have happend sufficiently close to one another in both time and space to actually matter. If we ever use a JTAC, we definitely need to stop lobbing missile at everything we see. These are not Apaches and it would be much less likely for two engagements to happen simultaneously in the same area. In our Hornet missions I think we all kept the preset laser code, whichever that might have been, and very rarely ran into any issues. Yeah, would be nice. But like I said, the mission can tell the players which code to set. You as the mission designer know ahead of time whether or not an AI JTAC will be used, you define the JTAC's laser code and you can make sure all players respect that. And of course players can choose to ignore the JTAC and self lase or buddy lase, because all this tedious button-pressing with ground-lase is a bit annoying and it's hard to get it right ("IN", "CONTACT", "LASER ON"... I know how I'd execute it with human players, but I don't recall how the DCS JTAC does it). Option 1, use the DCS JTAC and simply ignore any ground lase request. Option 2, set the DCS JTAC to not use lasing. Option 3, set all laser guided weapons to the same code. If you really want to use the DCS JTAC, the laser code issue is a very minor obstacle.

In the context of the F-16-switchology discussion, I'd say that's not all that relevant; as TobiasA already pointed out, CAS isn't actually about flying around and looking for targets. These targets have already been spotted and identified and the aircrews are now guided onto them through a process that typically involves a set of coordinates. Which, in turn, means pilots won't be required to look around and somehow get their sensors on a target of opportunity, and instead most likely create a waypoint, slave and slew sensors and then refine targeting until everyone is sure they're targeting the right thing. What you're describing sounds more like a killbox in which flights are free to engage every object that meets certain criteria (military vehicle, tracked vehicle, armed vehicle, any vehicle whatsoever - that's of course a matter or ROEs and SPINs), which is what the highway of hell in ODS would have looked like, and likely other operations since then. In terms of the actual targeting process and the switchology involved, I believe this is still very different from CAS.

Having done exactly this numerous times, I don't really see any incentive to use the AI JTAC in multiplayer. Scripting a laser that's triggered by the F10 radio menu is about as immersive as the AI JTAC, when you contrast either option to a human player acting as JTAC. And of course there's always the workaround that a mission tells players "Set laser code 1521!" and then all the players set the exact same laser code and the AI JTAC will be set to use that same code as well. There won't be any need to deconflict different weapons with the AI JTAC anyway, and TBH, deconflicting laser guided weapons by laser code is something that I believe I have never, ever needed in years of DCS multiplayer. It's still a good habit to set different laser codes on different aircraft, but in terms of immersion, having the same code on all aircraft is not that bad IMO.

Would be nice to have, but my personal preference would be a halfway decent ATC, then a halfway decent JTAC, and then much further down the line the option for a fighter-to-fighter brief. The latter is like the icing on the cake, whereas ATC is absolutely essential for a flight sim and I'm a bit curious why that is taking so long (not saying it's not an enormous undertaking - but I'd give the Apache back and wait for it for another 10 years if we could get a decent ATC instead. And I LOVE the Apache). The current implementation of JTAC comms is also not that great and in several regards outright wrong (no correlation/PID whatsoever, no routing and safety of flight, no AO update, JTAC passing laser code to the CAS flight instead of the other way around, to name just a few items). With F2F briefs, it would be cool if the AI could pass them to players when the AI leads a flight, and then the other way around when the player leads a flight. But this kind of thing usually makes the most sense in MP and for the time being I'm quite happy seeing it only there, or in hand-crafted, well-scripted missions with prerecorded voice-overs.

Yes, like I said I mostly agree that the flight should be given as much liberty as possible. On the other hand, I can certainly imagine a scenario where, say, a series of gun runs is requested, which would then be followed up by actions on the ground, in which case "shooter-shooter guns, 30 seconds" might be what the ground force commanders intends to use, the JTAC relays, and the pilot complies with (unless there are good reasons for the pilot not to comply). It's my understanding that neither side can order the other to do something, they can only request, acknowledge, deny or clear actions, but never order them. Which is why it makes the most sense not to micromanage one another and instead leave every bit of the execution that isn't strictly necessary to the other side (to the flight lead, in this discussion). My point is that when the JTAC asks for a specific tactic or formation, that'll probably happen out of such a necessity, and unless the flight lead has very good reasons to deny the request, they should just follow through, or at least recommend a preferred action instead. Yeah, that's a great example why the flight lead might deny a shooter-shooter. I think we're at least 95% in agreement here anyway. Oh yeah of course! Again I'm just saying when the JTAC feels that a specific type or direction of egress is called for, they can certainly request it to ensure safety of flight throughout the entire vul period. Then we have to agree to disagree. Holding 8 miles east of the target, a flight with good SA could engage the target with Mavericks in a manner of seconds (I assume that a tracking range of, say, 5 miles would be realistic and in DCS we enjoy a bit more liberty with the D model consistently tracking at 7 miles and beyond). I understand that unguided weapons are typically employed from an offset attack with about a 90° turn into the target using Z-diagrams. I also understand that slaving Mavericks to the TGP apparently is more of a DCS-ism and not a procedure that pilots routinely train to, at least according to info I've gathered here on the forum over the course of years. It just doesn't make a whole lot of sense to me to fly offset from the target for several miles, then turn hot onto a short final at circa 45° to 90° offset from the direct line from IP to target. And yeah, a final attack heading given as cardinal direction allows for a 90° cone which would allow for a faster turn onto final. But why accept this delay when the attacking aircraft could just track the target from maximum range in a straight run-in, making good use of the aircraft's sensors and weapons? It's always hard to find good info in this level of detail. But all the sources I could find (which all come from the DCS- or BMS-context) say the same you just told me. Looks like I'll have to revisit my personal procedure and probably rewrite a chapter or two in our squad's documents. Holy cow, you're right! Again, it's kinda hard to find good references, and again all the ones I checked say the same. In my defense, I didn't write the part in our squad's SOP that got me the wrong understanding. Thanks for clearing that up! And that's the cool thing about these kinds of discussions, there's always so much more to learn. Likewise.

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!