Eddie

If you say so fella. :D

RWRs etc. can display whatever they're told to display. IRL the threat libraries are not hard coded but can be (and are) loaded based on the requirements of the operators. It is common to have separate threat libraries for training and combat operations. And combat threat libraries/mission data can be, and is, customised for individual operations depending on the order of battle. In short, if you tell the RWR that the radar signal from a blk 30 F-16 is a MiG-29, or anything, that's what it will display. And there are other things that can be tweaked as well.

Given that the functionality is already present in the F-5E and other recent aircraft, I'd be very surprised if it wasn't also there for the Hornet.

Except it wouldn't. Pylons are a standard fit for the A-10C and are only removed for air displays and the like. For the Hornet, and most other tactical aircraft, we only fit pylons when they are actually needed.

All in the Nellis 11-250. http://www.476vfightergroup.com/downloads.php?do=file&id=424

I would love to, however I'm afraid most documents covering this subject are either export controlled or otherwise sensitive. All I can do is, very carefully, try and guide people to reasonable conclusions via my own written word (unless I can find the information already in the public domain).

Indeed. This is one of the main rubs with the way DCS in general has modelled these systems. They don't really give the kind of information they should, due to a couple of small but important differences from their real world counterparts. Specifically threat prioritisation and filtering. Very much an important point. Threat library data, it's this data that determines is a given signal is identifiable, as what, where is sits in the priority hierarchy, and what filters affect it (low alt/ship/search/"others"). Now of course, specific threat library data is highly sensitive, so it needs to be entirely fictional in a sim. But the logic used is very simple, and anyone who understands threat systems and what a pilot needs to know about them should be able to come up with a good facsimile. Indeed. This is the key point, threat RADAR. An early warning/air traffic/approach RADAR is never a threat to the aircraft. Therefore in most cases the pilot does not need to know about them, however in some cases they may find that information useful (it may allude to a threat systems location, or help determine if you're well masked. etc.).

The sounds you have are correct I'm sure. However what's missing are the threat specific tones, usually direct audio of the RADAR signal (freq/PRF). These have been present in pretty much every western RWR since for decades. Its actually the primary method by which threat information is fed to the pilot (audio is faster than visual). In US systems typically audio is only heard for the priority threat (shown under the diamond on the IP-1310). Although no DCS aircraft has this audio, the ability for it is there in the lua files is there. While I've got no first hand experience with the ALR-87, I do find it difficult to believe that it has lesser capability than earlier systems, and systems since. What manual specifically did this come from? The language doesn't sound like any tach manual I've ever read (and certainly not the way we write them) so I'd like to see the surrounding context.

No. I guess it's a case of either limitations of DCS and/or that BST have incorrectly interpreted/misunderstood the data they've found. I suspect a bit of both as the same issue affects other aircraft, it's just less noticeable as their RWRs are even more simplified. At present in the F-5 TTRs are not shown at all unless they're actively tracking you, even if they're emitting DCS just knows that you're not the target and therefore doesn't bother to display anything. This issue is evident when you look at aircraft, air intercept RADARs are TTRs, they shouldn't show up at all in "Search" mode, as they are considered TTRs. The only RADARs that should be filtered out without the "search" filter selected (using the logic BST has used, which isn't quite right) are EWRs and target acquisition RADARs (RADARs that are not involved in guiding a weapon on you). TTRs should be shown regardless of whether they are actively tracking you or not. The symbology is also off (SA-6 being show as "06" rather than "6" for example), as is threat prioritisation. Audio is also greatly simplified, but that's been true for all DCS aircraft so far. The F-5 as modelled now is an improvement over other aircraft in some areas, but still not presenting the information the pilot should get.

In the video you're carrying CATM-9s. Captive training missiles.

Yes. This is also pretty standard behaviour for an aircraft of the F-5s generation, it's simply the AB failing to light off. (the fact that the fuel flow stays at AB levels is questionable, but that might just be due to the way AB light failures/blowouts are modelled). Unlike modern fighters the engines in the F-5 don't have any digital control/management systems, so if you start slamming the throttles around and/or making large power setting changes at high AoA/low speed you can expect to see issues such as surges, stall, and AB light off issues. To minimise AB light off issues in the F-5 allow the engines to stabilise at max dry before engaging AB. Even doing that you may still see the odd light off failure at low airspeed, high AoA, and high altitude.

Chromium, I'm trying to get DAWS working, but it seems the save mission function doesn't want to work at all. The AI enhancement features are ok, so the module is loading. The only error I can see in dcs.log is the one below, any ideas?

The Buk M1/M2 has the NATO code name SA-17 Grizzly. SA-11 Gadfly is the original Buk prior to any major updates.

It really would. Or even deny them in the first place...

Being able to set waypoints and other aircraft data prior to flight via a planning tool is far more realistic than entering each waypoint in the cockpit on the ground, and for many aircraft entering such data isn't even possible in the cockpit (or at the least you are limited in what parameters you can enter). A feature such as this is vital to provide a realistic mission planning function in multiplayer.

I guess it depends on what ECM we're talking about really. If we're comparing to 60s/70s then I think the Low Blow will do pretty well, against modern ECM I think the result will be different. Valid point on chaff bloom rate as well, older chaff didn't have the bloom rate and sophistication of what's around now. Yeah, that's certainly not right in my opinion. If you're employing indirect terrain masking the ground clutter alone should give the Low Blow serious issues picking you out, even with its clutter rejection.

This. The Low Blow has an azimuth resolution cell of just over 600 feet at 6 nautical miles, so a beaming aircraft travelling at 300 knots will be distinct from any chaff after just over a second. If you could combine a very high dispense rate of chaff and jamming (unlikely as few SPJs cover the side hemispheres) while placing the TTR on the beam it might have a greater than zero chance of being successful, but it won't be very likely. That said, while you won't necessarily decoy the missile, you might generate sufficient miss distance to survive the shot by causing the missile not to fuse and/or being outsider of its lethal radius. Sadly, both things that DCS doesn't seem to model. Either way dragging the missile would be far more effective as not only would your chaff effectively obscure your skin return from the TTR, it'd also bring your SPJ fully into play. Although the SA-3 isn't too bad when it comes to ECCM with the leading edge tracking doing a good job of defeating an RGPO. How I wish this stuff mattered in DCS at all.

I was referring to specifically missing LITENING pod and aircraft system TGP features, never mind other systems and weapons. Multi target cueing and multi target tracking being just two.

There are quite a few missing TGP/Aircraft integration features I'd have before a colour camera upgrade...

Yeah you're right it is. What is interesting, and what made me think differently, is that there are also issues with the AIS pod on the A-10C (clipping through the ailerons with air brakes extended). I wonder if the A-10 has a similar issue then?

No. Moisture heavily attenuates infra-red light transmission in the air, moisture and other particles such as smoke are the biggest problems on the battlefield for IR camera systems. In short, while IR systems will see further through moisture/smoke than a visible light camera (smoke especially), they are still affected.

It's the AIS pod that's too long, the aircraft is fine.

For blufor, no, they follow either the Sally or Elgin LFE routing. Redfor however do typically enter from the west via the lee corridor.

During the day, no. Should be visible (and quite bright) from behind, but the plume/shock cone should be barely visible in direct sunlight. At night the reheat plumeshould be visible for miles, and especially bright when viewed through NVDs. I think this is a general lighting issue, the same one that makes aircraft lights much less visible than they should be.

We have every target present on our DS on a day to day basis. We only remove some range groups for large force excercises from time to time, and then as Stuka mentioned we'll just remove any ranges we aren't using.