shagrat

Noticed this, as well. Static is no longer audible when dialing up the volume. Checked if squelch is already active, but the switch position had no effect. I noticed a short "static" noise, when I dialed through the range of the volume knob again, but couldn't pin it to a specific position. It only gave me a small burst of static, when dragging the volume knob with the mouse. (Can't better describe it). - MP mission - realistic comms - Hosted myself - no SRS or other external voice, only discord - no in-game voice chat To reproduce: - battery on - start up APU - mouse drag the Master Volume knob to full - try squelch switch positions to on drag the Master volume knob, set squelch to off again (no static) and mouse drag the Master volume knob, again. Edit: all audio is routed to the headset output, as stereo.

It should ask in the dialogue. There is a checkbox.

To my knowledge Caucasus is the oldest map, with the least modern objects, the least modern effects, terrain mesh etc. Persian Gulf is frequently used by large amounts of users AND has most/all new effects introduced with the 2.5 graphics engine upgrade.

That's great, so I need to care only about alignment and constant speed. That's easier than I thought. Thanks for the info.

Exactly this. They need to move so there is a radar return that is different from the ground that's reflecting the radar, as well. That's why the mode is called Ground Moving Target. The computer can identify radar reflections that move against the returns from the background. Basically a vehicle standing is perfectly notching your radar from any available angle...

As you already did the usual RAM checks/swaps, another helpful thing to look at, is the Windows eventlog, first thing after a BSOD/Reboot. If you look at the timestamps there should be an error pointing to the "abnormal shutdown". Look at events, especially errors shortly before the crash. I once had a weird erratic crash problem and an error code/message and a bit of web search pointed to the PSU (power supply) either being faulty or at its limits. For me it was the old PSUs voltage constantly falling enough to starve the CPU. Another thing (unlikely, as other modules seem to run just fine) could actually be heat issues... Though the crash would reliably happen under load. Anyway, if nothing else pops up it doesn't hurt to check the heat management. Airflow not obstructed,suck-cool and push-warm, as in fans should suck in cool air from one side usually the sides or front, or the (unobstructed!!!) bottom and other fans pushing the hot air out to the back or top. Air flow over individual components e.g. CPU fan not sucking in the hot air exhaust, from the GPU. CPU cooler not blowing hot air on the back of the GPU. Finally omit placing the PC inside a desk or similar, that obstructs the airflow leaving the system. Don't place the back with all the cables too close to a wall or other surface. ...and yes, there are things out there, you cannot imagine. I've seen PCs in a closed (!) cupboard, cables in cable management cover that blocked 80% of the fans in the back (because the cables look so ugly), a PSU fan dying a gruesome death as it had sunken into a fluffy long haired flokati rug...

I think, at least according to the manual this thread mixes two different types. The M229 HE (the 17 lb. enlarged warhead) has the M423 (PD) Point Detonating "on impact" fuze and the M433 (RC) Resistance Capacitance delayed "after impact/hitting" fuze with a fixed delay time. That's basically the big brother of the standard M151 HE. Then there is the M282 MPP mentioned that has a hardened tip optimized for penetrating light armor, bunkers, maybe buildings etc. with a "modified" M423 fixed delay fuze? The not yet(!) implemented M261 MPSM and M255A1 Flechette should use the variable time M439 fuze, that allows the pilot to control the submunition release, similar to the HOF in the CBUs. If I looked it up correct, non of the rockets used on the AH-64D at the simulated period uses a M429 proximity fuze. EDIT: I am pretty curious to see the M255A1 Flechette. From what I've read the timed delay in conjunction with the desired "spread" requires some coordination and precise parameters, to ensure the rockets burst at the planned distance.

Agreed. There's even more. They mostly hit you after you passed the target, which at least I learned during Anti-air training with typical MG on vehicles, you do NOT, as you need a computer calculating lead in realtime to put bullets into a flight path of an aircraft flying away(!) from you. The AI has no issue estimating speed, distance, vector and bullet trajectory to match, a feat a human even with years of training would have learned is wasteful with the ammunition. My guess is, everything that has a "laser" for ranging and "optics" listed as sensor in the vehicle definition, has these in-human sniper abilities. Also for this aspect, there seems to be no impact from the skill setting. That still mostly seems to influence detection times until you are "spotted".

That's what I meant, there were already a lot of smaller updates and improvements over the last years. The rockets are far from useless, especially since with the introduction of the Apache there (finally) was a fix to the incredible resilience of infantry and ED fixed the "armor"/health. Now, rockets work as area weapons, against infantry, they deal noticeable damage to unarmored and lightly armored vehicles, resulting often in kills for unarmored stuff and damage to armored stuff, cumulative and up to the point where a 4-8 rocket barrage has a more realistic impact. This combined with the random critical damage effects, like immobilisation etc. gives us pretty believable effects, without a direct hit. Though to have an instant kill, you still need one or two rockets actually hitting a BTR, M113 or the like, or cumulate enough damage, through multiple rockets landing close. The problem with the hyper accurate BMP gunners is still valid, though. The positive thing is, though it is a painfully slow process, there is work done on these things in the background. Unfortunately these are often introduced silently, without even a notice in the Changelogs. When I tested the infantry path finding a while ago, to check on some issues, not only was the path finding way(!) better, than years ago, but my jaw dropped, like in a Tex Avery cartoon, when I noticed the Infantry in line abreast formation using basic fire and maneuver tactics with bounding overwatch. 8 rifleman group, 4 hold and fire, while 4 advance, then switch. I had tears of joy in my eyes... and it wasn't even one line in the changelog or newsletter. Again, I am aware, there is still lot of room for improvement in the damage modeling and weapon effects, but we have progress and the current results improved considerably, to the point where rockets and aircraft guns(!) now do their job.

Yes, totally agree, I am actually complaining about the non-AAA ground vehicles accuracy since the A-10C. That has been an issue since forever. I have no idea, why we still see BMPs that kill low flying aircraft with a precision burst from their autocannons. T-55/T-72 self defense anti-air MGs that are more accurate than the Zsu-23-2, are crazy. As well as 4-5km ATGM shots against helicopters that differ from MANPADs only by speed. This is a well known issue and I really would love this to be fixed. Scenarios where AH-64D are tasked to take out protected SAM positions in broad daylight, without any additional air support or SEAD, in my opinion are a typical game approach to create a difficult challenge. Yet, that is a scenario that should never happen IRL, other than as a last resort. The Apache is designed to take out armor/low level air defenses with its standoff capabilities (Hellfires) and mop up lightly armored vehicles, trucks and infantry. It proved to be quite good at CAS in COINscenarios, as well. Where the troops often benefited from the rockets when they could tell the Apaches to hit a woodline, small forest, a ridgeline etc. opposed to a precise impact point. The option of rockets, HEDP from the gun and the occasional Hellfire for a precise strike against a cave entrance, vehicle, building, or similar is a good showcase for the weapons mix and versatility.

Well, it is armored(!) exactly to protect from that kind of splash damage and small arms fire. So what do we expect? The armor mostly can't defeat an armor piercing shell, neither from an RPG or a Tanks. It can't withstand any large caliber rounds, either. Yet the armor, by design, will block shrapnel and splash damage from small fragmentation warheads, most of the time. That's actually the reason, that HYDRA rockets with Armor piercing warheads are a thing... To kill armored stuff, with a direct hit, not hope on the effects of splash damage. I personally would prefer to adjust all weapons in a way they better mimic fragmentation damage to the targets. The current way of (somewhat implified) modeling of internal damage is fine for me. Honestly, it would be cool if every bullet or fragment slicing through the target would be ray tracing and collision with internal systems, but I am perfectly fine with the current model. So if damage is dealt to the internal compartment there is an increasing likely hood we see effects, like speed decrease, immobilisation, weapon defects, etc. The critical component in DCS damage modeling is the way the damage types are calculated. We need a blast, heat and fragmentation. Not necessarily "simulated", but integrated into the calculation of the overall damage dealt to any target.

Yep, that's indeed something that needs some love, since DCS: A-10C Warthog... But as I said before, you don't use rockets in a frontal assault against a company of BMPs, either. In realistic scenarios they work pretty, well. For example, the real life run on the Iraqi search radars that initiated Desert Storm were executed by Apaches with mixed loadout, against a search radar installation with light(!) air defenses (AAA, Manpads) and not active SAM Sites, with multiple SR and TR. Both groups had more than 2 AH-64. They used the rockets to mop up and not to destroy the primary targets. They sent enough aircraft to ensure enough firepower, flexibility etc. To expect a single or two AH-64D with only laser Hellfire to go against an IADS or two to three companies worth of mechanized Infantry with integrated air defense is more like begging for cold war attrition rates... If we look at real life engagements with AH-64 Apaches, both the A, D and british "D" variant, they took great care and still were regularly shot down or damaged by some afghan insurgents with machine guns and RPGs. So there is a very real risk to get your a.. handed to you, if you try engaging Zsu-23, or more sophisticated anti-air in real life, not because the rockets in DCS "suck", but because attacking well defended targets with larger caliber autocannons and laser ranging sights sucks in real life as well and is usually more a last option, if you can use stand off tactics to minimize exposure to the threat or call backup, better equipped to deal with it.

Whatever was removed, definitely not the Windows feature. My best guess is, they adjusted the request to the windows ressource mgmt and/or changed the chaining of the "Updater" calling the Simulation?

The thing with VR is, you have two separate render processes. One through the VR platform (SteamVR, OpenXR, WMR etc.) and a "mirrored screen buffer"( sorry I don't know if the term is correct, but the part of the VR render that shows on the 2D screen), which is sent to a "window" on the Desktop. So the Windows commands apply to the window on the monitor, but I am pretty sure the DCS Window in VR is rendered through the VR platform?

I explained that before. If you run an application in a Window (either intentionally with Alt+Tab switching for example or unintentionally, the window is run as borderless and on top, but another process window still is the top process), depending on single monitor vs. Multi-Monitor/extended screen, the result differs. Originally (as in the MS support post) it is intended to give the current window focus and execute it in "fullscreen". This works, with a single screen, as intended. With an extended desktop (virtual screen spanning multiple physical monitors), it will not be able to enforce "fullscreen", but a side-effect/trick/hack was, that the borderless DCS simulation window, still was popped to the "foreground" and got the "focus" aka the application that gets all the requested Ressources, if available until further notice. This little "hack" is not the intention of Alt+Enter, but a side-effect that helped to tell Windows resource mgmt what to prioritize... At least that is the best I can do to explain, what happened for me. If there is a Developer out there with access to the Windows source code that can look up what in detail Alt+Enter is doing and share some more insigt, that would be cool. To my knowledge, the only option for game/sim/software developers to manage fullscreen, window size and appearance is requesting it from the windows ressource management (simplified: I am a game and need to be run in X/Y resolution, should execute on top of other applications/windows and need priority access to ressources). If the windows ressource mgmt messes up, you need to correct it, manually.

The real question is, what on the affected systems (still) prevents DCS to be the application "in focus" / executed in full screen? I mean Alt+Enter actually did(!) force the re-focus. With EDs changes this should be enforced, anyway. What process / window is interfering, is the question. I had to use this workaround myself, in the past (not always, but with multiple apps like Jetseat, Streamdeck, TacView, etc. running in parallel I could never really figure what exactly caused it, or why it was "intermittent". Since a while it does no longer happen on my system, so it's difficult to help in analyzing. What I was very aware with this "trick" is, that it is not a DCS feature of some kind, but a feature of the Windows Operating System. That's why I wanted to point out, it is unlikely ED will "fix" it, as they did not "remove it". We need to find the root cause, not hope for ED to move backwards... especially with 2.8 around the corner.

As posted before: Alt+Enter is a core feature of Microsoft Windows, not DCS! It was never a DCS feature. It was a "trick/workaround" to beat Windows into submission to re-focus the DCS window/force fullscreen, if the window management "thought" another process was in focus...

Theory, here. Neither tested, nor sure it's the root cause, so you will need to check if it is valid: could the problem be the slew in relation to the distance? Let me explain, what I mean. If the slew would move the seeker over the actual ground with a speed of say 0.5 - 2m per sec, instead of a certain degree change per sec, it would affect the perceived "speed". If the seeker looks at a far distant point, it would seem to not move "at all" while the closer to the aircraft (higher angle, off bore sight) the angle would change faster, with the same speed over ground. If the vertical movement happens to move over near hills/mountains and "jump" to the horizon or another mountain in the distance, it could make the seeker jerk between fast and slow change in angles, as it tries moving over the ground? I think there was a similar issue with one of the Targeting Pod implementations in the past, where it did not use angles per second to move the seeker, but distance over ground at a speed defined by the axis. I can't test myself at the moment.

Depends on distance... and this damage is cumulative. Immobilisation effects are modeled above a certain damage threshold, as are likely other critical damage effects. The more damage the higher the chance to get critical components "damaged". Not every rocket at a distance of 10m will kill/incapacitate all soldiers on the truck, hit the tank, damage the engine, kill the driver, or incinerate the covers. The problem with games is, they can't accurately calculate damage from a fragmentation weapon, because there are at least 3 different lethal effects at work, that all interact with the environment. Blast, heat/fire and fragmentation. Blast waves are shaped, reflected and compressed by the surrounding environment. A blast in a narrow street is way more lethal than on an open field. Heat/fire is partially shielded by objects, walls, but also reflected. Fragmentation is a multitude of objects flying a ballistic trajectory, hitting, sometimes penetrating the surrounding environment and potential targets. The computing power required to accurately calculate all this with ray tracing, may have an adverse effect on frame rates and overall performance... Let's say there are good reasons to use a more simplified way to model damage in most games. From my experience in the Apache lately, a Zsu-23 on a truck or unfortified emplacement, as well as technicals, trucks and infantry, now can be eliminated with a 4-8 rocket attack, if flown correct. 80-120 kts, range 3.500 - 2.500m or closer. Stable approach and co-op to ensure proper ranging information. I even killed BRDM and M113 with M229 rockets, though as they're armored it takes direct hits, so it is more effective to use AGM-114 Hellfire, against anything armored. In the end it's up for everyone to decide on their own what weapon to use in a specific situation. For me the rockets, especially the M229 work pretty well in the appropriate scenarios. Are they perfectly simulated? Nope, far from it. Still lot of room for improvement. Are rockets useless? Depends on the scenario. In most typical DCS REDFOR vs BLUEFOR scenarios, where you need to stop a flood of armored vehicles and tanks, definitely not the first choice. COIN or CAS against pop-up threats in wood lines, villages? Often easier to put a rocket strike on the position, than breaking of get in position for a Hellfire shot, while friendlies take the heat. Is the damage model of the ground vehicles perfect? Nope, though ED did add the critical damages and some effects, we miss visual indication (popped tires, broken track, burn marks, etc.). Also model damage so not "every" killed vehicle is exploding and burning, to add more realism and require pilots to assess the damage by behavior instead. A more detailed and flexible damage model wouldn't hurt, either, though I personally would prefer to better model damage effects of fragmentation and heat first.

Yep, so artificial 5% damage to mirrors, webbing, metal sheets etc. doesn't "kill" a vehicle either. But the cumulative effect of 8 rocket impacts near a vehicle each dealing 5-10% damage, will likely give you a more severe effect, up to killing the vehicle. The critical damage does not require 100% damage, from what I've seen. Anyway, the point is, though there is definitely room for improvement on the damage model of certain warheads and more detailed options to model internal damage, the rockets, if used against the right targets do perform not that bad, as people like to paint them.

No, it isn't. You notice when paying attention to the damage notification (critical damage messages) and also the actual behavior of damaged vehicles. Since at least the Nevada Map, you get mobility effects, where a unit in a group suffering enough damage has its maximum speed reduced. This can be as bad as to a crawl. The group is slowed by its damaged unit. I have seen effects where vehicles that were suspiciously similar to "weapons" disabled, though it is difficult to tell, as I could not find a log entry or similar for this, yet. If someone knows if and where DCS logs the critical damage sustained, I would love to get a hint.

That is the point. In other scenarios, where collateral damage, area coverage against infantry, quick snapshots against a general area of suspected infantry and light vehicles is called for by the mission, the rockets (especially if we finally have all warheads and can mix!) are the "better" choice. If the mission calls for quick and precise destruction/disabling/blocking heavily armored columns of enemy, Hellfire missiles (especially the Radar-Hellfire AGM-114L) is the preferred choice. Though the damage model of fragmentation warheads like the M151 rockets (but also Mk-80 series and the general cluster bombs) still need some love, the overhaul of the ridiculously resilient infantry a while ago, was a game changer, in my opinion. Since then you can actually kill infantry with rockets, especially the new warheads on the AH-64D. Damage to vehicles is actually modeled, though not visible. You can reduce their speed, or get a mobility kill. Cumulation of damage from multiple rockets in the vicinity, can take out a Zsu-23, Technical or truck... People expecting a BMP or Tank getting killed without at least a few direct hits, need to lower their expectations. A mobility kill against a BTR or BMD is actually debatable. Really didn't test that one for quite some time. Bottom line, if you use rockets against their preferred targets (infantry, unarmored vehicles/weapon emplacements) the results are pretty believable, though not perfectly realistic. The addition and realistic modeling of effects of M255 flechette, M261 MPP and the option to define zone loadouts ourselves will further increase the usefulness of the Hydra rocket system on the Apache in DCS. If ED further overhauls the damage effects of cluster bombs, rockets to better model fragmentation warheads that would be the icing on the cake. The change of the infantry damage model and introduction of technicals had a very positive impact on the typical Counter Insurgency scenarios, already.

He isn't flying the Helo, George AI is and it seems George AI has trouble holding a heading on commanded altitude changes.

Very eloquent and good explanation. The interesting thing is, this is a wishlist thread, basically a place to ask for new features. Why certain people feel the need to suppress everything they personally don't like, with bogus "arguments" is beyond my understanding. I really hope the overhaul of the AAR system as a whole, will see some closer looks at the ideas and input from these requests.

He always "knows" what ED is thinking, what their business model is, their plans, everything. He is the omniscient mastermind behind DCS... at least he posts like he is.