Auto IFF

[Joni]

So watching Wags' video about automatic IFF I noticed that the already interrogated contacts that resulted in friendlty or hostile HAFUs often turned back into unknown yellow HAFUs. I was wondering if it was a bug during the video or if the system really works like that (like losing the HAFU quickly until the next update frame comes in).

 

This is a very awaited feature for me and I felt quite bummed when I saw the video.

[Sarge55]

I noticed that as well.  I was waiting for him to comment on why they switch back to ambiguous.

 

I'm sure there will be an explanation along shortly.

[Joni]

1 minute ago, Sarge55 said:

I noticed that as well.  I was waiting for him to comment on why they switch back to ambiguous.

 

I'm sure there will be an explanation along shortly.

 

Can you imagine using it like that? Everyone will have it off all the time.

[oldcrusty]

I watched that vid with one eye while working on something else so... don't quote me, hehe.  I think it went back to ambiguous when the interrogation range was changed. I'll watch it again later.

[Joni]

Just now, Gripes323 said:

I watched that vid with one eye while working on something else so... don't quote me, hehe.  I think it went back to ambiguous when the interrogation range was changed. I'll watch it again later.

 

Yes indeed. But there were many times were the contacts reverted back to yellow for no reason after blinking for a second.

1 minute ago, Gripes323 said:

I watched that vid with one eye while working on something else so... don't quote me, hehe.  I think it went back to ambiguous when the interrogation range was changed. I'll watch it again later.

 

Wags even says "it got dropped" when changing azimuth, but that should not happen, the memory must keep the HAFU.

[Sarge55]

WIP perhaps.

 

My expectation as a "layman/flight simmer" is that once designated hostile it would stay hostile.  That enough checks and cross-checks have been done to confirm the status as hostile otherwise it should have stayed ambiguous.

 

[Harker]

Without being 100% sure, what I think is happening is that some tracks get dropped completely, so obviously the stored IFF info is lost. You can actually observe the HAFUs disappearing for a moment, sometimes. When the track gets built again, it's a new track, as far as the MC is concerned, so it's Unknown.

 

He's in AMRAAM mode, which by default has a memory setting of 4. Combined with the fact that he's on a 140/2bar interleaved scan, the update rate for some tracks probably isn't high enough and they get dropped.

 

Edit: I think my reply landed at the same time as the next comment. AFAIK, IFF info is stored on the track data.

Edited December 16, 2020 by Harker

[Joni]

7 minutes ago, Sarge55 said:

WIP perhaps.

 

My expectation as a "layman/flight simmer" is that once designated hostile it would stay hostile.  That enough checks and cross-checks have been done to confirm the status as hostile otherwise it should have stayed ambiguous.

 

 

Why launch it in that state? I understand WIP but if that's the way it's gonna work then many of us would rather have it off until fixed. What's the point?

6 minutes ago, Harker said:

Without being 100% sure, what I think is happening is that some tracks get dropped completely, so obviously the stored IFF info is lost. When the track gets built again, it's a new track, as far as the MC is concerned, so it's Unknown.

 

He's in AMRAAM mode, which by default has a memory setting of 4. Combined with the fact that he's on a 140/2bar interleaved scan, the update rate for some tracks probably isn't high enough and they get dropped.

 

I thought that as well, but the thing is that doesn't happen in the attack format. If it gets dropped it will be remembered anyway.

Edited December 16, 2020 by Joni

[Harker]

6 minutes ago, Joni said:

I thought that as well, but the thing is that doesn't happen in the attack format. If it gets dropped it will be remembered anyway.

It does happen, you can notice it sometimes. Most of the time, we don't get a good picture of the Attack format, because it's been bugged for a year now and only displays bricks for detected contacts.

 

Why would it be remembered if the it's dropped? How can the MC know if that is the same aircraft? It's a dangerous thing to rely on the assumption that it's the same.

 

I'm reserving my judgement until after I use it myself, but unless I'm mistaken, it seems to be working OK.

Edited December 16, 2020 by Harker

[Joni]

1 hour ago, Harker said:

It does happen, you can notice it sometimes. Most of the time, we don't get a good picture of the Attack format, because it's been bugged for a year now and only displays bricks for detected contacts.

 

Why would it be remembered if the it's dropped? How can the MC know if that is the same aircraft? It's a dangerous thing to rely on the assumption that it's the same.

 

I'm not saying it works correctly now, but I was talking about TWS and not LTWS which is broken 98%.

 

I'm gonna try dropping a contact and see what happens. I'll report back soon.

Edited December 16, 2020 by Joni

[Joni]

1 hour ago, Harker said:

It does happen, you can notice it sometimes. Most of the time, we don't get a good picture of the Attack format, because it's been bugged for a year now and only displays bricks for detected contacts.

 

Why would it be remembered if the it's dropped? How can the MC know if that is the same aircraft? It's a dangerous thing to rely on the assumption that it's the same.

 

I'm reserving my judgement until after I use it myself, but unless I'm mistaken, it seems to be working OK.

 

 

Confirmed that currently all contacts dropped and regained, retain their HAFU status.

Edited December 16, 2020 by Joni

[Harker]

1 hour ago, Joni said:

Confirmed that currently all contacts dropped and regained, retain their HAFU status.

Yeah, they currently do, but I'm not sure that they should. This is something that's been bothering me from the beginning. How can the MC know that this radar return corresponds to the same aircraft, if the track has been completely lost and that aircraft has moved in the meantime? It makes sense to lose stored IFF info if you drop the track.

[Joni]

39 minutes ago, Harker said:

Yeah, they currently do, but I'm not sure that they should. This is something that's been bothering me from the beginning. How can the MC know that this radar return corresponds to the same aircraft, if the track has been completely lost and that aircraft has moved in the meantime? It makes sense to lose stored IFF info if you drop the track.

 

I agree, but if it works like that now, why would this auto iff thing be any different? That's why I was worried about a potential bug from the start that could be avoided.

[oldcrusty]

33 minutes ago, Joni said:

 

I agree, but if it works like that now, why would this auto iff thing be any different? That's why I was worried about a potential bug from the start that could be avoided.

All this stuff changes like in a kaleidoscope from update to update and... in between,  but from what I remember from my yesterday's hop (yesterday = distant past for me)

it does work like this (similar to upcoming Auto IFF). Of course, with AWACS and other donors things might be easier.

Edited December 16, 2020 by Gripes323

[dorianR666]

HAFUs are terribly broken since TWS was added, so its probably WIP.

[Joni]

Just now, dorianR666 said:

HAFUs are terribly broken since TWS was added, so its probably WIP.

 

They're not broken, actually they work almost perfect.

 

It's LTWS+MSI what is broken.

 

The topic here was more about the radar code. 

 

 

I guess we'll see tomorrow if they launch it. I hope not, I'd rather wait until it works fine.

[dorianR666]

2 minutes ago, Joni said:

 

They're not broken, actually they work almost perfect.

 

It's LTWS+MSI what is broken.

 

The topic here was more about the radar code. 

 

 

I guess we'll see tomorrow if they launch it. I hope not, I'd rather wait until it works fine.

Last patch i managed in multiplayer to get into a state, where the softlocked target was displayed as confirmed hostile HAFU on radar page, but friendly HAFU on SA page.

Its still a mess.

 

I suppose HAFUs and MSI are kind of inseparable, cant really blame one without the other.

Edited December 16, 2020 by dorianR666

[Joni]

1 minute ago, dorianR666 said:

Last patch i managed in multiplayer to get into a state, where the softlocked target was displayed as confirmed hostile HAFU on radar page, but friendly HAFU on SA page.

Its still a mess.

 

I have never seen that happen or reported. You should post a track, otherwise it may never be fixed.

[dorianR666]

5 minutes ago, Joni said:

 

I have never seen that happen or reported. You should post a track, otherwise it may never be fixed.

Happened only once and in multiplayer, tracks are problematic there.

 

However i have a screenshot of another suspicious HAFU behaviour.

 

On radar page, target locked in STT, onboard half of HAFU says unknown, datalink half of HAFU is missing.

Yet on SA page the target is datalinked as friendly.

How come the bottom half of the HAFU is missing on radar page? Its not just attack radar page, but az/el page too.

 

HAFUs cannot be trusted and are WIP. Or is this a misunderstanding on my part?

[Joni]

31 minutes ago, dorianR666 said:

Happened only once and in multiplayer, tracks are problematic there.

 

However i have a screenshot of another suspicious HAFU behaviour.

 

On radar page, target locked in STT, onboard half of HAFU says unknown, datalink half of HAFU is missing.

Yet on SA page the target is datalinked as friendly.

How come the bottom half of the HAFU is missing on radar page? Its not just attack radar page, but az/el page too.

 

HAFUs cannot be trusted and are WIP. Or is this a misunderstanding on my part?

 

Oh, that's no HAFU bug but an MSI bug in attack format that I was talking about before. It's a pretty annoying one that I hate it hasn't been fixed yet.

 

That happens when the contact is a PPLI one and you havent interrogated him. So SA page (no bug) shows the PPLI contact (green left dot) and radar page (bug) should show the same symbol correlated to PPLI but instead is showing the HAFU with no correlation. If you command IFF you will see it was friendly.

 

IMHO, despite the bug the error was yours, you should have interrogated him way before locking.

 

 

Thanks.

[Harker]

7 hours ago, Joni said:

I agree, but if it works like that now, why would this auto iff thing be any different? That's why I was worried about a potential bug from the start that could be avoided.

Maybe they're fixing that and adding the Auto IFF function at the same time. It's happened before, they sometimes iteratively remove placeholder functions before adding the realistic ones, like when they removed the ability to auto-IFF the TUC in LTWS, a few patches ago, presumably because such functions are controlled by settings in the AZ/EL page now.

3 hours ago, Joni said:

That happens when the contact is a PPLI one and you havent interrogated him. So SA page (no bug) shows the PPLI contact (green left dot) and radar page (bug) should show the same symbol correlated to PPLI but instead is showing the HAFU with no correlation. If you command IFF you will see it was friendly.

Yep. Another thing that's broken and reported since day 1...

[Joni]

After making some tests it seems ED did fixed the magic memory IFF and now if you drop the contact the IFF is lost as well. The auto IFF seems to be working ok. I will do some more tests.