Hextopia

I'm also getting this issue, but it seems to pull the "ghost reflection" from the VR hangar, so the "glare" changes to a shadow of whatever I was last looking at in the F10 map, server browser, etc. It only occurs on multiplayer, and I can't seem to disable any graphics settings and remove it...

If I remember correctly swapping to RWS and back to TWS should reset it to manual. Check the other threads on it in here, they've got way more info.

This bug is already reported in here, it's caused by trying to tell jester to change elevation while in TWS:A. You need to switch to manual or RWS prior to telling him to change elevation, then you can swap back to auto.

Problem is you can't (and won't) be able to hit DCS AI with TWS shots easily since they treat it just like you had them in STT and fired. They're aware of the missile the moment it leaves the rail. So it's generally more useful against players, but with how unstable DCS MP is right now compounded with this TWS bug and how vulnerable TWS is to lag in the first place, I find it's often smartest to just wait till they're closer and STT launch the phoenix to make sure it doesn't get lost due to lag, but at that point you've only got a longer range AIM-120 that can't be used reliably in TWS and gobbles up chaff, so against decent players it's fairly limited in what it can do.

Is there any chance to do a sort of "sanity check" for lag where you look to track the "true" velocities of the targets from the server and clamp false targets when the server appears to be telling you targets are accelerating at insanely high rates (that couldn't be possible) it might not be true behavior, but it would make flying the F-14 bearable using TWS until we get some more stable multiplayer. It's honestly gotten so bad that I've been flying with phoenixes and using TWS extremely rarely, and when I do I almost always lose the shot to lag.

That might be caused by TWS-A flitting around trying to find the optimal scan area. Have a human rio sit in back and monitor it and you'll probably find it's moving the TWS scan volume around a lot.

Make sure you don't also have something bound to the master arm switch cover two position switch abstraction as well.

Based on more testing in singleplayer, it looks like it's almost exclusively caused by targets located close to each other, and the TWS track generator freaking out and thinking two or more nearby target returns are actually one extremely fast target. This can also be triggered by a single target defending hard enough that it's picked up multiple times in one TWS scan, or the F-14 maneuvering enough to cause the same effect. This is doubly troublesome in multiplayer where even a tiny amount of lag can cause subtle rubberbanding, which can ALSO cause the same issue. Compounded with the previous effects, this makes using TWS in multiplayer very difficult. Edit: The AWG-9 has trouble breaking out targets in TWS until they're about 2.3-2.5 degrees separated in AZ/EL (even if they're significantly separated in doppler return) when they move into/out of that threshold there's a chance the weird ghost targets show up, or more accurately it seems that anytime the TWS has to make a determination on whether they're one or more targets, it can cause this problem. Also interestingly, targets within 5NM of each other and within that ~2.3 degree AZ/EL area are shown as one return in RWS or TWS, but will show up very clearly separated in PDS if their speeds are different. This is especially curious for cases where there are 5+ targets within 5NM of each other, as they show up as a single tiny bar on the DDD in RWS/TWS, but will show as a large blob in Pulse search or PD search (assuming they're at different speeds).

I think you've found one of the issues right there. It looks like the radar is assuming those nearby targets are actually a single moving target, which is what's making it freak out and generate lots of ghost targets. I don't think that should happen, but it's just my guess that the designers would have optimized TWS track generation for multiple non-maneuvering targets near each other.

Me hitting into A/G was actually just a mistake, I usually fly in VR, so using Trackir was causing me some issues controlling where I was looking, as I also have no way to zoom bound. A similar situation happened in an earlier run where I only flipped it to A/A to fire off the missiles. As best I can tell, things that make it more likely to happen are: Firing a Phoenix Target maneuvering hard F-14 maneuvering (especially rolling) Multiple targets near each other

You sort of have to do some of the work for Jester, as he doesn't take any initiative. If the contacts aren't co-altitude with you, he won't automatically have the radar elevation set to find them, so you'll need to tell him to set it correctly so he can see them.

https://www.twitch.tv/videos/596842092 Here's a quick video in singleplayer of it happening. The test has multiple pairs of F-16's flying a generally flanking course in and out of the notch, with a few set to defend if fired on. After firing phoenixes, the non-maneuvering targets suddenly spawn a huge amount of false contacts, whereas the maneuvering targets simply disappear and leave a ghost contact as they enter the notch and start defending. Edit: First time the highlight screwed up in getting created. Edit2: Twitch doesn't seem to want to create the video properly, so here's the original video link: It happens from about 0:43 to 1:20.

I'll try and reproduce it in single player and get a track or stream of it happening if I can. I do know something similar will happen if the pilot or server is lagging, but it's generally less severe. Speaking of the radar getting weird with closely grouped contacts, do you know what that range is before it starts trying to group contacts together?

No, what's shown here are two non-maneuvering targets who were flying straight and level. The right target was hot, we're approaching him from his 11 o clock. The left target was also hot, nose onto us, but both aircraft were flying relatively slow (250 or so knots), and we're also in the middle of climbing, so we're at a relatively low speed as well (200 or so knots). Those insanely long relative velocity lines would indicate the target is flanking us at well over 2-3 times the speed of sound, which just doesn't make sense.

Attached is an image from an op we flew tonight that shows just how bad this can get. This is a shot of the TID with us in TWS Manual looking at two non-maneuvering enemy aircraft just prior to us hitting our launch distance. This doesn't seem like normal behavior at all, and I'd really like a response from someone at Heatblur on if this is/isn't intended behavior. Edit for more info: These aircraft were both roughly co-altitude and hot on us, but the TWS tracks that spawned out of them are flying off to the right/left.

It would help if you either removed the stick from view (backspace) or watched the track file instead so you can monitor the bandit and the TID to find out what's actually going on.

As has been posted in the thread already, you can test targets close to notch who maneuver and this specific behavior doesn't happen. You'll lose targets as they go into the notch, but they just fade out and reappear once they come out of the notch. This behavior is specifically talking about the TWS track compiler freaking out and either extrapolating the track as suddenly going Mach 30+, generating 5+ tracks out of nowhere and then immediately fading them all out, or generating 1 or more tracks in the exact same place/heading/speed as the current track while losing the current track. None of which seems like realistic behavior... TWS-A makes some of these especially obvious, as the computer will freak out and jiggle the radar azimuth all over the place and flicker back and forth between the TWS scan types as it struggles to keep track of an extrapolated target going hundreds of NMs per second.

If it's the same issue reported here: https://forums.eagle.ru/showthread.php?t=260806 Then it's not fixed yet and I and the group I fly with are still having the same problem. We're still trying to narrow down what exactly causes the TWS track loss, as it's not 100% consistent, but it does seem to mostly happen in Multiplayer.

I have a feeling this has something to do with the update rate of the radar simulation, and might be made worse by the multiplayer syncing between the rio and pilot regarding the radar. This is really something that needs a look from Heatblur so we can figure out if we're crazy or not.

I'm saying if you overspeed them, the LE flaps (technically slats) get stuck out and shake the plane to death while you're above flap speed.

Make sure you're not flying with your flaps down, or that you haven't spawned into an air spawn with the flaps out. If you overspeed the flaps and get them stuck extended, the plane will violently shake until you land and repair it (or get a new plane).

Have you tried wiping your windows device manager IDs for peripherals and starting fresh? It might be an issue where DCS is confusing multiple device IDs?

I mentioned it earlier in the thread, but I tested this in singleplayer with targets at/near the notch and didn't ever see it show up. I think it's a bug with the RADAR generating new tracks because it either incorrectly extrapolates the target's velocity, or it incorrectly computes the target's position during a sweep. As mentioned by others, I see this happen routinely while flying straight and level, and it's become quite common during missile flyout for the AIM-54, so much so that I've just stopped using TWS to launch on targets, as more often than not the TID gets filled with garbage contacts and and I lose the originally tracked target during the launch, even when continuing to fly straight and level.

I have this same issue when landing the Viggen. I can't use the brakes during landings unless I lightly apply them, since the wheels lock on one side and cause serious yaw instability. This causes an issue where you can't perform a max effort stop using full brakes and thrust-reverser, or use brakes almost at all when landing on a road. I'm not certain if this is normal aircraft behavior or just a quirk of DCS though. Are brakes used during initial touchdown at landing, or is it thrust reverser only?

This is absolutely wrong. You can test this yourself by loading a mission in SP with targets set to leave their jammers on all the time. The AWG-9 has no issue tracking them in TWS and does not cause ghost targets like this, regardless of if they're near the notch, closely grouped with other contacts, banking and cranking in a fight, etc. I've done extensive testing on this to confirm it's absolutely not jamming. Also, you can read the manual and see plain as day it states what jamming indications look like, and that they aren't currently modeled in-game. This is the exact kind of thing I was talking about earlier where the community doesn't know how the AWG-9 actually works and just assumes this is correct behavior.