toilet2000

It should indeed be less than 171x171. If we consider each zoom levels to be a scaling by the same factor, zoom level 9 should be 99x99 (with a scaling factor of about 0.833).

There are issues with what's cold and what's hot in DCS because it simply isn't simulated at all currently. But as you can see from the videos I linked previously (see: ), it should absolutely washout during explosions, and for a fairly long bit of time.

It's actually much better resolution than it should be. It's a 512x512 sensor with 2 optical zoom level (Narrow and Wide FOV) and several levels of digital zoom. At zoom level 6, the image resolution should only be 171x171. Currently, apart from the blurriness, the resolution stays the same whatever the zoom level.

Clearly the "Good FLIR" image as posted in this thread is no better. It doesn't washout at all. Maybe there are issues with the current rendering (including the washout being sometimes the same "color" as the explosion), but the "good" image is clearly not realistic at all. It should absolutely washout and stay like that for some time.

Even then, the FLIR cameras found in current commercial products are definitely not the same as a FLIR imager from ~2005. It will generally washout because of the same limitation of any camera: "exposition" time. Sure, using dual-image techniques (think they call it HDR) can help, but even then... And that's something available in current day smartphones, not a FLIR pod from 2005. Even from the videos, you can see that this washout stays for quite a long time, suprisingly so, while the flash is almost instantly gone when viewing the CCD images.

Indeed. My biggest gripe is the digital zoom (the zoom levels, not FOV levels), which keeps the same resolution whatever the zoom level. There are very public documents describing the behavior of the digital zoom levels, such as this one: https://trace.tennessee.edu/cgi/viewcontent.cgi?article=6123&context=utk_gradthes On page 24 (38 in the PDF): So while the pod is 512x512, a zoom on level 6 leads to a resolution of only 171x171.

To be honest, it does do that IRL, see the following video (should already start at 48s): Here's the direct link to the video:

Thanks IronMike! Good to know. Still a shame though, the previous offset function was definitely more useful. But if it is really like that, then that's just another quirk of the Turkey! :)

The SLAM is not a F&F weapon. The INS/GPS is not precise enough to guarantee a hit without manual terminal guidance. Basically, you can "hit coordinates", but your missile most probably won't hit those coordinates, but somewhere somwhat close to that point. So yeah, real world tactic with the SLAM is to always manually guide it to the target. The SLAM-ER (AGM-84H/K) are the ones that are true F&F, both with a more accurate INS/GPS and an automatic target recognition seeker (such as what the AGM-154C JSOW Unitary should have too).

Thanks for taking the time to confirm it! It's definitely a really useful feature for RIOs and this bug makes it extremely hard to use.

According to public sources (wiki) the AGM-62 Walleyes II datalink has a range of about 45 nm. Since the AGM-84E SLAM has the same datalink, the range should be pretty much the same, and it is pretty much that in DCS. You can get up to about 50 nm, but the image quality degrades really fast. As for usable range, I found that at 40 nm, flying level (important as maneuvers tend to cause more interference/worse image quality) and selecting the right antenna (Aft if the missile is in the aft 180 degrees region of your aircraft), the image quality is decent enough to manage a good hit.

IIRC this wasn't the case before. Designating a Full Action hook point with the HCU on the TID and pressing the HCU Offset button moves does not recenter the TID on the hooked point, but rather moves the TID in the opposite direction. This is opposite of what IIRC it was doing before, and opposite of what is described in the manual: I'll try to upload a track later today when I can. EDIT: added track f-14_hcu_offset_bug.trk

EDIT: Mods can delete this, I posted it in the wrong section. Created another post in the right section. Sorry! IIRC this wasn't the case before. Designating a Full Action hook point with the HCU on the TID and pressing the HCU Offset button moves does not recenter the TID on the hooked point, but rather moves the TID in the opposite direction. This is opposite of what IIRC it was doing before, and opposite of what is described in the manual: I'll try to upload a track later today when I can.

It was definitely possible, as it uses the same DL as the Walleyes II, which are known to be used with a pair of aircraft, one dropping and one guiding. On top of that, I had a discussion with BN or 9L (can't remember who right now) that confirmed it was possible for the Walleyes, just not implemented yet.

Wiki quotes a 45 nm range for the Walleye II datalink, which is the same datalink as in the original SLAM, so this seems correct according to public info. The long range SLAM is the SLAM-ER, which we’ll get eventually.

A GPS backed INS should definitely not drift. It can be inaccurate, sure, but certainly not drift.

Can't look at your track currently, but did you directly overfly the target? If so, the WMD-7 has a limited gimbal speed and doesn't really like following a target directly underneath. The pod will have to do a roll-axis rotation of 180 degrees, which makes the point track switch to area track. Best to drop your ordinance and then move off-axis (eg a 10-30 degrees heading change)

I've been told by people in the know that the RCAF used to train extensively on the usage of the AG radar, especially during the 90s and early 2000s (maybe still today, but I don't have any info on that). They were training for "Fulda Gap tank column hunting" types of mission using GMTI, for example. While the US Navy and Marines might have never really used the APG-73's AG radar features to their full extent, not the same thing can be said about other users or other airframes with similar radars. As another example, the F-15E uses its AG radar extensively for weapon delivery, or at the very least they did use it extensively during the 90s.

Has Santi has said, our Hornet is definitely capable of Medium Resolution SAR (EXP3), but it is far from the kind of image the F-35 gets.

As others have said: The HUD is normal behavior, due to wind. The pitch ladder always follows the velocity vector. If there is a lot of crosswind, the velocity vector will point to the side, and that behavior is what you see. I don't remember if there's a "cage VV" functionality in the JF-17 though. As for the WMD-7, you have to enable the CLDP "breaker" on the AAP panel (the panel where you generally press "CMBT" to enable all the combat-essential systems).

That's not really true. Polychop said that there would be 4 versions when they started selling the Gazelle: The SA342M, the L with the Mistrals, the L with the gunpod and the rocket pod and a dedicated "sniper" version, from you'd be able to use a sniper rifle from. They said that in the end, the sniper rifle would have had little use in DCS and replaced it with the minigun version.

As far as what Heatblur have said, it's highly unlikely. There isn't a ton of info available on the implementation of the Sparrowhawk and PTID, especially on the dependencies of that system, plus it's a pretty big change from what is currently in DCS.

Can't tell you about the latest patch (I haven't tested yet), but last time I tried, it was actually much easier to spot targets on the PG map than the Caucasus map, due to the lesser amount of "clutter".

@shagrat, this sums up perfectly what's wrong with the Harrier and why there's a decently sized crowd asking for fixes. Don't forget that the vocal ones are the minority. For every 2 vocal individuals, there are 8 that have the same complaints but do not voice their miscontent! As for the Harrier, there's a clear lack of polish in how the systems are laid out and the systems are clearly simplified, especially anything related to targeting and designation sources. I will quote a post I've made somewhere else: As for the targeting source, you're supposed to select the targeting/slewing source using Sensor Select Switch Up and Down, as per the real manual. Currently, it does not matter whether you're in whatever mode, and the BCIP/BAUTO, RCIP/RAUTO, GCIP/GAUTO and CIP/AUTO logic is simply non-existent currently. Really, like I said, the targeting system is full of magic.

Yep, this is definitely a bug as it can be clearly seen in the following video that the cursor returns to center when using an axis: