Jump to content

Hardcard

Members
  • Posts

    999
  • Joined

  • Last visited

Everything posted by Hardcard

  1. 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
  2. @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.
  3. @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.
  4. 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:
  5. @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.
  6. 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.
  7. @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.
  8. @[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
  9. @Frederf Thanks a lot for the detailed post. I think the responder works
  10. @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
  11. @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.
  12. 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.
  13. 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.
  14. I don't know how realistic that simulator is, but sure, that kind of approach will definitely get you killed in DCS
  15. @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.
  16. @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.
  17. 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.
  18. @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.
  19. @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.
  20. If those results are screenshots from the manual, I've already seen those. What have you found?
  21. @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.
  22. @Mangrove Jack What are you using those flags for? What's the goal you're trying to achieve?
  23. I've tried Google, forum search, checked both the manual and Chuck's guide, but I haven't found any info about the Mi-8's IFF responder. Does anyone know if it actually works? Does it require setting up? If so, how? I'm asking because Mi-8s don't seem to respond to IFF interrogations (at least when vipers perform them... I'm not sure if it's a viper bug, an mi-8 bug or something else)
×
×
  • Create New...