Wychmaster

The units in DCS are way to accurate with their aim. That doesn't mean that you can not evade their fire. I read in some thread here that they also seem to consider accelerations. So some random pushing and pulling on the stick should cause them to aim way off. Have not tested it my self so far, but maybe I ll try it today. If you have no issues, you have probably adapted.

IIRC raddest means "radar destroyed". Autonm means, as you mentioned yourself, that the sams are in autonomous mode and act like the default DCS SAMs. I have not worked with connection nodes but it seems that you used them cause in the documentation it is written that if a connection node is destroyed or looses power, all SAMs attached to it loose contact to the IADS and can either be turned off or go into autonomous mode.

Als jemand der ein wenig Ahnung von der Materie hat, würde ich gerne ein wenig zur Aufklärung beitragen, da hier an einigen Ecken offenbar ein wenig Sachen miteinander vermischt werden. Simpel runter gebrochen sind Vulkan, DirectX und OpenGL für den Programmierer "nur" ein Satz an Funktionen die eine bestimmte Aufgabe zum Erstellen von Bildern erfüllen. Wie diese Funktionen implementiert sind, hängt meines Wissens nach vom Treiber ab, also von dem Hersteller eurer Grafikkarte. Das heißt, eine gewisse Funktion kann auf ner Nvidia Karte rasend schnell sein und auf einer AMD Karte eine lahme Schnecke. Wenn Vulkan selbst an einer Ecke also langsam ist, hängt das eher mit der Umsetzung des Treibers als mit Vulkan selbst zusammen. Jetzt kommt hinzu, dass einzelne Funktionen der API nicht auf magische Weise komplexe Szenen erzeugen, sondern dass der Programmierer, der die Grafik-Engine schreibt, die Funktionen auch sinnvoll kombinieren muss (dass ist sehr komplex). Vulkan hat den Vorteil, dass es im Gegensatz zu OpenGL mehr direkte Kontrolle über die GPU zur Verfügung stellt. Aber mit dieser zusätzlichen Kontrolle muss ich als Programmierer auch was anfangen können. Dazu brauche ich aber erst einmal ein gutes Verständnis darüber wie alles zusammenspielt. Ob Vulkan jetzt schneller ist hängt also maßgeblich davon ab wie gut die Grafik-Engine geschrieben ist. Ich kann auch in einem Porsche nicht sonderlich schnell fahren wenn ich nicht weiß wie ich den Gang wechsle. Es stimmt zwar das ein Vorteil von Vulkan Multi-Threading Unterstützung ist, aber ich würde mir da jetzt nicht den heiligen Gral drunter vorstellen, denn im Grunde sollte das für die Performance so gut wie keine Relevanz haben. Der Grund hierfür ist, dass eine gute Grafik-Engine versucht, die Kommunikation zwischen GPU und CPU minimal zu halten. Wen das genauere interessiert, der kann ja mal nach "OpenGL AZDO" googeln. AZDO steht für "Approaching zero driver overhead" und beschreibt eine Reihe von Techniken, die versucht die Anzahl der OpenGL Funktionsaufrufe zu minimieren bzw. zu optimieren, denn die bringen das Problem mit sich, dass GPU und CPU immer wieder miteinander synchronisiert werden müssen und aufeinander warten was zu übermäßigem Leerlauf führt. Zudem braucht jeder Funktionsaufruf CPU Leistung. Lange Rede kurzer Sinn, wenn ich meine Grafik Engine hoch optimiert habe, reicht eine CPU zumeist mehr als aus um das Rendern zu verwalten. Nagelt mich nicht auf die genaue Zahl fest, aber ich habe irgendwo mal gelesen, dass sich mit Vulkan im Gegensatz zu einer hoch optimierten OpenGL Engine noch mal 10% mehr raus kitzeln ließen (Also kein riesen Sprung). Das ist allerdings schon etwas her und wird vermutlich mit wachsender API Erfahrung noch besser werden. Was bedeutet das nun für DCS? Ich habe von den Mods (glaube es war NineLine) schon den ein oder anderen Kommentar gelesen, dass man von Vulkan selbst nicht zu viel erwarten sollte, da es nur ein Werkzeug in einer Werkzeugkiste ist. Das Hauptproblem liegt sicherlich im Alter des gesamten Codes und das dieser ursprünglich nicht für Multi-Prozessor Setups ausgelegt war (das ist völlig unabhängig von der Grafik-API). Im Grunde wäre sicher ein Rewrite am Besten für die Performance, ist aber angesichts der großen Codebase einfach nicht machbar. Also muss halt Teil für Teil angepasst werden und das vermutlich mehrfach, was dauert und nur kleine Leistungsschübe bringt. Also erwartet nicht den großen Wurf über Nacht. Vermutlich ist einer der Vorteile des kommenden Vulkan-Updates, dass einige Code-Teile gleich mit überarbeitet werden. Die Multi-Threading Fähigkeit von Vulkan kann sicherlich dabei helfen, da ich mir keine Gedanken darüber machen muss, wie ich dem Prozessor der mit der GPU kommuniziert die nötigen Daten zuspiele, aber wie zuvor gesagt, das sollte eigentlich nicht das Hauptproblem sein. Da ich nichts mit dem DCS Code zu tun habe sind das Vermutungen basierend auf meinen eigenen Erfahrungen. Wenn die alte Render-Engine schlecht geschrieben war, kann man auch durchaus auf mehr hoffen.

+1 x 1000

+1

The trick is to create a mission with 2+ helicopters in the air at a sufficient altitude and set the skill level to client. You can immediately hop into the next chopper after the landing

I think it just means that you can't put the units of two sam sites into the same group and try to treat them as two different sam sites. Makes probanly sense when looking at individual ships that are in the same group.

This is actually the (bugged???) pitch AP channel. Turn it off and this behavior disappears. I fly always with all AP channels turned off because at least for me, it feels that they get in the way more often than they actually help. I have no problems in keeping her steady and in a solid hover without the AP channels, so I don't see a real advantage in most of the AP channels except for keeping a specific heading in level flight. YMMV

CPG: Co-Pilot Gunner TADS: Target Acquisition and Desination System(The Apaches targetting system) TEDAC: no idea what the letters stand for and I am too lazy to google but it is basically an extra MFD (Multi-function display) with fancy controls that only the gunner has in his cockpit CMWS: Common Missile Warning System FCR: Fire Control Radar LRFD: Laser Range Finder/Designator SAL: Okay, this one I had to actually search for myself -> Semi-Active Laser Stick around for a while and in a few weeks all your friends and family know what these terms stand for

I have generated a practice mission for me and my buddies with a shooting range. My assumption was that Bradleys and Strikers could be peneteated by the 30mm, so I used them as targets. I can confirm that shooting from higher ranges does next to nothing to them. At close range I managed to destroy a striker, but I was max 200m away. I can not tell if you can kill a Bradley at close ranges. However, if your armor protection data is correct, I would assume that the 30mm shouldn't have such problems against those vehicles.

Nice demonstration. That aligns perfectly with my autorotation attempts yesterday. With full fuel tanks the recommended 80kmh always lead to a crash (at least if I am the pilot). With around 150kmh and flaring it is manageable. Gave you an upvote on youtube

I don't know how close to reality it was, but in Janes Longbow 2, you had an I-beam instead of ccip cross. The rocket pods could be raised or lowered to hit your designated target as long as it is under the I. So one axis less to worry about for a direct hit, at least if it the real Apache has it. The manual of Longbow 2 can be found online. Quite interesting to read. Covers many questions I have seen in this forum.

My personal hype train just left the station...

This is a long known issue. As far as I know, the AI always uses the perfect target solution with some kind of random factor depending on the chosen skill level.

Either disable the sync or move your controls immediately after hitting the fly button. It's a known problem and also affects other devices:

Seems like Petrovich is labeling bug reports in his spare time. ED already confirmed that he is a bit "trigger happy" No seriously, I have the same Problem in the Hind. I also have it in the F-18, but there I can at least hit the brakes immediately to prevent the worst. In the Hind it usually causes a crash if I forgot to instantly move the collective.

+1 Already requested it

Can confirm that. Had the same problem yesterday after the patch.

Really like vsTerminus' channel. Loved his tutorials for the Mi-8. Find his criticism to be fair and constructive. However, at least my expectation for EA were much worse than what we actually got. I am quite happy with this release and looking forward for the upcoming fixes.

Since helicopters are extremely complex and I havn't been part in the construction of one, I can not tell if my answer is THE answer, just a part of the whole story or has no effect at all. This out of the way: The hind has a govenor that tries to maintain a constant RPM of the rotor. If you measure the RPM directly at the rotor shaft, you get it in relation to the airframe, but the relevant part for lift is the RPM in relation to the air. In a hover, with no wind at all, you could take the ground as reference. Now lets say, the engine govenor is extremely good at is job in maintaining the RPM and you can do whatever you want with your pedals, the RPM remains constant. The hind has a clockwise turning rotor, forcing the airframe to rotate counter clockwise (nose turns left) which is cancelled by the tail rotor. Lets say the maintained RPM is 240. Now you apply right ruder so that the airframe turns with 1 RPM in clockwise direction (like the main rotor). Now your total RPM in relation to the ground (and hence the air) is 241, causing additional lift. If you would do it in the opposite direction it would be 239 and produce less lift. Lets overexaggerate a bit and say you have a extremely powerful, magical tail rotor that can turn your airframe with an RPM of 240 to the left. Neglecting a lot of aerodynamic effects and other physics that prevent this, it would leave you in a state where the rotor has no RPM in relation to the ground/air. Hence it would produce 0 lift and you would just drop out of the air. As I said, I can't tell if this is truly the answer, but at least it makes sense to me

True... I am really good at logic related stuff, but language, wording and using correct terminology has always been my bane...

Thanks for the explanation, but I have a strong background in aerodynamics and simultions, so I knew this already. The whole point of my post was to figure out if ED actually modelled LTE and I triggered it or if there was an alternative explanation. As we figured out, a drop in the RPM is a valid explanation, since I needed more pitch to maintain a hover which finally resulted in me overstressing the engines. Would rather call it: not enough expirience regarding the limitations of the new aircraft type and trying to dogfight another hind at low altitudes between buildings To my understanding (from the video posted by Stuart666) my tail rotor not responding is a "loss of tail rotor effectiveness" (LTE) with VRS being one of the possible reasons for it. If thats not the academic definition, its fine by me. As long as I know what is actually happens, I don't need to know its correct name

So the hard break lowered my rotor RPM, causing me to use maximum pitch to keep my altitude. This left me in a bad state where the RPM couldn't recover due to the high torque and the tail rotor didn't provide enough force to counter the spin. The lowered RPM is an assumption of mine, since I had a fairly light loadout (only 2 gunpods) and was at sea level. In this configuration I don't need maximum pitch to maintain a hover and have quite good rudder turn rates to the right. Only other explanation would be that you loose rudder effectiveness once you turn to fast to the left (as you wrote) and can't recover from it, which would be some kind of LTE or am I missing something?

Can confirm that. I took off in a hot Mi-24. The yaw channel is off by default and I never use the trim nor do I turn on the yaw channel. In fact, most of the time I turn off all channels since there is also some pitch oscillations that occur sometimes and annoys me. However, I made a hard break and got into a left spinning hover. Full right rudder had no effect. Was pretty hard to recover. I couldn't lower the collective because I was close to the ground and accelerating was also hard with buildings all around me. So I had to climb spinning until I finally had enough space to accelerate and lower the collective. So my guess is, that it is either some unintended behavior or that they actually modelled LTE because of tail rotor VRS even though I recall that they said LTE wouldn't be modelled. Would be totally awesome if the "smuggled" it in

I think the salvo size depends on the missile type/launcher you are using, probably like in the Ka-50. There you could select to fire quarter (short), half(medium) and all (long) rockets in a launcher. But you have to keep the trigger pressed to fire the full salvo. Otherwise it stops earlier. So just tipping the trigger will just launch 1 to 3 pairs, depending on how fast you released it.