Jump to content

Yurgon

ED Closed Beta Testers Team
  • Posts

    10252
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Yurgon

  1. 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.
  2. 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).
  3. 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!
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. Excellent, thanks for the update! I've amended the report.
  9. Soweit ich weiß nutzt der Server den gleichen Branch wie der Client, also @release oder @openbeta.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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!
  19. 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.
  20. 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.
  21. 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?
  22. 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.
  23. 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...
  24. 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).
  25. There are a few lighting controls that are non-functional in our DCS A-10C unfortunately. I believe this is one of them.
×
×
  • Create New...