Hardcard

Another relevant thing that I haven't seen mentioned so far in this thread is the bar setting. Before the hornet's radar rework, I remember that 4 bar & 40º azimuth in TWS was good enough. After the rework, though, 4 bar was no good anymore, even with the narrowest azimuth setting, the radar struggled to pick up targets and maintain locks. I found that the 2 bar setting yielded much better results. If you're experiencing this kind of issues and using the 4 bar setting, try with 2 bar instead. (Perhaps the brick timeout workaround will be enough to make the 4 bar setting reliable, but in case it doesn't improve things, try 2 bar)

Unfortunately, dcs.log has never recorded anything that could be linked to this issue (afaik). I get that you're looking for clues, but I don't think there are any to be found in dcs.log, sadly. The one thing we know for sure is that the issue was introduced in 2.7, along with new UI features such as the ability to see other client / unit waypoint paths displayed on F10 map. Perhaps it's just me, but it has always seemed to me that this issue is related to UI changes introduced in 2.7 ... As for "Smart Access Memory", let's not start chasing rabbits here, guys. My hardware doesn't even support that tech, it has nothing to do with this issue. Also, the AMD CPU + AMD GPU setup hypothesis isn't valid either, I'm running an intel chip as well. If we have to look for possible hardware culprits, maybe we should consider memory issues instead (since both AMD and Intel users are experiencing this issue). Drives and paging files?. I'm using Samsung 840 EVO 120GB SSD as system drive (with a paging file) + Samsung 860 EVO 1TB SSD for DCS + OCZ Vector SSD (with another paging file) . I'm also using a 144Hz AOC monitor and have DCS capped at 72FPS (I think) I also used a symlink for the DCS Saved Games folder, since it got too heavy for my system SSD.

@Tomy10 Unfortunately, I can't check your mission, since I don't own the WW2 asset pack or any warbird module. I haven't tested SWAPR in Syria map either, there might be bugs related to parking spot IDs and stuff like that. As for the rest of things you mentioned, some of those are explained in the videos and previous comments in this thread. For instance, AI replacements are removed after ~3 minutes (no idea why), this is a known issue, you can use static replacements as a workaround, since they don't seem to be affected. Also, spawn offsets are intentional, I had to reintroduce them in order to avoid collision problems in version 2.7 As for having several replacements spawning in the same spot, something is clearly not working as it should. Btw, you didn't provide your dcs.log, it might contain some clues.

Sounds like a new issue, but, tbh, I don't think I can do anything about it, script wise. DCS spawning has been screwed for a long time and looks like they're finding new ways of screwing it with every new build

@pacastro Capture logic was only implemented in an experimental 1.3 version, 1.4 doesn't support it. The reason being that DCS automatically removes airbase replacements and prevents them from spawning upon capture (at least sometimes). It was a mess, so I removed the related code.

@MARLAN_ I haven't tested it yet, since I don't like the map (don't even have it installed ) I've recently bought the Syria map, though, so I'm now able to test SWAPR there (I have the feeling that there'll be issues, though ) Try SWAPR in the Marianas map, if it doesn't work, I'll take a look.

When you load a file in Mission Editor, DCS makes a copy of it, which is saved in the miz file. You need to reload the file every time you make changes to it, otherwise these changes won't apply. There's also the possibility of loading scripts dynamically, which allows you to modify script files without having to reload them every time. Here, Pikey made a nice tutorial about it:

@Erikson Thanks for including all the required files in the report (Take note, guys, this is how you make a report ) The SWAPR_1_4.lua inside your mission file is set to "SP", so if you run the script like that in a multiplayer environment, replacement removal won't work. The reason why I had to create separate "SP" and "MP" modes is because DCS events needed for the removal of replacements don't work in MP, only in SP. "MP" mode relies on server code (included in the server hook) for replacement removal instead. I tested your mission with the game mode set to "MP" and it works fine, but keep in mind that I don't have access to a dedicated server, so this isn't 100% conclusive. As for sheltered clients being replaced by AI instead of statics, this is intended, since statics used to spawn on top of shelters instead of in them when I created the script. I think that ED recently fixed this particular issue, so I might modify SWAPR to allow static spawning in sheltered spots again, we'll see. As for AI replacements being removed from the map after ~3 minutes, it might be a relatively new DCS cleanup routine that didn't exist before. I might end up ditching AI replacements and using statics exclusively... but it's risky, since there's a good chance statics will get bugged again in the future.

I wouldn't make such blanket statements if I were you, I get phoenix RWR warnings when flying the viper. This issue is probably related to specific conditions, rather than airframes. Remember that TWS launches don't give warning, only STT launches do, so I wouldn't test this with AI, since there's no way of knowing which radar mode it's using. Better test it with other tomcat players, talking via discord / teamspeak / SRS / voice chat, etc. Take note of the radar modes being used in each test, as well as other factors like aspect, indicated TTA, whether the lock is dropped, etc. Unreliable RWR warning when phoenixes are involved might have something to do with the selected radar mode, phoenix's radar losing track / reacquiring, etc.

@BigMillerTime Hey Miller, what's the problem? Do you have a mission file I can look at? @Spins321 Unfortunately, I have no idea of what's making AI replacements despawn.

@[ED]Obi @Flappie Issue still persists in latest OB 2.7.2.7910.1 As stated several times in this thread, it's a general issue that affects both AMD and Nvidia users, either in MP or SP. Doesn't seem to be driver related, looks like it's a bug introduced in 2.7, something breaks the UI of the entire game. Are you guys still looking into it? Is anybody looking into it? Here's the dcs.log from my last session (I lost the UI soon before closing DCS) dcs.log

@Frederf Thanks a lot for the detailed post. I think the responder works

@Spins321 Ok, we're talking about the replacements at Kobuleti, right? I can confirm that AI replacements are removed after ~3 minutes, fortunately, this issue doesn't seem to affect static replacements. Until I find the culprit, I recommend that you set Replacement_Type to "Static". (Keep in mind that tomcat static models are bugged since the introduction of 2.7, this is a known DCS bug and has already been reported. It has nothing to do with SWAPR) Also, I noticed that your SWAPR script is using several client suffixes that aren't present in the mission. Your clients at Kobuleti only use "_client", so your SWAPR_Prefixes table should look like this: local SWAPR_Prefixes = { "_client" } Finally, a 10 second delay for the SWAPR script trigger might be a bit overkill

@Willie Nelson I boresight them on the ground, using runway / taxiway signs (these are lockable objects in DCS). The procedure I follow is pretty much the same shown in the video that @Dawgboy linked, but, unlike the author of that video, I use lockable objects to boresight my mavs. He used a hornet's wheel, which the mavs couldn't lock on to properly, I wouldn't have trusted that alignment. In any case, I double check the alignment once I'm the air, using friendly ground units around the airbase. Small corrections are needed sometimes, but nothing major.

Bypass is definitely the way to go if you want full control. I also can't stand wasteful release of CM, which is why I use bypass exclusively. Just set the mode to BYP and have both chaff and flare switches up, that'll dispense a single chaff & flare per command. If you want chaff only, set the FL switch off (down). If you want flare only, set the CH switch off (down). Disregard betty's "chaff, flare" callouts, she'll say that even when you're only deploying one type of CM. I have CH and FL switches + CMS all assigned to the same 4-way hat, so I can quickly select the kind of countermeasure I want and release, without having to look down.

Watch the video again (or better yet, replay the track. It'll allow you to see the tiny radar queues on DDI). First two amraams got the LOST queue both at launch and during midcourse guidance (watch the radar page on the right DDI, at the bottom of the STT line you'll see "LOST" flashing briefly during midcourse guidance). I'm not gonna say that the radar isn't bugged (it's the hornet, after all ), just considering alternatives. Also, remember that whatever the hornet was capable of doing before 2.7, doesn't necessarily apply now, with the new radar implementation, so I wouldn't dwell in the past.

I don't know how realistic that simulator is, but sure, that kind of approach will definitely get you killed in DCS

@jwflowersii Your third missile tracked the bandit and the first two didn't, that's the fact we have on the table right now. The explanation must be found in the variables that changed between launches. Could be max range violation, loss of DL guidance before pitbull or something else.

@jwflowersii After watching your track, looks like the issue might be related to the fact that your first two amraams were fired beyond the calculated max range. I don't know whether this is expected behavior, but I do know that STT locking a bandit at 30nm isn't a good idea (unless he's chasing a friendly and you want to distract him). Next time wait until the bandit gets within max range, at least, and don't use STT lock from so far away. (Hell, with good DL picture, I wouldn't even turn on the radar until the bandit were within 40nm, or within 10nm in the absence of his nails ) EDIT: What @opps suggested might explain it as well.

Yup, post the tacview track file, so people can see what your missiles actually did. I'm betting that all your amraams were tracking, problem is that you launched them from way too far. Amraams aren't phoenixes, don't expect crazy range from them.

@Willie Nelson Yup, you're not alone. Auto handoff won't give you a valid mav lock most of the time. I force correlate H and K mavericks, using manual handoff and area mode, but in order for this to work well, mavericks need to be perfectly boresighted.

@Spins321 Thanks. Could you also attach the dcs.log that was running when you encountered the issue? Also, if you were running the mission in MP, I'll need the server hook as well. Additionally, if the mission is using mods, please remove any modded units/objects, so I'm not required to install them.

If those results are screenshots from the manual, I've already seen those. What have you found?

@Willbassen SA-10 sites don't have that many missiles available, I suggest that you first drain the site of missiles and then attack with HARMs, so they can't be intercepted. Draining the SA-10 (or any other SAM site) quickly is as simple as finding a hill / mountain (good enough for masking) within its umbrella. Pop up above cover, let the SAM site lock on you and fire, then dive behind cover again, instantly defeating the incoming missiles, rinse and repeat. It shouldn't take you more than 5 minutes of this to drain any SAM site in the game. You can also live dangerously and do the same in flat terrain, without mountains or hills... just drop to the deck, below the radar's detection threshold (20-30ft from the ground should be good enough), then pop up, bait the SAM site into firing, down to the deck again, rinse and repeat.

@Mangrove Jack What are you using those flags for? What's the goal you're trying to achieve?