gyrovague
-
Posts
189 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by gyrovague
-
-
8 hours ago, draconus said:
Is the fix supposed to be in 2.9.0.47168 hotfix? I'm still affected.
It seems like it's still not included in the openbeta distribution, I'm not sure why.
-
1
-
-
3 hours ago, gyrovague said:
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.
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.
-
1
-
1
-
-
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.
-
40 minutes ago, Nealius said:
but is this map/settings-related?
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.
-
3
-
2
-
-
Nicely done!!
-
37 minutes ago, Karon said:
EDIT: the forum ate the quote, neat. This was meant to be a reply to @bonesvf103, who said that the second row looks fine. It still looks bugged to me.
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.
-
1
-
-
On 8/21/2021 at 5:12 AM, DoorMouse said:
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.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.
-
6
-
1
-
-
On 8/17/2021 at 2:28 AM, DoorMouse said:
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.
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).
-
Steps to Reproduce:
-
49 minutes ago, near_blind said:
Is it possible whatever tells the missile to loft got mixed up with whatever tells the missile to HOJ?
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.
50 minutes ago, near_blind said:For real? There's been a thread in the bug forum since at least February and a thread pops up about it at least once a month. We can get you tracks if you need them.
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
-
4
-
2
-
-
On 8/15/2021 at 5:37 PM, DoorMouse said:
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
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.
-
On 8/15/2021 at 11:15 AM, UWBuRn said:
I can confirm Sparrows are still quite bugged.
Tested against rookie AI Su-27 with and without ECM, always shooting around 18 nm.
- AIM-7F => ECM: no track - straight off the rail
- AIM-7F => No ECM: the bigger the distance the smaller the chances it tracks, over about 10 attempts just once tracked correctly at 18 nm, 16-17 nm it's more or less the limit for reliable shots
- AIM-7M => ECM: no track - only executes loft maneuver then goes straight
- AIM-7M => No ECM: ok but is lofting
- AIM-7MH => ECM: ok
- AIM-7MH => No ECM: ok
Didn't test thoroughly ACM cover and flood mode, but for sure 7F don't track jamming targets even there.
@IronMike thoose issues have been around for a long time now: are they being actively looked into or there's some blocker before them?
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.
-
11 hours ago, Harlikwin said:
So... What effect does it have?
Pretty much what @Golo said above, tracking the leading edge, centroid, or trailing edge of pulse returns in P-STT.
-
On 6/24/2021 at 6:13 PM, Golo said:
It should do something according to the manual:
In the short pulse STT modes the aspect switch sets the system tracking mode to the corresponding echo edge or centroid to counteract countermeasures like chaff and specific jammer modes.
However that works.
That effect of the aspect switch on P-STT behaviour is not modelled in DCS F-14.
-
On 6/24/2021 at 1:40 PM, Lurker said:
Can we get a bit of clarification here? Does that mean that Jester will not be able to set the switch automatically, I.E. Jester will not be able to calculate the closure and set the switch accordingly, but that the pilot in front has to tell Jester to set the switch, otherwise it will always be in nose aspect position?
Yes, pilot will need to ask Jester to set it. We could consider making Jester decide in future, but that's far more work.
-
1
-
-
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...)-
2
-
-
On 5/6/2021 at 8:59 AM, SgtNathan said:
In this test, I can remove the input lag issue by software limiting my game's FPS to <50. On the flip side I can also exacerbate the issue by putting all settings to the absolute minimum, pushing my FPS around 200. This can cause up to a 10 second delay at times.
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?
-
1
-
-
This is fixed internally now, should be available whenever a new openbeta is released.
-
4
-
-
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.
-
3
-
-
5 hours ago, captain_dalan said:
Can the 54 be slaved to to a TCS lock?
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.
-
1
-
-
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-
2
-
2
-
-
12 hours ago, Xeno426 said:
Now that the Target Size switch actually has a use, could we get some keybindings for it?
Especially those nice "x, else y" binds for Warthog three-way switches.Done
-
2
-
[DCS ISSUE] TCS and Multithreading
in Bugs and Problems
Posted
That's interesting
I was under the impression the common factor for the few people encountering this issue was multithreaded DCS.