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.