gyrovague

That's interesting I was under the impression the common factor for the few people encountering this issue was multithreaded DCS.

It seems like it's still not included in the openbeta distribution, I'm not sure why.

OK, so it looks actually as though this TCS (potential) fix did not end up in DCS 2.9.0.46801, despite it being included in the changelogs, so hope still floats for this. There may be a DCS hotfix release sometime soon, then the TCS (potential) fix should end up in that.

Ugh, that's a pity. I'm going to double check whether the (potential) fix did indeed get included into DCS 2.9, since there was a bit of uncertainty around the merge window with the postponed release.

We don't really know, since none of us (or extended tester team) could reproduce this at all (and it seems pretty rare in the overall playerbase). From the various posts in this thread, it seems to affect certain people on certain maps, and also not always for some (and always for others). The (potential) fix is not settings or map related however, it was (maybe) an initialization order problem with multithreaded DCS. So basically:

Curious to know whether latest OB from yesterday fixes this TCS issue on multithread for those that encountered it. Nobody on HB team was able to reproduce this, so unknown whether the potential fix works or not.

A potential fix has been submitted -- nobody on our team has been able to reproduce this error, but we spotted a way in which it might be able to happen. Note that it could take up to 4-6 weeks for this to become available in openbeta, keep an eye on the DCS F-14 release notes for this issue.

Nicely done!!

This has been fixed internally five days ago, but it didn't make it into the openbeta hotfix patch today unfortunately. It seems ED maybe didn't notify any 3rd parties of the hotfix build, judging by lack of patches to other 3rd party modules.

I spent a bunch of time trying to reproduce this TWS with PH ACT issue in SP and MP, to no avail. As far as I can tell, the logic all operates correctly, so I'm also surmising that the issue is due to packet loss or reordering over internet MP. We don't have any control over the netcode of course, we simply launch a missile with an API, and call another API function to set it to go active. If that packet indicating it must go active is lost or reordered (e.g. arrives before the missile creation packet for instance), then of course one side will think the missile is active and the other side will not. We'll ask ED whether there is some way we could improve this, e.g. perhaps calling active periodically (I suspect right now it would only send a packet if active changes, so repeatedly setting it active most likely won't do anything) or calling it only a while after the missile has launched instead of immediately etc.

OK, thanks for the report, this sounds bizarre... we'll need to reproduce these steps to see what's going on, but with Phoenix Active selected prior to launch, it should be launching active from the start, and not get sent active command later (and tgt size switch shouldn't be a factor then).

Yes, yes it is possible. and should now be fixed.... Looks like this .. .. got introduced when we added a wrapper to the missile APIs to cater for both types (since we're in the process of converting the phoenix to the new). Look for this in next openbeta. I don't personally (have time to) monitor that forum thread unfortunately (or fortunately, as the case may be), but I've not seen issues logged about it in our tracker Will follow up about it, but usually that means it's not locally verified or so... however, perhaps (most likely) this hoj/loft snafu explains and fixes it all, as you mentioned

Phoenix RCS has been dictated to us by ED. We're looking into how to ameliorate this situation. TCS sync between RIO and pilot is on our issue tracker, but non-trivial to fix unfortunately. That said, the next two locking TCS sync issues you mention are not known to me (not on our issue tracker). Phoenix: this is in the process of being converted to the new missile API, hopefully this will solve many or all of the sync problems (although there are also reports of similar issues with AIM-120, so time will tell). The two TWS shot issues are not known or on our tracker AFAIK.

AFAIK, these issues have not been reproduced or logged as issues on our side. However, we have finally gotten rid of the copied AIM-7 lua. We previously had to copy those because the 45deg axially rotated sparrows used to eject diagonally, but this has been fixed on ED side. Our copied versions were sometimes out of sync with upstream updates, so it may be that sometimes strange things could happen Hopefully () now that we're using the ED AIM-7, the behaviour of them will always at least be the same as the AIM-7 on the other aircraft. This should be available in the next openbeta.

Pretty much what @Golo said above, tracking the leading edge, centroid, or trailing edge of pulse returns in P-STT.