yes Is AACQ active already ?

[max22]

I'm looking for this  killer feature for so long. Is the AACQ implemented ? not following so much lately. Thanks.

[fitness88]

Yes I use it.

[Shimmergloom667]

It's implemented for ages now, but was somewhat buggy a long while. It's working pretty perfectly nowadays, though, including the AACQ cue, that has been added a while ago.

[falcon_120]

16 hours ago, Shimmergloom667 said:

It's implemented for ages now, but was somewhat buggy a long while. It's working pretty perfectly nowadays, though, including the AACQ cue, that has been added a while ago.

So does now have range gate? So if you select 20 nm it will automatically pick the first detected bandit inside 20 miles? 

Before the major problem always was that it had a huge tendency to pick the longest target 80 miles out while never acquiring the bandit hot on you at 10 nm coming really fast.

[Harker]

SCS to Radar (that invokes AACQ, FastACQ etc) works much better now and is reliable most of the time. Most of the old issues are appear to be resolved.

One thing that's not working yet though, is the rejection of the previous AACQ contact for 10 seconds, which is done by using the SCS again, after you've used it to enter AACQ before.

[Swift.]

The logic it uses to decide which track to STT is also terrible, afaik its just based on range right now which means it just locks up your lead wayy too often if you are even slightly sucked. It doesn't account for ID, aspect, closure, etc etc.

 

Also missing some AACQ functions but I'm sure they will be seen soon enough.

[Santi871]

AACQ was updated and works correctly now, but it is missing bump acq (AACQ while in STT).

[Joni]

10 hours ago, Swiftwin9s said:

The logic it uses to decide which track to STT is also terrible, afaik its just based on range right now which means it just locks up your lead wayy too often if you are even slightly sucked. It doesn't account for ID, aspect, closure, etc etc.

 

Also missing some AACQ functions but I'm sure they will be seen soon enough.

 

Well, I tested this and it turns out the logic works fine. If all targets are unknown then the closest one will be locked up. But now with auto IFF I found out that it locks up the closest enemy return or the closest unknown, even if the closest to you is a friendly.

[Swift.]

1 hour ago, Joni said:

 

Well, I tested this and it turns out the logic works fine. If all targets are unknown then the closest one will be locked up. But now with auto IFF I found out that it locks up the closest enemy return or the closest unknown, even if the closest to you is a friendly.

That doesn't sound like what you would hope is 'correct'. The distance to you isn't the only property that I would hope is considered. Thing about aspect, altitude, ID, airspeed, closure. Having it lock the closest hostile means it would lock the bandit running cold at 15, when the guy hot at 20 well inside his WEZ will be passed over by the logic. 

 

idk, maybe it is that simplistic IRL, but as I said, I hope not.

[Joni]

16 minutes ago, Swiftwin9s said:

That doesn't sound like what you would hope is 'correct'. The distance to you isn't the only property that I would hope is considered. Thing about aspect, altitude, ID, airspeed, closure. Having it lock the closest hostile means it would lock the bandit running cold at 15, when the guy hot at 20 well inside his WEZ will be passed over by the logic. 

 

idk, maybe it is that simplistic IRL, but as I said, I hope not.

 

I was trying to point out that it doesn't work like you said in the first place, like locking the closest despite being a friend.

 

Aspect I didn't tried, but it could very well work like that in DCS.

[Joni]

43 minutes ago, Swiftwin9s said:

That doesn't sound like what you would hope is 'correct'. The distance to you isn't the only property that I would hope is considered. Thing about aspect, altitude, ID, airspeed, closure. Having it lock the closest hostile means it would lock the bandit running cold at 15, when the guy hot at 20 well inside his WEZ will be passed over by the logic. 

 

idk, maybe it is that simplistic IRL, but as I said, I hope not.

 

Ok I tried it and distance + IFF are the only things taken into account.

 

I had a bandint coming at me further than the cold bandit and it turned into the AACQ contact exactly when the hot one was closer than the cold one.

Edited January 10, 2021 by Joni

[Jak525]

What AACQ should do is acquire the L&S, if it exists, and if it doesn't then the priority one trackfile. With no L&S and no AMRAAMs in flight, the priority one trackfile would be the track with the rank number of "1" in the middle of the HAFU. Rank is based on distance, direction, ID etc. If it's doing something else in DCS it's wrong. The priority logic isn't implemented, but it would only really change the logic in the case of an AMRAAM being in flight and an L&S not existing. (Priority = L&S>under AMRAAM attack>DT2>other trackfiles by their rank)

 

Note this is of course assuming the cursor is not over a trackfile. In that case, it should always perform "Fast Acquisition" i.e. STT the trackfile under the cursor, regardless of if that track is the L&S or not.

 

The only time AACQ would not use this logic is in the not yet implemented Velocity Search (VS) mode where trackfile processing doesn't occur. In that case, it would simply lock the hit with the fastest closure rate to you.

 

I would also note the Acq Point Cue in RWS mode is improperly implemented, which is for another report I guess. In RWS, when an L&S exists, the point cue should not be there. This is because the point cue points to the #1 priority trackfile if its HAFU is not displayed. The L&S is automatically #1 priority, so if it exists, the point cue does not. Right now. the point cue simply points to the #1 RANKED track. Recall that rank and priority are different. If the trackfile with a rank of #3 is the L&S, it's still rank 3 and whatever was rank 1 is still rank 1, but the L&S is priority #1.

 

I'll end my slight tangent there lmao.

Edited January 10, 2021 by Jak525