itsthatguy

The most recent update has FINALLY brought some much needed consistency to the original issue I discussed, where pressing the uncage button would randomly switch between the three states when an L&S is present. It seems as though the new implementation is working mostly as intended. It has a strange side effect, mostly manifesting as the strange "auto-lock" behavior that's discussed in many posts above. The one thing that still seems off is that the behavior is different depending on whether the L&S is created with a normal radar mode or an ACM radar mode. The seeker behavior when there is no L&S is still the same as @miguelaco describes a few replies above. What's finally fixed is the seeker behavior when the HMD is on and and there is an L&S that is acquired with a NON-ACM radar mode: 1) Upon designating L&S, seeker will auto-slave to L&S. Will also auto-lock if target is within range. 2) When pressing uncage button, seeker will return to HMD slave. 3) Next press will attempt to lock target within line of sight as long as uncage button is held. 3a) If no target is in sight, seeker will return to L&S. When button is released, seeker will briefly unlock and re-lock. Seeker is now back to step 1. 3b) If a target is within sight, seeker will lock onto target as long as button is held. As soon as button is released, seeker will return to and auto-lock to L&S (if possible). If target is L&S, seeker will briefly unlock and re-lock when button is released. Seeker is now back to step 1. For whatever, reason, if the L&S is designated thru an ACM mode (HACQ), the seeker behavior is different and still wonky: 1) Upon creating L&S with ACM mode, seeker will auto-slave to L&S. Will also auto-lock if target is within range. 2) Upon pressing uncage button, seeker will slave to HUD only. 3a1) IF pressing and releasing uncage button, seeker will return to L&S slave, but NOT locked on. 3a2) IF pressing and releasing button, seeker will return to step 2. 3a3) IF pressing and holding uncage button, seeker will lock onto L&S. Upon release, seeker will briefly unlock then re-lock L&S. Seeker is now back to step 1. 3b) IF pressing and holding uncage button, seeker will lock onto L&S. Upon release, seeker will briefly unlock then re-lock L&S. Seeker is now back to step 1.

I've noticed that no other ground mapping radar in the game seems to be effected by jamming in the way that the Viggen is. Even the Viggen itself only "sees" jamming from ships, and not any other source. This leads me to the question of how it's implemented in the Viggen. Is it: 1) An actual interaction between the ship and the aircraft. Ex: The ship object starts jamming, this information is passed to the aircraft object, which produces the jamming effect on the radar display. OR 2) Wholly contained in the aircraft's logic, and not an actual interaction. Ex: The Viggen's code has some rule for when a ship WOULD turn on it's jammer, and when that condition is met, it produces jamming effects on the radar display. If 1) then is there a way to set a ship's jamming behavior in the ME?

I created a video as a visual aid for all of the problem(s) I've described in this thread. I'd like to re-iterate that not only did the April 2025 patch not fix the seeker behavior, it actually introduced even more problems (see my prior post). Another issue I discovered, which I didn't cover in the video, is that when the seeker is slaved to the HMD, and the HMD becomes masked, the seeker just gets stuck wherever it was at the moment the HMD became masked. So, if you look at the HUD, the seeker will be stuck off to the side of the HUD. AIM-9X_Problems.log AIM-9X_Problems.trk

Maybe you're misunderstanding what I'm asking for. I'm not asking HB to change the current implementation. I'm asking them to (maybe as a stop-gap) just create a brand new version with a different name (like how we have a separate version for AI at the moment) that uses whatever ED code was used for the Harpoon in the F-18 or by Deka Ironworks for the C-802AK used by the JF-17. Are you saying that there is no standard API/Template/"code" for ASMs like there is for A2A missiles, so it's not that simple? Does ED need to be the ones to implement it themselves, rather than the module maker using an API?

If you weren't aware, the RB-04 and RB-15 have been implemented in a way that causes them to go stupid and/or self-destruct if the host aircraft dies while they are in flight. HB did this on purpose, even though it's not realistic, because it was the only way for them to implement the fancy targeting features these missiles are supposed to have. What I'm asking for is a version of these that are made as a normal ASM (like Harpoon) so that we can have something that will at least still connect if the host aircraft is intercepted and killed during RTB, even if they lack the fancy targeting features.

I'm trying to raise awareness for this to save others the hours of my life that I wasted trying to figure this out, and I think including this in Chuck's Guide would go a long way: HB have implemented the RB-04 and RB-15 ASMs in a way that causes them to go stupid and/or self-destruct if the host aircraft is destroyed. If you release these things you must stay alive for the duration of the flight if you want them to connect. No, it's not a bug, even though it's not realistic. They did this on purpose because it was the only way for them to implement the fancy targeting features the missile is supposed to have.

If this is [NOT A BUG] then can we at least have an acknowledgement of it in the manual? The only places where this is mentioned anywhere is two obscure forum posts that you're only going to find if you already know what to look for (ie. you've already figured this out for yourself). I couldn't find a single guide/tutorial that mentions this either. I had a couple of sorties in MP last night where I released RB-15s then got intercepted and killed on RTB, and I spent hours trying to figure out what I did wrong that was causing my RB-15s to randomly explode 20-30s after I died. That's hours of my life I could have saved if I had known about this beforehand. It wasn't until I tried to test in SP and they exploded immediately that I was able to put two and two together. Curiously, when I launched a my own MP server and tried it, the missiles didn't explode immediately or continue on course before exploding like they did on the public server - instead they turned vertically and flew to like 20,000 ft before exploding.

Okay so I did some quick testing after today's patch and while the cage/uncage button behavior certainly is different I'm not sure I'd call it "fixed". I need to do some more digging to figure out exactly what's happening now with the relationship between the 3 "states" that I mention in previous posts, but it's different now than it was before. It's still seemingly somewhat random, but it's now more complicated than it was before. One observation is that the button now functions on both press AND release, whereas before it only functioned on a press. This is readily apparent and easily testable by silencing the radar so it can't interfere: Looking at a target with the AIM-9X slaved to the HMD, then pressing and holding the uncage button will cause the seeker to lock on. If you keep your HMD reticle over the target, then release the cage/uncage button, the seeker will briefly unlock and then re-lock the target. Repeating the same procedure, except looking away when you release the cage/uncage button, will cause the seeker to snap back to the HMD line of sight - HOWEVER, the seeker will automatically lock onto the next target it sees without you pressing anything. This means that if you quickly press and release the uncage button, the seeker will briefly lock on, the unlock, then re-lock onto the target (assuming you don't look away too quickly). I don't think this behavior is intended. @BIGNEWYPlease pass this on.

Reviving this thread because it has been 7 months with no word on the issue, and my (hopefully) more clear description of the issue was never acknowledged.

There's been a hotfix released since you say this problem was semi-fixed, why wasn't it included? Are 3rd party devs not allowed to push changes to a hotfix version?

In modules that simulate it, whenever you face into the wind, and your engine windmills a little too much, it will prevent you from repairing. I think if the RPM is above 1% the ground crew won't repair. Fixing this is as simple as raising that number to 3 or 5%.

I second this. It's very annoying.

I've done a little more testing and it seems in situations where the target is too far away for the missile to see, it will happily switch between states (1) and (2). It appears as though what is happening is that when the seeker is in state (2) or (3), and the uncage button is pressed, it will attempt to return to state (1) - however, the seeker will often achieve a lock on the target before the missile LOS is able to move back to the HUD or HMD LOS, causing it to snap right back onto the target. In summary, When there is no L&S/STT, but there is a target within range of the seeker, Uncage will toggle between states 1 & 3. When there is an L&S/STT, but no target within range of the seeker, Uncage will toggle between states 1 &2. When there is an L&S/STT, AND there is a target within range of the seeker, Uncage will switch between the 3 states randomly. To be clear, the problems described in this thread (apart from the first one that was already fixed where the seeker would unlock if you looked away) only occur when trying to use the AIM-9 with HMD cueing while also having a L&S/STT designated. There is some conflict in the seeker behavior logic when the cage/uncage button is pressed. In any case, for those browsing about the issue, the easiest workaround is to SCS Up to enter HACQ mode, then immediately hit the undesignate button to "reset" the radar and clear all track files. Just be aware that if you are in TWS mode, as soon as the radar sees something, it'll automatically assign it as the new L&S and you'll be back in problemville. @BIGNEWY Please pass these findings along, I hope they can be helpful.

So then what's the actual difference (in DCS) between RWS with LWTS and TWS, other than TWS having a scan volume limit and RWS with LTWS not having access to the EXPand function? Also, I was under the impression that IRL, taking an AIM-120 shot would automatically switch the radar to TWS in AUTO mode, with the option to return to RWS.

Gotcha, I was just going off of this line on page 177 in the manual: Also, at 6:39 of the relevant Wags video: I could not track down any changelog item that noted this change in behavior, so I thought it was a bug.

You can launch AIM-120's from RWS and get all of the proper symbology as if the aircraft was actually supporting the launch, even though (in theory) any launch straight from RWS should be an unsupported "maddog". I do not know if these missiles are actually being supported even though they shouldn't, or if the aircraft is providing bogus missile tracking, time to active, and TTI indications. F18_RWS_Bug.trk RWS_BUG_120.log

It is very unclear in the manual how all of these button presses should relate to each other, and it seems wrong to me, so I'm making this bug report. Entering VACQ is a very convoluted process when the HMD is turned on. You cannot enter VACQ from HACQ, as that button press is instead reserved for AIM-9X UPLOOK (which doesn't seem to work anyway). There are only 2 ways to enter VACQ when the HMD is on: 1) Enter HACQ or LACQ, then WACQ, then you can enter VACQ. 2) Select A/A Gun, putting the radar in GACQ. You may then enter VACQ. On another note, it is unclear to me why the AIM-9 seeker is caged to the HUD Boresight when in HACQ & LACQ, but not in the other ACM modes. It doesn't seem like it should work this way. dcs.log F18_ACM_Bug.trk

@BIGNEWY I've been trying to boil this issue down and I think I've done a fairly good job here: There are 3 states that the AIM-9 seeker can be in, in the hornet. 1) Slaved to HUD Boresight/HMD LOS, depending on whether pilot is looking inside our outside of cockpit, and whether the radar is in HACQ mode or not. 2) Slaved to Radar L&S/STT (looking at target but not actually locked on) 3) Locked on to Target. When the radar is off, or if there is no L&S or STT, the behavior is rather simple. The seeker will do (1), and upon pressing uncage, will attempt to do (3). However, once there is a L&S or STT, the behavior of the uncage button becomes unclear. It seems to move the seeker between the 3 states randomly, with no clear logic. In any case, the only reliable way to get the seeker back to HMD LOS is to drop all radar tracks in one way or another.

I was creating a bug report on something else, using the F-18 AIM-9X practice mission. When starting this mission, the AIM-9 is selected on mission start. This is not the case in the track file, meaning several of my actions were not appropriately reproduced. dcs.log F18_Track_Bug.trk

As far as I can tell, the IR A2A missile simulation in DCS is extremely simplistic by modern standards - especially the IR-CCM aspect. It seemingly isn't substantially different than what it was in 2011 - or maybe earlier. Aircraft only have 3 states of IR luminosity - Engines off, Engines on, and Afterburner. This means that the IR signature is the same whether on MIL or idle. IR-CCM is apparently a dice roll to see if the missile "goes for the flare", with the chances varying depending on flare/missile type, range, and aspect. There is, apparently, no attempt to actually simulate the different methods of flare resistance employed by different types of missiles. A2A missiles are completely unaffected by sources of IR radiation from the ground, and can't actually "see" flares (you won't get a tone if you cue your seeker onto a flare). With the recent improvements to radar and radar guided missiles seemingly wrapping up, this feels like a natural next step. EDIT: Now that I think about it, Chaff is also very simplistically modeled - until the F-4, no radar in the game could actually "see" chaff.

That means that War Thunder and VTOL VR have more detailed IR missile tracking and countermeasure behavior than DCS. Maybe after ED finishes their new radar modeling they can focus on this and we'll see some improvement a few years from now.

Is anyone able to confirm how IR-CCM works in DCS? This is one aspect of the sim that (as far as I'm aware) hasn't been substantially updated since 2011 (or maybe earlier). Of course, in real life, different IR missiles have very different methods of resisting flares - for example, I believe the AIM-9M added a feature where the missile would simply turn off the seeker for a brief moment when a flare was detected that obscured the target - it would then turn back on and attempt to re-acquire once the flare had left the missile's FOV. It seems to me that in DCS flare resistance is a dice roll based on your aspect. Either the missile will "go for the flare" or it won't. Also, I've heard that (as far as IR missiles go) every plane only has 3 "states" of IR luminosity: Engines off, Engines on, and Afterburner. Meaning, there's no difference, as far as defeating IR missiles, between MIL and idle power. Can anyone confirm this as well?

The smoke from the large fire effect renders on top of clouds, but turns white. When the smoke is on the edge of a cloud it kind of flickers or fades between black and white. (At least it does in VR, haven't tested flat screen). Using most recent "combined" release version. Seems like this is one more thing that needs updated to play nice with the new clouds.

I figured as much - the post was more of a comment on the unrealistic accuracy of the box. It's always spot on almost instantaneously after a radar is detected for the first time.

As far as I'm aware, right now the the Hornet's HARM TOO mode is like an HTS but with superpowers. I have no idea how the aircraft would be able to display a box over the emitter that the harm is "looking at" (the one that is boxed on the HARM display). In order to do that, the HARM would need to be able to give an accurate "look angle", which it should not be able to do. Determining the accurate position of a radar emitter is no trivial task, that's why things like the HTS exist. Here's another way to look at it. As we know, a TOO launched missile doesn't loft because the missile cannot determine range on it's own. But if it has an accurate "look angle", it (or the host aircraft) WOULD be able to calculate a range. With the current implementation, I can fudge a impromptu PB launch by finding an emitter in TOO mode, then creating a target point with the HUD and slewing it into the center of the box showing me where the emitter is. Now I have a relatively accurate aiming point for a PB launch. That should not be possible, not even an HTS in a Viper can give you an accurate position instantaneously, regardless of your approach angle. I'm not saying the box in the HUD is completely wrong, but I am saying that the way it's implemented right now must be. Also, why does the HARM in TOO mode have none of the restrictions that the HARM in HAS mode does for the Viper, like tables and scan time? The Hornet's HARMs can scan the entire volume for all types of emitters almost instantaneously.