Ghosty141

So let's get this straight. Basically the documentation CANNOT be right. It lists the yellow box clearly as RADAR FOV meaning, the radar can see everything in it's field of view. In the following screenshot we can clearly see the LST is in the box of the AZ/EL page and within the elevation range of the radar on the right side. The problem arises once I move the yellow box (or radar elevation) so that the target is OUTSIDE of the radar elevation boundaries. On the radar we can clearly see the LST is 2k ft below the cone of the radar. On the AZ/EL page though the contacts are outside of the field of view of the radar (the radar cannot see them anymore because of the elevation), they are still shown within the yellow box called "Radar FOV" in the documentation. This discrepancy makes the AZ/EL page almost worthless since I can't use the yellow "Radar FOV" box to control the radar elevation since based on it, I can slew my targets out of the radar FOV while the yellow box still indicates they are in view until they fade.

@NineLine any progess on this?

The thing that irks me about it is that it's VERY easy to misclick an MFD button and accidentally turning off your RWR which you don't notice since it only makes a sound when being turned on. Maybe this sounds stupid but, who asked for this? Have you guys noticed it in playtesting? I find it really annoying, at least let me turn it off maybe. I can only see this being useful for people without TrackIR.

Hi, this doesn't need much talking, basically the border of the AMPCD lets the clicks pass through to whatever is behind it resulting in accidental presses of the ALE47 buttons (which can be quite catastrophic ) If you click where the red arrow points in the picture you it will actually hit the ALE 47 Power button for example.

This is 100% what has happened, you can't uncage without master arm on.

I personally don't see the problem as long as you use an axis for the TDC since you can just change the curve and saturation as well as deadzone in the axis tune setting making it as slow as it was previously again.

This should be correct, TWS always needs a priority target, if none was selected in RWS it's gonne select one for you. The problem I am describing is when already having acquired a L&S target, pressing sensor control switch to the side of the radar should place the LST into STT, this doesn't always happen though since it randomly skips through other trackfiles.

This would only work within the limits of the seeker though, for example and aim9m would have a hard time the close it gets, right?

Hi! I generally agree with the notion you've explained in many other threads that artifically increasing the planes "size" to make it easier to spot is a bad solution and other steps should be taken to fix this if poissible. What I want to know your opinion on is the fact that spotting IS different depending on the resolution, on 1440p it is noticeably harder than on 1080p. That's a part of the core issue many people have with the current system. It feels bad to trade in visual fidelity for competitive edge. If needed I can try to get some examples on 1440p vs 1080p at various ranges although I'm don't have too much time at my computer right now so you might need to wait a few days for this.

Any progress on this? I personally find this one of the most annoying issues in PvP A/A fights since if a bandit is coming at you at close range in that space between HUD and HMD it's impossible to lock him unless you completely turn off blanking which is a pretty bad solution.

I can also confirm this sometimes happens. It's not tied to the missile since I've had this happen using Fox 1s (sparrows to be exact).

Firstly FACQ/AACQ are broken currently so while @sk000tchs advice is absolutely correct it's currently not a good idea to press SCS right to lock the L&S target. Check my bugreport for details (incl. track file and youtube video). TDC depress is currently your best bet. I haven't tried it yet but I this MIGHT (!!!) work if you are extremely quick and break lock immediately after firing. In DCS STT should always give an RWR warning. IRL you wouldn't lock a target in RWS mode since TWS is used for engagements. For example once you shoot an AMRAAM the radar automatically (!) switches to TWS AUTO mode, this is currently not implemented. TWS AUTO should work differently than it does now too, check this thread out for some of the details:

I found the ACM modes quite inconsistent in the hornet. With LACQ for example I couldn't get a lock on a bandit I saw right infront of me but I could see him on the radar after giving up on LACQ. Maybe it was his maneuvering but I don't know.

@BIGNEWY @NineLine I don't wanna be pushy but could you please remove the tag since it's simply false. This is a bug and should be fixed since it makes AACQ kinda useless in this situation.

Glad I'm not the only one. The "correct as is" label should be removed since the video clearly shows this is a bug.

What do you mean? The dimming function is only supposed to work in NITE mode, this is true to real life.

Ok I figured something else out, this behavior seems to be linked to changing the L&S target at least once. It sometimes works correctly if I engage TWS mode, place one target at L&S and then engange AACQ. I made a video showing this behavior: I also added the trackfile below. bugreport.trk Oh I missed that AACQ is not a ACM mode, thanks for the clarification. The behavior is still not correct thought, check out the video in my post above. This cannot be correct since it conflicts the documentation and behaves in a completely random way not being useful in any form.

I find it very irritating that these QoL features are not implemented while "less important" things get added and fixed. As a relatively new player I was quite stunned that you can't change the F10 radio menu in any way for example, same goes for the countermeasure programs. For multiplayer it's just too tedious, a better solution is needed. I really hope we get an update on the situation some time.

Just as an additional datapoint, I saw this video (don't worry I timestamped it): No idea if the data can be trusted since it's not blurred which is odd since they are usually quite secretive when it comes to ranges etc. Lets assume the F22 flies at the same altitude (40k ft) as the target with comparable speed (since Vc = 1460kts, 1460kts/2=730knts should be fine since it's head on). I replicated this scenario in DCS and it matches quite well. I'm a bit slower (only have the hornet :/) but Vc is close and altitude is basically the same. Looking at the radar, the range of the AMRAAM matches the one in video. Looks like ED comes quite close!

Don't get me wrong I don't doubt this but I'm curious for some sources that can back this up. The part that I also read is that the missile is way more proactive when it comes to getting "through" the jamming signal and getting the lock than currently modeled in DCS. I personally don't even really mind them not having it implemented yet, I'd just wish some more explanations on what is intended and what is not.

I agree with the other poster, don't forget that missiles ONLY rely on the shooters connection, meaning if you experience some kind of lag for a short time it may affect your missile. After the lag it may have lost lock and "gave up" (iirc once it loses lock and doesn't get new information it's basically dead, if it does circles or whatever doesnt matter at that point).

My understanding: The missile checks the course vector of the target and extends it as if it will keep flying in a straight line. If the target now keeps turning, the course line moves with it making the missile adjust to the point where it thinks it will intersect with the target (which it assumes keeps flying straight) which is far infront of it. That constant adjusting bleeds a lot of energy depending how the turn by the target is timed. You can see this VERY well if you turn on the "course" vector in Tacview and go to the cockpit view of the missile. (see attachment) It's very understandable that it works this way, how would the missile know its target is going to keep turning. Although I believe the real one might have some smart heuristics up it's sleeve. Some that I can quickly come up with: If a plane turns with 5g -> it will most likely keep doing that turn for a certian amount of time, or if the target is in a steep dive it can only do it for a certain amount of time until it hits the ground so it only makes sense to aim down a certain degree. It would be amazing if a dev could clarify this since I personally haven't found any posts about how the guidance works. Edit: I also added an attachment that shows me evading a aim120c shot from 34k ft/M1.5 at me (6.5k ft/M0.95). I only start my defensive maneuver once I hear the missile warning tone at ~8nm distance from the missile. Basically: turn to get the missile on your 6 while keeping it looking far down the course vector, once it its on your 6 turn again in the opposite direction. aim120c_defense.acmi

Hi, I've noticed that this part of the manual is not correct anymore. If the hornets radar is in TWS mode and I select a target to be the L&S target via the NWS/Undesignate button and then push the SCS right, the radar goes into AACQ (ACM) mode which should not happen according to the manual: Page 357/499 states: When in TWS mode, press right on the Sensor Control switch will place the L&S target into STT. This seems like a bug. I attached a track file to see this behavior. bug.trk

I've seen this multiple times already, the missile somehow doesn't try to intercept but rather catch up which ends up with it going parallel to the target. Not sure if this is intended or not.

Can you specify with what you mean by "no warning to the target". In the Hornet for example if you don't get a warning, the jammer is not going to emit anything, so the missile wouldn't need to be in HOJ mode. I guess I'm misunderstanding you there.