DoorMouse

I saw that, and what a great shot. The Aim54 is definitely is better at altitude, even if its slower, because that terminal guidance isnt doing wierd 50 degree pulls dumping all its energy. That being said, that guy was super compliant.

This is the crux of the issue. ED wont accept anything less than a track file, and 50% of the track files you send seem to be corrupt when they try to use em.... that's if you can even get em from a busy server. I think Hoggit allows you to have your own track file but places like GS, 104, DDCS, Enigmas all block telemetry to prevent exploits. So you dont get a useful track.

The doppler filter is ~140 knots closure, this is maybe an exaggeration, and part because I don't think Jester properly manipulates the beam/hot/cold filters properly? Maybe he does i dunno... but if someone is beaming you they are probably actively defending and likely to lose lock quickly. And yeah, if you try to go STT and your closest target is a Datalink target, they could be behind a mountain for you but visible to the E3. So Jester cant lock him. He just does a poor job of telling you why. I THINK you can use a separate menu for Lock TWS track.... actually haven't tried that.

@IronMike The Angle Tracking is not implemented yet, correct? I was just listening to the Tomcast about this.

Make sure you have a RADAR TRACK already for the target you want to lock... Not a DATALINK TRACK. Make sure the target is Doppler Hot, probably over 800-900 knots closure. Otherwise he is flanking and in/out of your filters Don't use "lock enemy/lock target" unless it is in front of you and has an active radar track. Usually this doesn't work anyway unless it's a perfect target profile. DO use the "lock specific target" and use the yellow radar tracks not the blue datalink tracks The issue is jester doesn't say, "can't lock him, he's behind terrain" or "<profanity> he's in the notch". So you have to be aware of why he can't lock him, and I've rarely had an issue where I didn't understand why he can't pick up a lock.

Dcs models RCS values as a single coefficient. Orientation does not matter

Oh no... I love the jester wheel in VR and the granular controls. I have them basically on muscle memory now and can do them very fast. It's actually one of my favorite features. If you ever significantly change it please add an option for legacy mode maybe. I dunno. I only wish he could PH Active and re sort tws targets.

Just to confirm, when the timer starts flashing, that means the AWG9 has sent the pitbull instruction. Correct? Even if the time is inaccurate, the flashing is always the Pitbull command?

yeah all the missiles in game say AIM54C At least have an A model Not that anyone can see it when they slam into you

$20 in the jar per Top Gun reference

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.