toilet2000

That’s not part of DCS but rather part of the radar code, which is most often per-module and not DCS-wide. I know Galinette (Razbam’s radar dev) has talked about it.

That's exactly how Doppler notch filters work: that spinny thing has reflective material moving at a very high linear speed, both negative and positive. The issue though is that the return, even though it might have a very distinctive Doppler shift, is fairly small, so in general it's hard to detect a spinning rotor at long range. The shorter range of a missile might actually still be able to see it though. I would assume though that in this case, the AIM-120C just went directly for the last contact position with extrapolation as it should and hit the heli.

You mean like the Hornet? Any modules will have tons of bugs at any time. That's true for any software, especially non-critical ones. Knowing there are issues doesn't make it "worse" than anything else. To the opposite, you might be greatly biases because you don't have access to those bug trackers for other modules. How so? Both work as intended for me.

90%? Not at all. Most of them are. Nonexistent damage model? On what planet do you live? It's at pretty much the same place as other modern modules. The issue is the WW2 damage model not being available yet on modern jets. If there's lots more, then it shouldn't be hard to list them without using hyperboles like you did.

Like what?

I can't say I've had that experience at all. Some switches are non-functional like in all modules, but a vast majority of them are. The rudder needs to be sensitive at low speed due to the very small turn radius required for roadbase operations. You can simply add a curve (like with every other module) if it's too much for you. As for bugs, pretty much all of those I had were fixed at the end of last year. Right now it's in a very good spot. I assume some of the issues are not with the module but a meter in front of the screen. Sometimes it's just a matter of learning the module, and the Viggen is very quirky by design.

AI is currently unimpeded by weather. This was the biggest limitation of the new weather effects and engine and ED have said they are working on it.

That's weird, it does work for me. Even if you put the inner radius at some ridiculously low value (like 0.1) it doesn't show any pixelation?

There's a modification of fholger's vrperfkit that might be working for fixed foveated rendering in DCS, albeit with caveats. See: https://github.com/cedriclmenard/vrperfkit/releases/tag/v0.2.2-dcs-ffr

The missiles are always SACLOS. They aren't SARH or ARH. Normally, the tracking radar automatically takes over to send SACLOS guidance commands to the missile, but SACLOS is not a fallback mode for the missile, it's the only guidance mode. The issue is that optical guidance is a fallback mode for the operator, requiring manual target range input. As for DCS, it seems to always use this mode and never use the radar tracking, except for the gun solution.

As stated by @Hulkbust44, missiles can infer a "range" for the control laws by looking at the angular rate of the emitter target. An example of the same logic is seen in the Maverick missile, where it will "loft" a bit before coming down on the target. Real lofting though requires a somewhat precise position, as it is an optimization of several parameters for best kinematic range. You'll in fact see a much, much more pronounced loft at long distances.

You first need to designate a target using the AG radar by depressing the TDC, I think it's called T5 Press. Make sure you assigned it in the controls because for me it got reset in the last patch. Once that is done, you either press the stick switch that changes the radar scale to the left (S2 hat) or you press the "RBM" OSB to change it to EXP then DBS1 and DBS2.

Because the stores aren't mounted on the centerline. It actually looks like the CCIP solution is using 0 altitude (like if you were on the ground) on your images. That huge offset (170 mils) looks a lot like if you were flying basically as close to the ground as possible. I'd be curious to see if mounting only a bomb on the centerline gives that kind of offset too.

No, we don't have an "Old Hornet model", we have a Lot 20 with TAMMAC and all the bells and whistles. Choosing a 1994 date doesn't change the plane, it only makes GPS unavailable. Same goes for the F-14. Changing the date doesn't give you an earlier model. The DIL could very well be displaced horizontally due to incorrect wind calculation, incorrect attitude estimation and wrong altitude. Best example is using Snakeyes, which you will see the DIL jump left and right from each releases at low altitude due to the offset between stores, with the horizontal jump getting bigger the lower the altitude. As I said, there is a bug nonetheless, but it's simply untrue that GPS/INS pos is supposed to have no impact on the CCIP solution. Yes, that's the bug I talked about in one of my previous comment

You really don't understand how the CCIP cross is computed. I suggest looking a bit a the tutorials on the A-10C, as it only uses it's INS/GPS combined with DTED (Digital Terrain Elevation Database) to compute the slant range and point of impact. Old Hornet models used to simply compute the CCIP slant range (and thus the cross position) using the radalt or baro altitude (like the Mi-24) or using the AGR when commanded to (Sensor Select to HUD). The radar doesn't directly need any INS data to compute slant range. Hornets that received the TAMMAC upgrade (like ours, except for the HSI) have the integration of the DTED, meaning the aircraft, knowing its position from the INS/GPS, can infer the slant range by correlating its slant angle and INS position with the elevation database and finding the intersection of both. This gives slant range, but only if the INS is accurate. This is generally not an issue because moments without GPS coverage are often small enough that the INS won't drift enough for the accuracy to be that much lower. The issue arises when you completely remove the GPS on a whole mission with a bird made to fly with GPS and with the DTED integration. TL;DR Yes, the CCIP cross should depend on the INS position when not in AGR mode.

Did you read my first comment in your thread? What ever feature I am talking about has definitely a link with the thread and an issue with it actually makes the CCIP unusable with INS drift (because AGR doesn't override the DTED range estimation). Moreover, I was answering question others asked me.

INS position influencing the CCIP solution. There are some issues (as said in one of my previous comment), but with DTED that came with TAMMAC, INS/GPS position should change the CCIP solution calculation, as it would not only rely on current radar altitude when no AGR/TPOD ranging is preset, but rather on position, attitude and the intersection of the weapons predicted path with the elevation map given the current INS/GPS position.

The updated HSI is the only thing we don't have from the TAMMAC upgrade. So I assume we simply don't have the right HSI and we have TAMMAC, which actually fits the CCIP behavior.

It's been discussed quite a lot on the forums and on the Discord. The general consensus is that given the features we have and the specific model/time, we do have TAMMAC. We should actually get the updated TAMMAC HSI, which we don't.

Considering the newer block Hornets should have a DTED, your current position compared with your current attitude (i.e. the LOS of the CCIP piper) should be correlated with the DTED to give you an accurate computed impact point. So basically both are linked. It should feed from the AGR when telling it to though (via SSS Fwd), so there's definitely a bug. But at the end of the day your GPS/INS position is indeed used for CCIP. The HSI situation is actually wrong. Our HSI is not what the jet should have, since it is a TAMMAC equipped jet and thus should have a DTED.

Hopefully we'll get some news about this soon! :)

Considering we're getting a Late Block II (https://forums.eagle.ru/topic/273179-dcs-ah-64d-development-report-4th-june-2021/?do=findComment&comment=4684398), the APKWS is not a realistic weapon for our Apache, since late block II would be around 2008-2011ish. According to your own source, the first ever test of an APKWS on the Apache was in 2013. Same goes for the AGM-114R, which entered service in late 2012. As for the Stinger ATAS, CRV-7, AIM-9/Sidearms and Mistrals, these were not used on AH-64D Block II in US Army service and ED already confirmed these were not part of their plans.

Not at all. It was reduced because they didn't meet their initial deadlines so they dialed back the "hypetrain" that they started to early.

Then blurry isn't the term. Even if information is lost, nothing garantees that this "lost" information was useful to make a sharp image to begin with. That's the goal of upscaling, we don't see individual pixels, we see patterns. If you can upscale and preserve sharp patterns, then that "lost" information wasn't very useful for us. That's actually the basis of lossy compression like JPEG (when using a more quality-friendly compression). At the end of the day, if your upscaling method is blurry, it failed at upscaling.

It's not antialiasing, it's really just upscaling (like DLSS is). Those methods are getting quite good at producing upscaled image based on synthetically generated base images (i.e. games) and does not make them blurry (depending on settings of course, but the higher quality settings do not). It's actually something that has been done for a long time in higher res TVs and such (i.e. upscaling 1080p to 4K), but the task is much more challenging for synthetic images than real video images (like TV). FSR and DLSS both cannot be used for antialiasing.