DoorMouse

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.

yeah.... im pretty sure this is a bug and not an intended design feature. Its a problem for the 120 shooter too, you can use this to stuff their missiles at will.

You can see in this video, and it is easily replicateable - The 120 is intercepting Aim54s in a 20nm head on engagement. I'm not sure what the intent of changing the missile RCS values was, but I'm pretty sure this was not it. The Track File is too large, ill find a way to post it if needed - but this is glaringly obvious, I can find a dozen examples of this happening day one of the patch. https://www.dropbox.com/s/c6jsrsgtqr9tdqn/Tacview-20210811-192307-DCS-Dedicated_Tact_Loadout_PG.zip.acmi?dl=0

Did this make it into todays patch - There seems to be nothing in the notes

The Aim54 can absolutely pull 20g. People hear "it's less maneuverable irl" and then characterize like it's a 20 ton rocket or something.... They don't know what they are talking about. Putting aside that noise, the maneuverability of the Phoenix is not in question, and has nothing to do with Desync... Again 90% of players hear this but have no idea what they are talking about. There are two issues. 1) the state of the game today, all missiles have very poor network sync between shooter and target. I suspect the methods they use to do this are quite old and buried in the 20 year old code.... But what do I know. All I know is the results are poor. 2) the Aim54 CAN have issues like this https://gyazo.com/bdc8ff7a1ff793fa13433badf07ac7fd Where the missile appears to be flying a complete different direction according to the target aircraft. So far all I've heard is that the mythical Missile API will fix this, but it's been years we have been hearing that. What we need is Heatblur to step up and figure out why this wasn't a problem a few patches ago (last year), and how it was introduced. It sounds like they are generally aware of it, but what would be more helpful is the community to submit track files, videos, or steps to reproduce it. Frankly I've never been able to do it myself, but I've seen a few videos and Instructions

Thats the neat thing... You dont. Its not an IFR rated aircraft. It is an actually challenging thing to do. Best thing to do is use Tacan and fly by instrument. Hope there are no mountains

Is it possible for you to post the mission file here so we can replace it manually until the next OB patch (which is next week right?)

Just did this one and was on station over the ship forever and the mission never progressed. Time accelerated until it was completely out of fuel- no event

Remove the phoenixes, remove pylons, add phoenixes - They look like they are floating in the editor In-game the pylons seem to appear just fine.

According to the video Mach 0.8. I was off the burners in a Tomcat A model. Not nearly enough to rip the wings off even if I pulled full stick. We also triple checked the server and my track file. We were not being shot at. the wing just popped off. Again my hypothesis is that some momentary lag or delay caused the aircraft to calculate our G-Force/Position as instantaneously moving some distance. EDIT: OH wait is there a bug with wing sweep sync perhaps? The aircraft momentarily swept the wings full forward?

@IronMike I think the usefulness of this thread has run its course and its just going to devolve. Its not up to me but It seems like it should be locked. Thank you for the HB team acknowledging that they are aware of this. I know its not easy to do but we would all love a timeline from you and/or your partners at ED about when some of these items will be fixed, and when the "Missile API" might be implemented. As to not throw knives into the dark - I'd HIGHLY encourage you to start an ongoing dialogue with the Community members @X-man@M0ltar who are organizing these events. Ask them explicitly what they find to be questionable and what items need to be addressed and how. The first step I think is getting the truth out about some of the community "Knowledge" (I suspect there is a lot of misunderstanding and hearsay) and get feedback from them (longstanding items like the TCS Slaved Radar which have existed since launch). Please. Start a conversation. I am sure it would benefit all parties. Appreciate it, and we (on all sides of the conversation, it would seem) are looking forward to seeing this resolved.