Jump to content

gyrovague

3rd Party Developers
  • Posts

    189
  • Joined

  • Last visited

Everything posted by gyrovague

  1. That's interesting I was under the impression the common factor for the few people encountering this issue was multithreaded DCS.
  2. It seems like it's still not included in the openbeta distribution, I'm not sure why.
  3. 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.
  4. 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.
  5. 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:
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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).
  11. 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
  12. 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.
  13. 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.
  14. Pretty much what @Golo said above, tracking the leading edge, centroid, or trailing edge of pulse returns in P-STT.
  15. That effect of the aspect switch on P-STT behaviour is not modelled in DCS F-14.
  16. Yes, pilot will need to ask Jester to set it. We could consider making Jester decide in future, but that's far more work.
  17. Added Jester option to set aspect switch, and defaulted the switch position to nose aspect. This should be available in the next openbeta.
  18. @SgtNathan@Aries144 Have you guys tried using a powered USB hub for the MSFFB2? (grasping at straws here...)
  19. I think this sounds quite intriguing, and another avenue to explore towards trying to reproduce and resolve this. I'm speculating very wildly now, as I'm not familiar with this part of the code at all, and don't have FFB myself, but perhaps we are somehow sending FFB updates to the joystick every graphics frame, and over a slow USB1 interface, and with a driver from the 1990s or something like that. I can imagine something like that potentially resulting in buffering of IO etc. If so, it should be possible to rate-limit such updates to say 25Hz or something (again, I'm making up numbers here for the sake of argument) to perhaps solve the problem. Edit: the above is probably totally wrong... it seems DCS queries our code for values of various FFB settings (e.g. pitch and roll deflection forces, shake amplitude and frequency etc.), and we simply return values for each of those (with no complicated calculations or anything that looks like it could explain some slowdown). Not sure what the issue could be then, and I don't have FFB to even try anything. Perhaps F-14 is the only module that returns shake effect values or something?
  20. This is fixed internally now, should be available whenever a new openbeta is released.
  21. I'm seeing this thread now for the first time... I was not aware collision steering was not working correctly, I'll add it to the bug tracker.
  22. Yes, IIRC it will use TCS lock (if it exists) if there is no radar STT lock, but it will essentially just pass the initial angles to the missile and set it to active immediately.
  23. Near_blind is spot-on, in P-STT the missile seeker is only slaved to the radar angles but the missile is active off the rails, and not supported by the F-14 radar further at all. One minor note is that the list of phoenix/radar launch conditions is now slightly different, following the recent TGTS size addition. The 10NM everywhere is replaced with 6,10,13 (for TGTS size set to small, normal and large respectively), and the TTI is no longer relevant, it uses that same distance metric. Let x be the range as determined by TGTS size switch, then: - TWS with range >x: LTE (launch to eject) 3s, loft if necessary, SARH/DL, missile goes active at range x from target - PDSTT with range >x: LTE 3s, loft if necessary, SARH/DL, missile does not go active (SARH/DL all the way to target) - TWS or PDSTT with range <x, or PH ACT selected: LTE 3s, no loft, active directly after launch - PSTT or BRSIT or (ACM cover up with no track or PSTT or PDSTT): LTE 1s (unless STT and angle >15deg then 3s), no loft, active immediately
×
×
  • Create New...