Kondor77

Had this same bug, happened to me on the next mission, and also at the exact second our push code word was sent out. Smashed the trim back full left and was able to finish the mission. Was definitely a bit odd.

I haven't run into this issue with the campaign, but twice actually in MP. Both times received no damage either. So this is definitely an F4 specific bug with the current version, and not with the campaign.

Personally what I've found works best is disregard any of the seeker heads that target Tracking Radars. As already mentioned the radar would have to be illuminating, guiding a missile, and all in the direction of the shrike. Against your likely foes of SA2/3/6/8, I've found the Mk 37 seeker head works much more reliably. For the SA2/3 it will go after the FF search radar. With that out of the way the site becomes much easier to then clean up with some iron bombs. The Mk37 will also guide on a searching SA6 and SA8, no need for either of them to be actively guiding a missile.

Well said. ED asks us for our opinion. We give it (and most do it respectfully) because we're all nerds for this stuff and know it's a niche within a niche. But then to have our comments either in discord or in a thread sent to the ether with this kind of attitude really leaves a sour taste. This specific issue with the MV has been known since the release of the remaster. To then knowingly hold a livery competition knowing full well the plethora of disappointed livery makers was just too much to let slide without some pushback. We all want to keep making this game great. And a huge part of that is the work and love community members put in making missions, skins, apps etc etc.

Bump. This bug is still happening. For a while I thought the solution was to turn off "Hardware Accelerated GPU Scheduling". However, that might've only been a placebo. FYI @BlindeThe ONLY thing that's corrected this issue for me is to once again disable the Supercarrier module. How this module affects every other module and how the game loads their dll files in a MP server...I'll never know.

I can also report this issue. I've posted my logs before on the ED discord and no solution. I also updated Windows 11 to 24H2 and that was probably when this happened. I've tried complete clean DCS reinstall and that hasn't helped. I can also verify that loading into a slot in SP loads normally. And that if you do this BEFORE joining a MP server and picking that same jet/helo you will load into the slot instantly. But if you load into MP "cold" DCS will appear to hang because as seen in the logs people have uploaded the specific plane(whatever plane/helo slot was selected) take MINUTES to load each dll. So for the ED testers what is the difference between first loading the dlls in SP vs MP? I've tried this in several servers with TONS of slots and servers with only 6, and it makes no difference. Are any ED testers on 24H2?

So our only option to use the directors is to essentially only have an empty deck in every mission? Fantastic, well done.

I really hope this isn't the case.

After doing some more testing, it seems as soon as the EWR is used in a dedicated server - it reverts all it's settings back to default. So in this case if you had a different callsign, it'll always revert to 'Axeman' (which is the default and top of list of EWR callsigns). And it additionally reverts back to default frequency (124mhz). What is so weird that this works fine as it should in SP, or even locally hosted on your own gaming machine. But as soon as I drop this onto a separate dedicated server box, the EWR reverts back to default. @NineLine @BIGNEWY

Attached are the .miz as well as the trk file. No scripts, EWR does not respond/talk when the mission is run from a dedicated MP server. If I run the mission straight from the ME or from hosting on my own machine - it works. Very weird bug. SA_F4 STRIKE DAY 1_EWRAxe-20240820-133342.trk SA_F4 STRIKE DAY 1_EWRAxe.miz

@NineLine @BIGNEWY FYI track and log files have been included here, could either of you please confirm these have been sent to the team?

This post is over 5 years old. With track files provided and still no acknowledgement from anyone? @BIGNEWY @NineLine

Per the changelog: AI Ground. Added the ability for SAM to evade ARM (enabled by default, but can be disabled in Set Options - Evasion of ARM). Units that detect the missile will turn off their radar(s) and displace. Units that cannot move quickly will simply turn off their radar(s). The higher the skill level, the higher the likelihood that the air defence unit will react to the incoming ARM This does not appear to be working as advertised. I've tried both by adding the scripted 'Set Options' as well as not including it since it is 'enabled by default'. The only SAM I've managed to see shut itself off is the SA-5. I made sure on every SAM tested to increase every part of the groups AI level to 'Excellent'.

He should still be able to highlight different ones though.

Bumping again, in lieu of I'm sure more SC 'news'. Please fix this. This affects paid and even the free carriers. It's been ridiculously ignored for long enough.

Just having F-14 Jester use the 'context' button to highlight different TWS targets, or change the target/launch order would be fantastic.

I've had him do this on airbases with multiple runways. I'm assuming it has to do with taking off from a runway the AI doesn't believe is active/primary. Probably all based on wind direction.

If you turn on the autopilot (alt hold not necessary), then press active pause, as soon as you un-pause the jet pitches up uncontrollably and you have to restart the mission. I already have FFB forced off in the MISC tab.

Thanks. If you'd like to test it yourself this also happens in the Nevada Through the Inferno mission provided with the F4. I sit in the cockpit cold and wait for all the scripts to activate. Once they do I try the standard edit flight plan > use map markers Jester option. As soon as I hit use Map Markers...the Jester wheel freezes.

Have had this happen in a few Grayflag MP sessions. All while editing flight plans using map markers. Maybe it doesn't like " # " being used for map markers?

Bump, this is still occurring. Why wasn't this change reversed until it could be fixed properly?

Gracias Fausete, you guys rock! Keep up the great work.

Tested this twice in MP, SA10 gives a lock warning but no launch tone on RWR. Tested in SP and it works as it should. Wondering if anyone has run into this in MP after this weeks' patch and subsequent hotfix. I know we've had issues with the RWR in the past with SA5, so maybe a variation of this bug is back?

I admit to know nothing, but it almost seems to me like ORT is 1 person, they themselves did some art but probably contracted out most of it. This is why bugs as simple as this to fix, haven't been yet, regardless of "Priority" assigned by them in this forum.

100% The fact that this hasn't been fixed in nearly a year after release...very disheartening.