Jump to content


3rd Party Developers
  • Posts

  • Joined

  • Last visited

Everything posted by gyrovague

  1. 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.
  2. 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.
  3. 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).
  4. 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
  5. 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.
  6. 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.
  7. Pretty much what @Golo said above, tracking the leading edge, centroid, or trailing edge of pulse returns in P-STT.
  8. That effect of the aspect switch on P-STT behaviour is not modelled in DCS F-14.
  9. Yes, pilot will need to ask Jester to set it. We could consider making Jester decide in future, but that's far more work.
  10. Added Jester option to set aspect switch, and defaulted the switch position to nose aspect. This should be available in the next openbeta.
  11. @SgtNathan@Aries144 Have you guys tried using a powered USB hub for the MSFFB2? (grasping at straws here...)
  12. 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?
  13. This is fixed internally now, should be available whenever a new openbeta is released.
  14. 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.
  15. 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.
  16. 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
  17. The weapon selector on the F-14 stick has the top position as "SP/PH", and the weapon selector press action toggles between those two missile types, so making "up" do it would not be realistic, as there is no further up position on the stick's weapon selector. I suppose if there is sufficient demand, we could add a special option to allow this, so that pressing "up" in the PH/SP position would emulate weapon selector press. (Edit: this feature has now been added) The weapon selector press action is not specific to PH/SP toggling, it has different functions in different positions of the weapon selector. In SP/PH position, it toggles between those missiles. In sidewinder position, it steps missiles (i.e. selects which one will be fired (and therefore also which one provides IR seeker tone to cockpit audio). Between off and gun it needs to be pressed (on the real stick, and VKB (and perhaps Virpil) F-14 grips) to move between those positions because of a physical detent preventing it from being moved otherwise.
  18. The backtrace indicates something to do with simshaker. edit: not sure that's the cause of the crash however, probably not
  19. Thanks for the posts, fixed internally (fix for the first post automatically fixed the second post too).
  20. Is this F-14 specific, or does it happen in other aircraft too?
  21. Some of these things are by design, for example the front rails (3&6) are fitted in a pair or not at all, and the rear rails (4&5) are also a pair AND require the front rails to be fitted (i.e. rear rails cannot be fitted without the front ones, due to AIM-54 cooling IIRC). If you remove either 3 or 6 pylons(rails), it will clear 3,4,5,6. If you remove either 4 or 5, it will clear both 4 and 5. That said, there are certainly known shortcomings/issues in our implementation of the multitude of loadout combinations, and unfortunately many of these issues have no known fix right now.
  22. This has been addressed internally now, so should hit openbeta in a few weeks.
  23. It should only switch to TWS-A if it was in TWS-M when a phoenix is launched. It should not switch to TWS-A when launching phoenix in STT, or BRSIT or PH ACT.
  24. This is the thing that is fixed now, and sounds like nearblind and klarsnow are referring to this too.
  • Create New...