Issue with radar target bouncing around

[Temple]

Ah, it's me again with another question[8|]. I'm playing Operation Trident. One of my INS ships (all radar off) has noticed via RWR that a contact is getting kind of close. So my one near ship goes radar active. This should, based on what I've done in previous scenarios, give me one solid target object since it's well within my radar range. However, something weird is happening. I recorded the sequence and took four snapshots. These are about a half second apart according to the clock at the top of the screen (apparently the recorder individual frames are a half second apart, or maybe a second based on rounding).









All those targets are Skunk #30 bouncing all over the place. The above sequence repeats itself after several seconds.

So, my question, is this a bug? Is it due to only one ship radar being active and some kind of interference with the RWR indications from other ships? I don't think it is, because I did go active with other nearby ships and the same jumping around continued to occur. If this isn't a bug, how do I, as task force commander and ship captain, deal with it?

I've also uploaded the .rec file if anyone wants to look at it.

[ExMachina]

I've seen this before too when I turned on my radar. And the contact was close so it should have been a solid lock.

When I tried to duplicate it I couldn't.

[El Savior]

I have seen this happen many time. Contact change position several times, but my range wasn't close so I thought this is normal. Is enemy using jammer or is sea state bad?

[Der Zeitgeist]

I think it's just the current behavior, with the picture you see on you screen switching around between the different sensor sources. The problem with that is that it also affects the AI using weapons, regardless of the optimistic/pessimistic setting for contacts. So when the contact suddenly jumps to another place, the AI may think that it is now in range, fire a weapon on it that will surely miss.

[Agathosdaimon]

is there a way to ensure that the AI doesnt fire until it knows the correct location - or should one just put everyone on hold fire until something is definite - a risky thing though if the enemy already has you targeted

[Der Zeitgeist]

ORIGINAL: Agathosdaimon

is there a way to ensure that the AI doesnt fire until it knows the correct location - or should one just put everyone on hold fire until something is definite - a risky thing though if the enemy already has you targeted

One thing that worked for me for ASuW missions and SEAD missions was trying to make the patrol zone as small as possible, to ensure my units only engage enemy units within that zone. So when an enemy unit suddenly "jumps" out of this zone, it should not get engaged.

[brassem]

If your target is jumping around, triangulate them from different directions at a time to get a solid bead on them. Obviously they are scrambling your sensors, or your sensors are being fudged by naturals, if you can't get a positive fix.

[thewood1]

I used to have this same issue with Harpoon 2/3. Whether its an issue from a realism standpoint or not, I can't say. But it had to do with units losing contact and other units gaining contact. It always seemed to make a confusing mess.

[Agathosdaimon]

so this is what the whole pessimistic, optimistic settings are supposed to affect? Whether the AI attacks uncertain targets or not? Perhaps this needs to be tightened up ie patchwise?. making patrol zones smaller is an option though i dont always assign my units to specifically created missions

[ExMachina]

Probalby not relevant, but why are there two, overlapping data boxes in the first screen capture?

[smudge56]

If you move the mouse cursor fast it leaves a trail behind it of the data box. Not explained this great sorry.

[bsq]

ORIGINAL: ExMachina

I've seen this before too when I turned on my radar. And the contact was close so it should have been a solid lock.

When I tried to duplicate it I couldn't.

Seen this too. If Command is replicating a high level picture then this should not happen and the modeling is possibly off.

What you should see if the first contact is passive is:

1. Line of Bearing
2. Fix with large CEP
3. CEP gets smaller as fix improves

As soon as someone goes active and assuming the contact is correctly cross referenced, you should now see a radar contact, which WILL NOT JUMP. If it is not correctly cross referenced then you will see two contacts. The radar contact, which still WILL NOT JUMP, and the ESM contact which should continue to jump as its location and CEP improves.

If you are only reporting one contact, then its all about fusion and IRL these things don't jump all over the place.

[kieferpl]

I have had the same problem and I think it comes down to the Command engine/system being too sensitive. In real life if you have a contact under solid radar paint and you get a spurious or uncorrelated ES line on bearing, the track correlation system isn't going to shift the track. Whatever is doing track gridlock for Command needs to have a hierarchy of tracking sensors, if it doesn't already, so like if you have an air contact well within the range of a high power 3D air search radar and you get a LOB from a passive ESM system that is 10 degrees off and estimated range of 40 miles off, the system will throw out the ESM LOB and maintain on the radar position.

[Dimitris]

@kieferpl : You are quite close to the root issue. Not exactly there but close.

[Agathosdaimon]

As this sounds like an engine issue is it one that will be addressed so as to bring it more into line with real life?

[kaburke61]

ORIGINAL: Agathosdaimon

As this sounds like an engine issue is it one that will be addressed so as to bring it more into line with real life?

I hope so. It's slightly annoying watching a contact "bounce" all over the place even though you have it painted with radar/etc. from multiple sources.

[AdmiralSteve]

I don't believe its an issue, it's RADAR/RWR real world modeling. The bouncing I presume is just a way to simulate whats called "Ghosts" which is caused by the RADAR/RWR signal returning in multiple paths and gives a false position. This is caused by atmospheric ducting, ionospheric reflection and refraction, and reflection from water bodies and terrestrial objects such as mountains and buildings.

No, I'm not an OS or FC is the navy, I was a BT so my head really hurts finding an answer. [;)]

[Temple]

ORIGINAL: AdmSteebe

I don't believe its an issue, it's RADAR/RWR real world modeling. The bouncing I presume is just a way to simulate whats called "Ghosts" which is caused by the RADAR/RWR signal returning in multiple paths and gives a false position. This is caused by atmospheric ducting, ionospheric reflection and refraction, and reflection from water bodies and terrestrial objects such as mountains and buildings.

No, I'm not an OS or FC is the navy, I was a BT so my head really hurts finding an answer. [;)]

If that's true, then I would just ask for a way to tell the game engine, which in this instance is acting as the data interface to my ships computer system, to let me select one target data point and ignore the others. I realize that this request (if the assumptions are true) would involve some hefty changes to the game engine, so I could live with it for now. And if it doesn't happen all the time, I could live with it if there is some in-game method to overcome it, like switching off (or on) certain sensors or using some other unit to provide an alternative data source.