Yurgon

This doesn't seem to belong to the built-in DCS kneeboard for the A-10C II module. I recall such a kneeboard from a campaign. You should probably find the author of the mission or check your kneeboard mods in order to get this fixed at the source.

Some parking spots have caused that in the past, for instance at Ramat David in the Syria map if I recall correctly. Wheel chocks should obviously prevent this, so a reproducible mission setting would be great. Other than that, step 1 of bug hunting is to disable all mods.

Meinst du vielleicht MiG-29 oder Su-27? Egal welche der beiden, die gleichen Waffen wie die F/A-18C sollte keine davon tragen können. Entsprechend kann es durchaus große Unterschiede in der Reichweite der Waffen geben - da müssten wir also im Detail wissen, welche Maschine über welche Waffen verfügt. Return Fire ist das Gegenteil von offensiv. Bei Return Fire muss eine Einheit warten, bis sie beschossen/angegriffen wird, erst danach darf sie Waffen gegen den Angreifer einsetzen - wenn sie denn kann, denn erstmal muss sie ja den laufenden Angriff überleben. Offensiv wäre "Weapons Free". Ja, das sollte möglich sein, und vermutlich gibt es mehrere Wege. Dies wäre einer: Einstellung wie etwa die ROE, etwa "Weapons Free" oder "Return Fire", sollte man als getriggerte Aktionen anlegen können. Und dann kann man eine bewegliche Triggerzone an die gewünschte Einheit binden und prüfen, ob sich bestimmte feindliche Einheiten, Gruppen, Teile von Gruppen oder Teile der feindlichen Koalition innerhalb der beweglichen Triggerzone befinden, um dann über die getriggerten Aktionen einen anderen Satz ROE auszulösen. Oder man kann natürlich auch ganz andere Konditionen verwenden, also z.B. die vergangene Zeit seit Missionsstart, oder bestimmte Aktionen des Spielers - da sind deiner Fantasie ja kaum Grenzen gesetzt. Achso, du bist ja neu hier, sonst hätte dir bestimmt mal wer gesagt, dass ein Track immer eine große Hilfe ist, um solche Fragen viel direkter beantworten zu können, weil sich dann ganz viele Gegenfragen direkt beantworten lassen...

Klar, solange es um die A-10C geht. Sorry, Mi-24 habe ich vielleicht 10 Stunden geflogen, und das meiste davon Freeflight ohne Waffeneinsatz (und davon mindestens 30 Minuten ohne Ventilator - ich weiß, ich weiß, Schande über mich! ). Da kenne ich mich leider echt 0 aus.

Nein, ich kenne keine Möglichkeit, Tracks zu bearbeiten. Wenn es gar nicht anders geht, nehmen wir natürlich auch 2-Stunden-Tracks, wo das Problem bei 1:59 aufgetreten ist, aber es ist schon eher unwahrscheinlich, dass so ein Track bis zum Ende korrekt wiedergegeben wird oder dass sich jemand 2 Stunden Zeit dafür nimmt, den Track anzuschauen und das Zeitraffer-Problem zu vermeiden. Wenn man zumindest eine Idee oder Theorie hat, was das Problem ausgelöst haben könnte, ist es immer gut, die Situation so nackt wie möglich im Missionseditor nachzustellen. Gerade Fragen zur Bedienung von Waffen, Systemen und Sensoren hängen ja meist nicht davon ab, was vorher alles passiert ist, da kann man also super ein Spielerflugzeug, einen Wegpunkt sowie ein Ziel platzieren, das Problem dann im Flug zeigen und danach den Track speichern. Wer das macht, hat damit natürlich einigen Aufwand und muss Zeit investieren. Auf der anderen Seite kann man das Problem dann sehr gut eingrenzen und vielleicht sogar beantworten, bevor man überhaupt die anderen fragt - und damit hat man einen positiven Lerneffekt. Schwieriger wird es, wenn beispielsweise das Flugverhalten plötzlich komisch wird oder Systeme ausfallen oder Fehler auftreten, für die man keine Erklärung hat. Das kann eine Folge von Feindbeschuss sein, es kann (in einigen Flugzeugen) an zu hoher oder zu niedriger Triebwerksdrehzahl liegen, Vereisung könnte in Frage kommen, es könnte sich um zufällige oder getriggerte Fehler handeln oder natürlich um einen Bug in DCS oder eine Unverträglichkeit mit einem Mod, den man vor Monaten installiert und dann vergessen hat. Diese Probleme sind viel schwieriger einzugrenzen, aber auch hier kann ein Track noch eine große Hilfe sein, denn Tracks kann man einfach in .miz umbenennen und im Missionseditor öffnen. Selbst wenn das Replay nicht taugt, lassen sich viele wesentliche Umgebungsinformationen relativ leicht aus einem Track ziehen, damit man zumindest schon mal einige mögliche Ursachen ausschließen oder andere näher in Betracht ziehen kann. Manche Leute haben schon alles fertig, um Videos aufzunehmen. Videos sind auch gut, aber Tracks sind in der Regel besser. Gerade bei so Problemen spät im Flug ist aber natürlich ein Video Gold wert, weil wir dann das Problem live und in Farbe sehen und nicht den ganzen Track abspielen müssen. Wenn es den Track dazu gibt, umso besser, weil man dann die ganz konkrete Mission auf Details prüfen kann. Aber grundsätzlich gilt halt: Hat man nicht ohnehin ein Problem ganz früh in der Mission, ist es immer brillant, das gleiche Problem mit Hilfe des Missionseditors in einer nackten Mission nachzustellen und davon dann einen kurzen Track zu posten. Grundlegenden Umgang mit dem Missionseditor kann ich nur allen DCS-Spielern wärmstens empfehlen, das hilft weit über das Erstellen kurzer Tracks hinaus.

Das geht ja auf Zufallswerte zurück. Wird da nicht ein Random-Seed verwendet? Zufallswerte betreffen ja auch Trigger, die zufällige Aktionen auslösen können, und um hier die Reproduzierbarkeit von Tracks zu gewährleisten, wird meines Wissens ein Random-Seed im Track gespeichert, damit bei der Wiedergabe exakt die gleichen Zufallswerte herauskommen wie beim ursprünglichen Lauf der Mission. Da wäre es ja naheliegend, dass zufällige Turbulenzen und Böen den gleichen Seed für den Zufallszahlengenerator verwenden und die Böen entsprechend auch in der Wiedergabe eines Tracks identisch sind. Ob dem so ist weiß ich aber nicht.

Meine Vermutung ist, dass Track-Aufzeichnungen sowie Track-Wiedergaben im Allgemeinen sehr gut funktionieren, wenn das System und insbesondere CPU und RAM nicht am Limit sind. Wenn es irgendwo eng wird und die FPS in den Keller fallen, kann man sich vermutlich leicht vorstellen, dass schon beim Aufzeichnen aller Eingaben kleine Fehler passieren können, und wenn man sich später die Wiedergabe anschaut, können diese minimalen Abweichungen dazu führen, dass die Wiedergabe scheinbar gar nichts mehr damit zu tun hat, was man vorher erlebt hat. Wie schon gesagt wurde kann Zeitraffer das Problem drastisch verschärfen. Beim Testen von Missionen nutze ich oft Replays und darin Zeitraffer, und selbst komplexe Missionen laufen manchmal 30 Minuten lang synchron mit dem, was ich vorher erlebt habe, sodass ich an der richtigen Stelle die Kontrolle übernehmen und eine bestimmte Situation erneut testen kann - und dabei habe ich wahrlich kein High-End-System. Der Grund, dass wir immer und immer wieder nach kurzen (!) Tracks fragen, ist, dass das Frage-und-Antwort-Spiel einfach brutal lange dauert, wenn jemand lang und breit ein Problem schildert und dazu sagt "ich habe aber alles richtig gemacht", und nach 3 Tagen hin und her stellt sich raus, der Spieler hat irgendeinen Schalter vergessen oder ein System grundlegend falsch verstanden. Das hätte man im Track nach 1 Minute gesehen. Und zweitens bieten uns Tracks einen Sprung direkt in die Situation: welches Flugzeug genau (wir haben allein 3 Varianten der A-10, mehrere Varianten bestimmter Warbirds, bis vor kurzem gab es 3 Varianten der Gazelle), welche Zuladung, welche Bedingungen (Status des Triebwerks, im Missionseditor festgelegte Systemausfälle, ...), welche Flughöhe, Wind, Luftdruck, Wolken, Außentemperatur... leider sind die allermeisten Forenteilnehmer gnadenlos überfordert, wenigstens einen Bruchteil der relevanten Informationen zu liefern, wenn sie ein Problem oder einen Fehler melden oder Hilfe suchen. (*) Ein Track kann viele der Fragen direkt beantworten. (*) Und das Forum ist noch der pure Himmel im Vergleich zu Discord. Und weil wir alle wissen, dass die Wiedergabe von Tracks ungenau ist und im schlimmsten Fall schon beim Start auseinanderdriftet, ist es so wichtig, dass man die zugrunde liegende Situation reproduziert und dann einen kurzen Track erzeugt, der nur exakt das geschilderte Problem zeigt. Positiver Nebeneffekt: Beim Versuch, ein Problem zu reproduzieren, findet man oft raus, was das Problem war. Einige meiner besten Fehlerberichte sind die, die ich nie abgeschickt habe, weil mir beim Reproduzieren klar wurde, was mein Fehler war.

Betrifft vermutlich nur eine recht kleine Zahl an Benutzern, aber manchmal ist eine Accountsperre komplett willkürlich oder basiert auf automatisierten Kriterien, und dann kann der Schaden schon ziemlich groß sein, wenn man nicht darauf vorbereitet ist, auch andere Dienste nutzen zu können, und wenn die sperrenden Dienste außerdem erstaunlich schwer zu erreichen sind, um das Problem zu klären. https://www.heise.de/hintergrund/Automatisierte-Scans-Microsoft-sperrt-Kunden-unangekuendigt-fuer-immer-aus-7324608.html https://www.rnd.de/panorama/google-account-von-vater-gesperrt-missbrauchsverdacht-wegen-intimfotos-des-sohns-fuer-arzt-DWWNWFUAH5G5LNQVO5BJPCRQG4.html https://www.heise.de/news/Proteste-gegen-Sperrung-von-Fotos-stillender-Muetter-auf-Facebook-192904.html Betreibt man seinen PC ohne Microsoft-Account, dann kann man zumindest noch DCS spielen, auch wenn andere Dienste vielleicht aus welchen Gründen auch immer gerade gesperrt sind.

@BIGNEWY @NineLine can you move this thread? Thanks.

A short track would go a long way to figure this thing out.

What's your SRS version? Support for the ARC-210 was added when the A-10C II module came out. The A-10C II ARC-210 works fine here; it should be "Radio 1" in SRS, just like the old ARC-186 used to be.

Ich werd's wieder so halten wie beim Umstieg von Windows 7 auf Windows 10: Wenn ich mir einen neuen Rechner einrichte, käme jetzt ganz sicher Windows 11 drauf. Auf dem aktuellen Rechner bleibe ich bei Windows 10, bis Windows 11 entweder wichtige Features bekommt, die ich brauche/haben will (beispielsweise ein neues DirectX, das in Spielen einen Vorteil bringt) oder bis der Support für Windows 10 endet.

Passend zum Thread nochmal in aller gebotenen Kürze, bezogen auf die A-10C (beide Versionen in DCS): Es gibt immer nur einen Sensor of Interest (SOI). Den kann man mit dem Slew-Cursor manipulieren. Es gibt immer nur einen Sensor Point of Interest (SPI). Das HOTAS-Kommando "Make SPI" (TMS Forward Long) setzt den SOI als SPI-Generator. Das heißt, von diesem Zeitpunkt an generiert dieser Sensor den SPI. Manipuliert man diesen Sensor, der gerade SPI-Generator ist (TGP slewen, HUD Cursor slewen, TAD-Objekt hooken, HMCS-Objekt hooken, anderen Steuerpunkt auswählen, ...), dann aktualisiert das Flugzeug direkt und sofort den SPI. Wenn man einen anderen Sensor zum SOI macht, ändert das nicht den SPI. In der unteren linken Ecke vom HUD wird immer angezeigt, welcher Sensor gerade den SPI generiert. Für CCRP-Angriffe und beim Übertragen von Kontakten per Datalink wird immer der SPI genutzt. Hat man dieses Konzept einmal verinnerlicht, ist es super mächtig und es wird klar, dass fast immer unterschiedliche Wege zum gleichen Ziel führen.

Reading the question again, it sounds like you are right. In that case, option select buttons in the A-10C are the rows and lines of buttons around the 2 multifunction color displays (5 buttons on every side of each display). Keeping any of these pressed for too long will lead to the RIGHT/LEFT MFCD STUCK KEY message popping up. That should hopefully answer the question fully.

So to double-check: at certain angles, the TGP doesn't track targets, correct? And are those moving targets, or is it also unable to track stationary objects? In those cases, does it show "M" for "masked"? icemaker asked this question already and it seems it's pretty important. Can you at least post a screenshot of the TGP screen when this happens, and can you please also post a screenshot showing the HUD after you used the "Make SPI" HOTAS command on the TGP? Even when the TGP is masked and shows the "M" indication, that doesn't (shouldn't, at least) prevent it from generating the SPI, and using the HOTAS command "Make SPI" on the TGP should still place the SPI where the TGP line of sight intersects the ground, and the HUD indication in the lower left corner should still switch over to "SPI", and the TAD and HMCS should show the SPI symbol (the 3-layered wedding cake symbol) right where the TGP is looking (and the HMCS should also show the TGP field of view box around the SPI symbol, if my memory doesn't fail me). I'm trying to figure out if there's something broken with DCS, or in your specific DCS installation, or if it's user error. Right now it sounds like you might not fully understand what the SPI is, how sensors generate it, and what the difference is between tracking an object and creating a SPI. So, once again, if you can provide us with a complete and detailed description of the actions you take regarding HOTAS commands and the SOI, and if you can illustrate this with screenshots or a (short!) track, we can probably give you very specific advice within one response. Right now, though, we have to ask tons of questions and do a lot of guesswork, meaning this could drag on for another week.

Option Select Button

In einem deutsch lokalisierten Windows ist es genaugenommen C:\Benutzer\{Benutzername}\DCS Aber stimmt, C:\Users oder C:\Benutzer ist der richtige Pfad - normalerweise schaue ich sowas um sicherzugehen extra nochmal nach, hab aber gerade nur ein Ubuntu-Notebook am Start.

"Make SPI" doesn't do much to the other sensors. Can you confirm that the HUD shows "TGP" in the lower left corner after you've pressed "Make SPI" with TGP as SOI? Can you confirm that the TGP retains POINT or AREA track (as commanded) and that the TGP keeps looking at the proper object? Can you confirm that the HUD keeps showing "TGP" in the lower left corner throughout these issues that the thread is about? And do I understand correctly that after the steps you described above you then follow it up with the "Slave All to SPI" HOTAS command, but now the Maverick (as opposed to the TGP) isn't always able to track the SPI? If the answer to all of the above is yes, then this sounds like a simple case of Maverick gimbal limits. If the answer to any of the above is not "yes", I can only reiterate that we need more information and preferably a track.

Das wäre ganz besonders: C:\{Dein Windows Benutzername}\Gespeicherte Spiele\DCS oder C:\{Dein Windows Benutzername}\Gespeicherte Spiele\DCS.openbeta Es kann sein, dass deine USB-Geräte neue IDs bekommen; das kann man in DCS mit Speichern und Laden von Profilen lösen oder indem man die Dateien in Gespeicherte Spiele\DCS\Cinfig\Input (wenn ich mich gerade richtig erinnere) umbenennt.

Let me rephrase then: As far as I'm aware, masking does not prevent generating a valid Sensor Point of Interest. So with the "M" indication for masking, the SPI Generator as indicated in the lower left corner of the HUD should not change away from "TGP" to, say, "STPT". Sure, the TGP may no longer track a moving target, but that's not the problem OP described.

Ah, super! Das ist völlig an mir vorbeigegangen, aber so kann Peterik das Problem ja sehr gezielt angehen.

Not sure if there is a maximum range, but once the TGP (not TPOD, this ain't no Hornet) is slewed to the horizon and above it, it's obviously impossible to calculate a point on planet earth where the TGP line of sight intersects the ground, making it impossible to designate the TGP as SPI Generator. Otherwise, I'm not quite sure what you mean. I'm not aware of any lateral or longitudinal angle limit that would prevent the TGP from generating a SPI. So when you try to make the TGP SPI Generator with the Make SPI HOTAS command, does the lower left corner of the HUD not switch to "TGP"? If you could post a track and describe exactly what you expect to happen and what happens instead, that would be a big help to clear things up.

Die DCS-Reparatur wäre mein erster Tipp gewesen. Tipp #2: benenne deinen Ordner Gespeicherte Spiele\DCS.openbeta um, nimm beim nächsten DCS-Start nur die nötigsten Einstellungen vor und schau ob das Problem weiterhin auftritt. So oder so kannst du danach Gespeicherte Spiele\DCS.openbeta löschen und deinen umbenannten Ordner wieder zurückbenennen. Tendenziell würde ich aber auch mal einen Blick in den Windows Task Manager werfen, vielleicht ist es ja etwas außerhalb von DCS, das dir dazwischenfunkt. Vielleicht dein Antivirus?

That's an interesting thought, and it actually sounds quite plausible. On the other hand, from a low altitude release the weapon would carry the kinetic energy it was given by the launch platform, and an optimal release profile should pretty much allow it to reach the target with this energy. With a short bomb fall time from a low altitude drop, I assume there's a chance the bomb will run itself out of energy before reaching the target - then again, low altitude LGB releases aren't usually recommended anyway. I have a much easier time imagining a high altitude release where the bomb runs out of energy because its flight path deviates too much from a ballistic path. But from a level release, the seeker wouldn't even see the designation until the bomb is already quite a bit nose down on its ballistic path - so maybe the issue is indeed more manifest in a low altitude level release, where the seeker can pick up the designation right away. So even with a relatively small difference between a ballistic flight path and a direct flight path, this might be enough to run the bomb into the ground short of the target. I'm now more confused than ever.

IIRC the resident SMEs have said for ages that LASTE does a great job of collecting and updating wind information and that pilots basically don't touch the manual wind entry, unless there are very specific circumstances. There was also the question if manually entered wind data does anything at all in the jet; I recall a video (or was it a forum discussion...?) years ago where active pause was used and it was shown that the CCIP pipper does indeed move depending on the manually entered wind data, and in essence manually entered data can and does have an effect on targeting. But as I recall it, the difference between the generally suggested method of calculating wind data from whatever was entered in the ME and the automatically gathered data by LASTE was so minimal that it's just not worth calculating and entering this stuff for every flight.