DoorMouse

TWO, EJECTING.

I mean even more so with the last patch, Its way slower down low but it still burns FOREVER. Its like a Mach 1.7 persistent threat for 25 seconds. It probably wont hit you but you still gotta not fly into it.

I still have found it personally gratifying and hilarious to watch the missile burn for 25 seconds straight into low targets. Its like the missile from "Behind enemy lines"

Oh my lord it hit at mach 3+ at 50+ miles F-pole. Thats gonna be scary even in a flanker.

ohhhhhh well there it is.

I thought that one was a C, which they added some specific capabilities/designs for cruise missile intercepts. I presume it had some ground avoidance mode

Just so it's clear, that roll at the end happened AFTER the tracks trashed and I went defensive. The only maneuver I did during the TMA period was roll Port and hold a crank. You can see the artificial horizon on the TID. You can see it has that track way over on the right side of the TID which is pulling the TMA to the extreme edge of the gimbal, and eventually trashes it. Its really easy to see with discrepancies in Azimuth, but honestly the worst examples are when this happens with Altitude. There is nothing more frustrating and potentially game ruining as having a target at 30 miles, 1,200knots closure, under TMA, get trashed because something 90 miles away popped up and pulls the radar down. It obviously screws up your timeline, and then you die. I have another example from last night I need to record. But in short, there was a TMA on the left and a Track on the right... Once the right track dropped the radar snapped back to have the TMA center mass again. I had the thought that the computer isn't applying different weights to TMA tracks and queued TWS tracks... Sounds like that is what you were saying. For differentiating more hostile threats - I had thought that since it does have some logic for re-ordering 1,2,3,4 based on Closing speed, distance, etc. That it could weight target 1 more than target 5? but I guess not. It would be interesting to see how the computer decides who is target 1,2,3 etc.

Using relative aircraft positions and approximate closures we can make some educated guesses/estimations: 8 Miles from Fox 3 to A Pole is approximately 24 seconds (1200 closure) to 29 Seconds flight time (1,000 closure with a modest F-pole maneuver while retaining doppler). This is just about when the motor would burn out 4 Miles from A pole to F Pole is approximately 12s-15s flight time (same conditions above). This looks like a TGT Normal shot. This is a total flight time of 36s-44s at alt = ~2k thats only going to work on a very compliant bandit, as at 36 seconds it impacts at M1.1, but at 44 seconds its off the chart and is probably 0 airspeed at alt = ~20k you have a speed band of M2-M1.2. That's pretty lethal, but they could probably turn cold if they performed a proper F Pole Maneuver at alt = ~40k you have a speed band of M3.5-M2.5.... Prey to whatever deity you have. I think the in-game Phoenix has always underperformed here honestly (probably due to guidance). There should be little to no escape and I hope that changes. Note: This does not specifically take into account the target altitude. Its just a rough guide based on the Whitepaper: http://media.heatblur.se/AIM-54.pdf and the above assumptions. Assume co-alt. The question now becomes if the rest of the missiles in the game follow the same rules of physics, of which I am highly skeptical - but hey. Nobody is going to smack talk the Tomcat now.

Well I'm at Zone 5 hearing that. You're just going to have to be faster, disciplined with altitude, and conscious of target behavior.

Thanks! It looks like Active tracks have 5 points of weight. Which with 5 targets, is acceptable. But with the maximum of 24 targets, its 23 v 5, so the computer says - Not as important as tracking those guys way over there...

@Naquaii Opening up a new thread on this per our other exchange. Appreciate it, as always. With the changes to the Phoenix, Potential new API and INS/Active capabilities, and hopefully some guidance fixes in the near future, its going to be ever more important to make sure that the missiles you fire actually go active and have a chance of connecting. There are multiple issues which plague the AWG-9 and have for a very long time, but were hard to track down and form a good hypothesis on, but are the source of frustration for most of the complaints about both Jester, and the AWG9. Having several thousand hours in the simulation, i've noticed patterns, and have been recording them. I'll try to make clips of all of these, and happy to work on some way of reproducing or finding track/tacview files. Just let me know what you need TWS-A weighting causes the most threatening target to often be removed from its volume. Active Missiles being pulled out of the scan volume by new contacts appearing at extremes of Azimuth and/or Elevation is the worst of this bug. This is the first one I'll cover in hopes we can track down a resolution. Momentary 'network' issues causing targets to look like they are traveling very fast and disassociating otherwise compliant targets. I don't know how you solve this. Perhaps smoothing out the requirements to maintain a lock to be slightly more forgiving than the real life radar? Sometimes the track will simply not display a TTI - It is in TWS properly, and once the missile is fired no time indicator will display. Sometimes if you wait long enough it will appear with an inappropriate number (120 seconds, for a 20 mile shot) and then rapidly count down. I think this is associated with the issue above, where if you fire when that target is having network issues it screws up. I also have this one on video. Getting TWS Tracks/Jester Operation. Jester is not particularly smart about "High" contacts and will not scan/find Data Link/AWACS targets that are 30,000+ at <40mi unless explicitly told to do so. He should recognize that data link contacts are also a threat and TWS Manual to the largest threat. Once you do find it, it is often subject to the same weighting issue once you get a track. This is just a quality of life thing but also causes some real head scratching moments where you cannot get a track without a lot of knowing how to fudge jester's operation- IE Telling him to scan up at 45,000/ feet on a 30,000 bandit so he wont start picking up low contacts. To Illustrate what I am talking about, here is a horrible set of diagrams, and a video i've compiled of 3 scenarios which all happened in the same session last night. As I had said before, this happens multiple times a day every day. Its a pervasive and repeatable issue. Track built on bandit at Alt-3 band, prioritized as #1 target Track built on bandit at Alt-2 band, prioritized as #2 target New target appears at Alt 2 band but further away, prioritized as #3 Target, TWS-A slews down, now bringing targets 4-5 in the Alt-1 band into the volume TWS-A slews down, causing #1 target to be removed from the volume, and the track is trashed. This regularly happens with TWS Tracks and fairly consistently even with Active missiles. This happens in both Altitude and Azimuth adjustments Here is an issue illustrating some examples of this in operation (I've removed the audio because its 99% me using profanity when these issues occur):

This happens on a daily basis but ive been trying to isolate and replicate it. I think I have it. I can provide lots of videos though. Its hard to get tracks because it usually happens on GS or somewhere crowded but i've been planning to make a separate thread.

The issue is now that the AWG9 has problems weighting its fired missiles appropriately, and will move the TWS-A cone outside of its active track in order to pick up something it just saw on the extreme other side. I'm unsure if this is the correct behavior, but I assume it is not and it should be ignoring new contacts while there are 1-6 missiles out. It certainly shouldn't be putting your only active target on the absolute edge of your radar cone. You cant hit a target when you have all sorts of issues with small perturbations in network trashing locks, weird bugs where the TTI indicator doesn't show up and the missile is stupid off the rail, and hold-tracks not working because they are implemented as a hack rather than a complete feature due to needing the new API to function properly. INS guidance and the other features we should have available should help- But this has been the long tent pole for a while. Who knows when ED will get around to making that stuff, but maybe this will light a fire under the move to the new API instead of fooling around with the old one which is essentially wasted time.

They already specified this is only true in a straight line. The issue is when it has to maneuver is now inaccurate and loses far too much energy, and does not maneuver to target properly. It should perform (hopefully) closer to what it looked like at release before whatever changes happened that caused it's over performance, it will still out range an aamram. We just have to wait for a fix. Hopefully soon.

@IronMike That's good to hear and appreciate the response.

To be honest, it is really quite bafflingly inconsistent right now. I'll refrain from calling it useless, but it's maybe slightly better than useless. Im compiling some examples, but it is overtaken by an aim7 or even the firing aircraft against targets inside 10 miles sometimes... You will see it often wobble back and forth like it can't decide what path it wants to take to the target- this is primarily during PSTT launches. Something is definitely wrong with the guidance. TWS is definitely incredibly reduced but 30-40 mile kills are still possible, but I Don't see how it could be performing any of the test shots the HB had listed as benchmarks. I can't say with 100% confidence, but I'm pretty sure the Phoenix should out range the aim120 a/b/c5? My concern is that guidance is out of your hands and that means we are all at the whim of a third party who has many irons in the fire already to fix it.... Who knows when ED gets around to it. It's also the case that you guys have had moving this over to the new API as a priority on the public roadmap for a long time, so I presume there are still things ED has yet to provide you with in order to do it... Or it's just simply not possible yet. Could you set any expectations as to when we may see a fix on this... While it's not "useless" it is absolutely hobbled.

Thats the question. It's got significant deficiency in guidance, but that's not up to HB. It seems to more closely match the CFD in a straight line though. Edit- corrected.

@Naquaii @IronMike That was very quick turn around. Thank you. Could you guys provide any data around what you changed and your testing data? It would be good to see how close it is to the CFD now, and where you expect changes when it eventually ports over to the new API. Anecdotally, people are reporting it's a pretty significant change- but most importantly, let's help build the consensus that it's accurate so we can all move on to other things appreciate it

When we get the naval variant, can we get Ens. Jester as the character in the official campaign :-). I figured he flew f4s before tomcats.

E-TF [113] Doormouse/WhiteRabbit F-14 A RED

Unfortunately, DCS is single CPU thread, and single thread speed is king. I've seen massive improvements overclocking my CPU. More so than GPU/Ram/anything. Disclaimer: Overclocking can damage your CPU. 4.20ghz is pretty slow for that chip.... My 10700k im running at 5.1 pretty comfortably, and saw a pretty significant increase in VR performance. https://www.anandtech.com/show/16857/overclocking-with-intel-rocket-lake-four-core-i911900k-binned-and-analyzed/7 You should be able to push much faster than 4.2ghz. Provided you are cooling properly. Do so with care. Also turn your grass off, who cares. you wont see it at 10,000 feet. And experiment with turning the trees down. Due to the increased Radius, the greater the range, the more things that need to be rendered by a squared factor. (Circle Surface Area = πr²). So you arent rendering 2x as many trees if you double the radius, you are rendering 4x as many. They really do make a hit on performance as far as shimmering goes - If you find a solution to that please let me know. DCS looks like Absolute ARSE when there are buildings or objects with sharp angles, when viewing textures at high angles, everything shimmers. Its really annoying.

As far as I'm concerned DCS is in Early Access until this feature is added.

And the wings ripping off hilariously inside its published safety factor

That would be welcome news. I had not heard this.... and its been the neglected step child of ED's modules for years until they decided to make wings rip off hilariously last patch....

I suspected this might be the case. A RIO had a discord event a while ago and mentioned it... but I got the impression it maybe wasn't documented. I was hoping you knew more about it