Noctrach

CAP BRG is currently using the aircraft heading as reference. This means that a contact bearing of e.g. 270 with ownship heading of 300 gives a CAP BRG result of 330. As such, the current number is a very weird representation of antenna train angle, rather than contact bearing. This behaviour is the same in ground and aircraft stabilization modes. Is this intended behaviour or a bug?

Hey at least we've moved the goalpost from "The Phoenix Was A Bomber Only Weapon And Never Hit Anything" to something even less substantial or relevant to the DCS situation. Time to complain about people dropping their tanks when they're empty. They tend to be in shorter supply than missiles on most carriers and forward airbases. Anything else strike your fancy? The only "reality" I see being problematic here, is the one where we pretend any of us are in the know on the actual capabilities of these weapon systems. I'm being facetious but you get my point, the discussion is just nonsensical at this point. There's so many fallacies and make-believe in DCS that you either come up with hard, substantiated evidence that the currently Phoenix modeling is in some way objectively worse than the auld AIM-120s or SD-10s, or just stop endlessly making these kinds of threads. Hell, half the airplane roster has either under/overperforming FMs in some regions, guesstimated systems behaviour or other flaws. Just learn to accept it's a sim with sim-isms and adapt your tactics to what you're dealing with.

Exactly. But then again, airquake has taught me the AIM-7 is a useless missile so I don't see why they ever employed them. Regardless, it was always disgusting to me how the navy spent millions in extensively testing Phoenixes against targets they never intented to use them against. Taxpayer millions. :mad: 3 actually. :smilewink: 2 failed to ignite due to human error involving the arming pins. 1 got kinematically defeated by an egressing MiG-25. Yet people keep bringing this shit up, ohwell.

Thanks, I'll see if I can also do something of a script for this. For now I just roll with two pods I think, twice the flares, twice the fun.

Yeah I noticed it was off, the values on the AIM-120 and AIM-54 wouldn't make sense either. So no idea. It might be something related to the Fi/phi values which iirc relate to sensor tracking but I'm just guessing at this point.

@dundun92 That would be missiles_data.lua, P_77, but since most of that is in cyrillic, it ends up gibberish for me.

@dundun92 I'm pretty sure the notch values are defined in missiles_table.lua, by seeker = { height_error_max_vel } in KPH for "half" the gate. This is would result in +-32 knots for the AIM-120B, +-27 knots for the AIM-120C, +-75 knots for the AIM-54 (not sure if this is the HB one, most likely is) Correlates pretty well with what I've seen in TacView

Ya but in that case you can just fire it in any of the PLM/PAL modes, which will give it an azimuth and altitude and tells it to go play fetch.

I think the bottom line is, it can be used but effectiveness will be very low :) it would be a freaky instance of luck, but I've seen it happen The reason it works so well against notching targets is that from a "game" perspective the missile will check every X milliseconds whether it can still see the target and whether it will go for chaff. During a notch, the target isn't eligible as a valid result, so the only possible outcome is to go for one of the chaffs. I feel this can still sometimes be influenced by chaff rejection, resulting in the missile finding 0 valid targets until it re-evaluates on the next tick. The evaluation will still run if you're not notching, like during a lookup, but the chance of it succeeding is slim, depending on chaff rejection values.

Considering the age of the missile and the size considerations of batteries... Would launching it active not just cause the the battery running dry mid-way through the shot? Active scanning costs a whole lot more juice than homing SARH or flying on DL. As such I highly doubt that was a possibility.

We know for a fact it isn't tbh :book: Most, if not all radars since the 60s had some form of range gate processing. The MiG-19 in DCS iirc has a radar that didn't do this and as a result it is completely blind in a look-down scenario under something like 3-4 km altitude. Similar to doppler gating, you have different "bins" for range, if you detect a target at a slant range "5 to 6 miles" and there's clutter on a slant range "7 to 8 miles" the radar will just ignore that. To really be able to benefit from background clutter you'd have to get the ground inside the range resolution of the radar you're trying to spoof. I have a tacview somewhere from the old API where I demonstrated someone how to notch a near co-altitude AIM-120C by doing a lazy turn without chaff at 30,000 feet. I don't think the new API changed this, but who knows what the future holds. Personally I always just share this under "ECM would take care of providing my clutter" in my headcanon. There's plenty other reasons why a missile would miss in real life, but complete loss of contact through notching at 20,000 feet would not be one of them. Edit: there it is. Bear in mind this took advantage of the scripted 13G pull behaviour. In the current API the missile would still be notched, but would continue to my last known position and pick me up again 9 times out of 10. There's no way I'd do able to do this right now, least of all at Mach 1.2 :P HighAltitudeNotchNoChaff.zip.acmi.zip

This is mostly true, but I'd like to add some extra nuance. From a combination of LUA file reading and very extensive testing with my old SATAL team: two things need to happen 1) Missile needs to be looking below its own horizon (so any pitch down greater than 0 in magnitude will suffice) 2) Closure rate needs to be lower than the LUA defined notch gate. This is unique for each missile and radar. Slowing down makes this easier, but you can do it at mach 2+ if you have a steady hand and good timing. With the old API the missile would execute a scripted behaviour where it would pull 13G off the target for a second or so, which meant even a 0.1 second notch would spoil the shot. With the new API, the notch is only valid as long as you keep the closure below the defined number and the missile no longer goes haywire immediately.

@SgtPappy good points. I feel firstly we should distinguish notching/beaming, lookup/lookdown from pure chaff effectivity. Chaff modeling in DCS is still fundamentally RNG based, so there's always a slight chance that a missile will go for chaff instead of the target, even in a head on look-up scenario. Notching/beaming merely pushes the balance of the diceroll to be more likely to go for the decoy. Secondly, since chaff is being evaluated on the missile rather than the launching platform, a look-down on the side of the missile will make it susceptible to notching and therefore massively more likely to go for chaff, even when the STT lock is in look-up and held steadily. This imo is the key point in this issue. Even if the launching platform never loses lock, the missile may still go for any of the "radar flares" that have been released. Considering chaff in DCS lasts for 5-6 seconds, this means that a missile may lock onto chaff that is well outside of the scope of the STT illumination. The SARH missiles in this game are especially sensitive to this, as they have very low chaff rejection values for some reason. In my experience, I don't fly the Mirage, but no other jet I've flown will lose lock in a look-up on a beaming target. The only exception to this rule is the F-14 on a target disappearing inside the zero-doppler filter if closure drops below +-100 knots. For missiles adhering to the old API I can absolutely confidently state they will not be notched in look-up, but this doesn't bar them from eating chaff if you get the exceptional lucky dice-roll.

Track Hold is a button the RIO has on theTID to tell the AWG-9 to keep updating a track for up to 2 minutes, irrespective of whether it has been correlated with a radar hit. It can be manually enabled for targets you're tracking and is always enabled for targets under missile attack. I.e. if you fire in TWS, trackhold is automatically enabled for targets you launched on. In light of these changes, I'm more curious to know to what extent the AWG-9 will be capable of resolving "false" tracks originating from a cranking target, because right now it's very poor at doing this. I guess we'll see that in the update on the 18th @IronMike ?

You can still see the track on the TID but it has a small cross in it when it hasn't been updated recently. You will not see whether the missile has received a signal or has been trashed.

Is there a (legitimate) way to reduce the flare release interval on the Viggen to less than once every 2 seconds? Reason I ask is that DCS's flare simulation being the way it is, having only 2-3 active flares in the air at any given time makes MANPADs a significantly more lethal threat to the Viggen than even the toughest SAM site :/

No missile in DCS is notchable when they're looking up even 0.1 degree above the horizon. Background clutter is simulated as "below the horizon", not based on chaff or actual background. This also means notching at 30,000 feet is just as effective as notching at 5 ft. The idea that chaff will create some high-clutter background for PD sensors is a fallacy that I see oft repeated on the forums. This is absolutely true for Pulse-based radar tech, but for PD ones the effect of chaff is minimal, exclusive only to the expansion/bloom fase of the countermeasure. This lasts about half a second. Essentially what you do with a chaff release is create a very large temporary return in the hopes that the PD sensor mistakes it for your aircraft and loses the track, even if only shortly, while you execute an evasive manoeuvre trying to avoid the reacquisition search pattern when the chaff gets inevitably filtered out. Chaff without other ECM is pretty much meaningless to modern PD arrays and had very limited effectiveness against radars in even the 70s and 80s. A mech-scan array might have more trouble keeping up with a fast-jinking target, but it won't change the chaff-eating tendencies. If anything it will just increase the notch-gate so chaff gets filtered out rather faster. It's still a PD sensor, not a Pulse one. Easier to notch, yes, easier to chaff, no. Which is also the case in DCS... Phoenix notch gate is a lot larger than other missiles or planes, hence why you see people accidentally notching it. Again with the caveat that the missile has to be looking down. In DCS chaff is invisible to aircraft radars, so you won't be breaking lock. Instead it's simulated to have a % chance to attract a missile in flight towards the aircraft that launched the chaff, but only if the missile is nose down at least a fraction of a degree. (This does mean that you can complete spoof STT missiles even when the launching aircraft has a steady look-up lock, but that's a different topic...)

Nope, try it yourself in the mission editor, even with uncaged IR missiles on modules like the MiG-21 and F-5 you cannot get a tone on flares since they do not exist as "objects" in that sense. The reason you see "pre-flaring" work is because once the missile is in the air, tracking YOU, it will also start tracking all flares dropped BY YOU and start the dice-roll. So if there's enough flares in the air at time of firing, the missile has a pretty good chance of going for one on the first time it calculates what to do. Note I emphasise how they have to be flares released by YOUR aircraft. The missile will ignore countermeasures from all other aircraft. This means you cannot "buddy-flare", something which is done a lot in helicopter attack runs irl. I'm not saying pre-flaring is wholly ineffective, but it doesn't work like pre-flaring at all. It works exactly like post-flaring but is less reliable. Apologies if this seems like "gamifying" it too much, but unfortunately this is one aspect where the modeling in DCS is really exceptionally shallow.

Pre-flaring doesn't really work in DCS for the simple reason that I'm 95% sure the flare acceptance/rejection is executed on the missile rather than the launch platform. The missile as a self-functioning game object isn't in existence prior to weapons release. What "pre-flaring" does in DCS is increase the volume of flares in the seeker head at the moment of firing i.e. when the missile is "created" in the game world. Since flare rejection is just a dice roll, more flares means there's a bigger likelihood of the missile going for a flare instead of your aircraft. The best "pre-flare" routine is therefore "whatever keeps at least 5-6 flares in the missile's field of view at any point in time". In my experience this is something like 2 flares every second or so, which means you burn through your flare supply in absolutely no time at all. All flares dropped that expire prior to missile launch are pointless, since DCS doesn't really simulate the launch platform being spoofed by flares... As a result, just dumping 6 flares in extremely rapid succession the moment you see a missile trail is by far the most effective and flare-efficient way of doing things. I've tested this extensively with the F-16 and Ka-50 against a setup of 50 launcher of various types. Pre-flaring ALWAYS gave worse results than dumping a bundle of 5-6 flares after the missile was already in the air. Conversely, dumping that bundle at the right time post-launch made me almost impervious to IR missiles, so that was nice at least. There's no difference in doing this for front or rear aspect shots, except rear shots are much harder to decoy so you might want to either increase flare volume (double it) or run the program while executing a break turn to put the missile in front of your 3/9 line (forward hemisphere) to obscure your exhaust. From a "game" perspective, DCS is kinda binary in how it simulates flare effectiveness, so this is your rule of thumb: Aft hemisphere - Ineffective, forward hemisphere - Effective. Afterburner on - Ineffective, Afterburner off - Effective. Adjust your flare volume based on this. As for chaff, by itself it's almost ineffective at decoying missiles and should be used in conjunction with a notching manoeuvre. Therefore a similar program should be used as for flares and you'll get the best results by timing the program with your notch (i.e. dump 6-8 bundles of chaff in rapid succession while you execute your defence)

Alright, then I've been lucky so far. Will adapt my tactics to that new knowledge. I have tested it quite a bit and I can consistently push her to 290-300 knots and 5-6G in both on- and offline without lockout. I hear the same from other Tomcat pilots so I'm assuming there will be a lot of unpleasant surprises coming next patch. Regardless, thanks for the clarification @fat creason :thumbup:

Calm down there @Skysurfer , no need to get so defensive. I'm not out to get anything changed, it suits me right fine as it is, so I haven't the faintest inclination to start pretending I know how it is in real life. It's just a sim after all. F-14 is very believable in most other aspects so if this is the only flaw then fine by me. Just find it rather incongruous that they'd specifically limit it to 2G at under 54,000 gross weight and 1.5G above that, when it's fine all the way up to 6G. The jet was rated 7.5-8G for wartime, bits start breaking for realsies at 12G. Flaps are rated for 225 KIAS, bits start breaking for realsies at slightly over 300 KIAS. Seems to me like a 50% "safety margin" is sensible, a 300% one might be a tad overkill. But if HB and the SMEs are fine with this and consider it done, then I'm fine with it and will continue to make use of this to the full extent that the sim allows. In general, or for this specific module in the foreseeable future? ^^ Because I do feel it goes against some good and sensible BFM principles, but it's just so damn effective when executed right.

I hate to bring this topic up again but I was wondering what the official stance was on the status of the flap damage model in the Tomcat. Is it complete? Is it still WIP? Reason I ask is that while the -1 states overspeed/overstress is a risk at above 1.5-2G and 225 KIAS, but I've not seen them break yet at up to 5.8G and just under 300 KIAS. They do however, break the very instant you exceed 300 KIAS. I'm getting into BFM with the Tomcat and notice that while staying fast will save my bacon in a 1vMany situation, in a 1v1 the best way of fighting by far is to bleed down to about 290 knots and drop the flaps. It feels like weird way of fighting, but the performance in terms of both rate and radius with the flaps down is so crazy that it's incredibly hard to beat. Is this the final state or will learning to fight this way ingrain some really bad habits that will come back to bite me later?

AI uses a different flight model unfortunately, so comparing with it is very pointless. I think it's also kinda pointless to compare Viper against Hornet for any reasonable discussion on the FM regardless, as there's no charts for the Hornet, nor does it really matter how they stack up. It's an F-18A/DCS at the end of the day. Plenty good info on the F-16 to do standalone comparisons.

Again though, kinda not the point of this thread. I'd like it to not get buried in the noise before one of the devs can provide an update on the completion status of the system.

Yep, Crptalk's post is pretty much where it's at. It's flyable (FM WIP) and can do limited combat sorties (Combat and navigation systems WIP, damage model WIP). It can fire AMRAAMs and sidewinders in BVR and WVR and even with half the systems and most of the switchology missing or WIP, it's pretty good at it. It can also deliver a variety of dumb munitions, laser guided bombs and mavericks, all of which are heavily WIP, missing various systems. Your mileage may vary as they say.