DoorMouse

This is absurd. Air to Air missiles intercepting eachother is not in any way realistic or intended - this is a bug. And as a point of clarification, a tomahawk cruise missile is TWICE the size of a phoenix missile and will have an even larger RCS due to the wings.... and it is incredibly challenging for missiles to intercept those. Having SD10's intercept Phoenixes or 120's is complete nonsense.

God, I hope we get Hawks for the IRAF tomcats

E-TF[113] Doormouse Mig29

If you can VID a Phoenix, you have bigger problems but yeah this one would be cool to get models for.

This is my anecdotal experience as well. I feel like the radar needs to be less sensitive to network issues. I hypothesize what is happening to be that the real radar has a refresh rate and sometimes the network data runs afoul of that. I also still get issues where the hud will lock things and the diamond is somewhere nonsensical. They did a great job syncing the TCS with pilot and Rio in the last patch, I'm hoping these are solvable too.

This always drops tracks for us, even on non-maneuvering targets. its a major annoyance. It seems to be much worse on multiplayer with many players. My hypothesis is that the AWG 9 has a very sensitive requirement to "hold" a track and needs constant updates that heavy multiplayer servers cannot provide - So your local simulation thinks it has lost the track, when really it is that the MP data hasnt gotten to you yet, or is the wrong tick-rate, or there was just a temporary network slowdown/loss. Switching to TWS Auto is a partial work-around sometimes - It seems to work better- but it shouldn't have to be.

Awesome patch, and thank you and the team for taking the time to look at our report. Appreciate it!

Thank you, and awesome this is getting resolved soon! Also great information on the CW/flood when Slaved to the TCS, that is so cool! I'm looking forward to the TCS STT modes being implemented

Which requires nose hot and you can't guide a Phoenix. It also is limited to less than 3 miles or something. It's pretty close range, different use case

If you lost radar lock. Often at less than 30nm the TCS does a better job of tracking than the radar if they go to the notch. The Camera will track the target just fine- Fire off a phoenix in their direction to keep them from going Hot. for one. Its a neat feature, but very very situational.... frankly I have no idea how its supposed to exactly work. We would need an SME

So, from what I've been told is you can fire a PH active with a TCS lock and it will maddog it with the correct angle and elevation. It is also potentially a way to guide a Fox1 because you are slaving the radar AZ/EL to the camera track. SAHR in Flood mode doesn't need ranging Information, so the question is can the CW illumination be used in this way for the Sparrow (which I think not?), And can the Phoenix follow it's Pulse Doppler illumination when Slaved to the TCS (Which I believe maybe not... It needs ranging info) it could be the case that it too just goes PH active automatically But I've not heard an SME talk about either of these. You probably should still get a lock warning... But potentially not. It depends on the radar duty cycle, and if that mode is the correct illumination.

I've seen this too, was going to put this in the queue to do some reproducibility testing, but I was under the impression this was reported.... I hope it has been. Which is unfortunate because the TCS/radar Slaved mode is a unique, very situational, feature of the tomcat.

Sent, thank you!

I have all of the tracks, but no way to attach files that large. What is the best way for me to get them to you?

https://www.dropbox.com/s/2s5x660zgrx6krj/Public Release Missile Test.docx.pdf I have lots of documentation on this now, and a weird edge case that I've tracked down that may explain it. I have a version which I want to send you and anyone on the HB/ED teams that wants it, which has the methods section, as well as video documentation of how to reproduce this. I do not want to disseminate that information in such detail publicly. Please let me know if you have any questions. I'm happy to help track this down.... but the TLDR is that this is not due to net-code. The shooter and the target are being given different sets of information, and it's easily reproducible. I am now working on getting you some videos/trackfiles of non-maneuvering hot targets with 1000+ knots closure having their tracks drop.

TLDR: in 100% of tests the RWR gave a warning There was only a minimal 'desync' when the missile worked properly, and we have found a way to replicate proper behavior which will be in the next set of tests. Basically, restart the server and the First shot seems to work the same for Shooter and Observer- subsequent shots do not. Shooter and Observer get different initial vectors for the missile heading and this causes the Shooter/Observer's independent simulation of the missile to have different flight paths, speeds, and locations when the 'Kill" event happens. This is not a network issue, this is the two clients being given different information I will be posting follow up videos later. I have intentionally removed the steps required to reproduce this issue as to not proliferate its use. I hope this helps. I've posted this on both the Heatblur Bugs and ED Weapons Bugs forum. Public Release Missile Test.docx.pdf

TLDR: in 100% of tests the RWR gave a warning There was only a minimal 'desync' when the missile worked properly, and we have found a way to replicate proper behavior which will be in the next set of tests. Basically, restart the server and the First shot seems to work the same for Shooter and Observer- subsequent shots do not. Shooter and Observer get different initial vectors for the missile heading and this causes the Shooter/Observer's independent simulation of the missile to have different flight paths, speeds, and locations when the 'Kill" event happens. This is not a network issue, this is the two clients being given different information I will be posting follow up videos later. I have intentionally removed the steps required to reproduce this issue as to not proliferate its use. I hope this helps. I've posted this on both the Heatblur Bugs and ED Weapons Bugs forum. Public Release Missile Test.docx.pdf

This is what I suspected. The phoenix does not have any "specific" issues, its just that EVERYTHING has desync issues and since the Phoenix is faster it can travel more time during that interval. In which case this will never be 'fixed'

This is unfortunately what I expected - Its the triggers messing up with Coop and that's just in the core game . I was hoping it was maybe something in the mission files you could fix, because that will be 1000% faster than waiting for ED Sucks for everyone involved- Still having a lot of fun with the campaign though!

If you have a friend in the back, most of the dialogue spams and fills the entire screen, and you hear the audio trying to play over and over and over (just the static mic click plays over and over). Once the RIO leaves the seat to spectator and Jester comes back, the dialogue works again. Given that the Tomcat is best enjoyed with a friend - This is really disappointing https://www.twitch.tv/videos/1124776167

This is "the bug" preventing people from flying Tomcats in SATAL Id love an official response on this one Im still working on compiling a video of the TWS tracks trashing instantly. I SUSPECT it has to do with server/player/rio latency and the AWG9 in game is TOO sensitive to server latency. If a target-client's aircraft lags, if your rio lags, even a little - it trashes your track. Probably because its tested/optimized in single player.

First - Appreciate you responding! I will get together some tracks and build a video compilation and tag you in the post in this thread once I have it. If you will allow me, there is one other Item that people said has been reported that I want to make sure you are aware of. Apologies if it is redundant: Steps to Reproduce: 1)RIO must select Missile Option: Phoenix Active setting pre launch 2) Shoot pre pitbull range, higher the range higher the desync. Keep tracking the target with TWS till the missile goes active ( Could work without keeping track) . Can only be seen visually if its going for the target 3) Once the missile is within pitbull range (Range being dependant on the Target Size switch) and the target is still being tracked in TWS it will snap on them and there is around 2 second difference between the shooter and targets client. Meaning the position and angle of the missile is different on each client. Higher ping could increase this dysync due to client side netcode.

Still a massive number of game breaking issues with the Phoenix. New as of this patch: Phoenix RCS is Excessive and is intercepted by missiles with alarming accuracy. https://youtu.be/zU7kSd2r3R4 Old: TCS sync between multi-crew RIO and Pilot is poor. The camera bounces around for the pilot, rendering it useless Old: TCS and Radar slaved sync between multi-crew RIO and Pilot can create a situation where the pilot is locking a target, but the RIO's client did not get that information Old: TCS and Radar Sync between multi-crew RIO and Pilot can create a situation where the Lock Diamond is placed off the Hud, or locks an area of blank space behind the target Old: Phoenix Hold Tracks still do not always pitbull. Extremely frustrating when this happens 1 or 2 seconds before pitbull and there is no way they have moved 3 miles away from last known in a few seconds (Which is the currently implemented work around) Old: TWS Shots often show no TTI after firing Old: TWS Shots often drop (X) immediately after firing at non maneuvering targets I Love the Tomcat and its flight model is amazing -Weapons operation has consistently gotten worse every patch it seems though

This is all nonsense.... And clearly a bug/oversight. In no universe should an aim120 be tracking phoenixes with near perfect intercept results, and that doesn't explain why the SD10 or other missiles don't do this either. This isn't some intended behavior or emergent gameplay. This is a mistake that wasn't caught in testing.