Hardcard

I meant that Jester (or the radar) will sometimes bug distant, non-factor targets, in the presence of bogeys on the nose, which are way closer (even hot ones). I guess it's a TWS Auto issue, but Jester should be "smart" enough to see the problem and work on the nearest bogeys first. Images are worth a thousand words, I guess (a couple of Photoshop edits, just to illustrate the problems I found. EDIT: Ignore the symbology, just imagine that TWS Auto/Jester are bugging the farthest bogey only, ignoring the two closest ones on the nose): I think there should be a Jester TWS menu, just like the STT menu currently implemented. Pilots should be able to command Jester to switch between TWS contacts, without having to STT lock them.

Awesome? I'd gladly get rid of it, in its current state :lol: A/G radar's resolution is so low that most targets can't be seen. Even in ideal conditions, where the targets can be seen, A/G radar's accuracy is simply not good enough for weapon employment. Tpod designation is still faster and way more accurate as far as I can tell. We'll see how the finished A/G radar compares to Tpod... for now, I'll keep it disabled. ;)

The hornet's trim is really "slow", you'll need to press the trim buttons thrice as long (or even longer) in order to apply the same trim you would with other aircraft. As for the walleye, I wouldn't use it without the DL pod.

First off, let me just say that the tomcat module is amazing, I'm absolutely in love with it, you did an amazing job. I've been flying the tomcat during the free trial and things have worked fine, for the most part. However I've encountered some really nasty issues, which I don't see reported anywhere, so here I go: All my tomcat tracks were corrupted I couldn't get a single valid track (this happened both in SP and MP). Specifically, the plane would just start veering off course, completely disregarding what I actually did in the mission, pitching up and doing loops, eventually crashing into the ground/sea. Also, Jester menu would get "stuck" during the replay, blocking the view (looks like Jester menu interaction isn't properly "recorded" in tracks) I probably should've kept some of these corrupted tracks, but I was so pissed I deleted them all :doh: They were useless anyway (at least I thought so) - Jester seems to be bugged in terms of radar/target management. His first TWS Auto interactions seem to work fine, but as the situation gets "complicated", serious problems start appearing. For instance, Jester will arbitrarily start auto-locking distant contacts, even when there are other radar contacts on the nose which are way closer (even hot ones). Note that I'm not talking about DL contacts, I'm talking about contacts detected by my own radar (upper bracket)... they're definitely on Jester's screen (I'm quite certain of this because we're sharing it), but he simply ignores them. As a workaround, I try to "reset" Jester by commanding him to go radar silent or by switching to PAL. Sometimes this is enough to make him "see reason", but other times he'll keep locking on no-factor contacts, forcing me to go defensive without shooting. - PAL gave me a couple of "fake locks" yesterday As I understand it, the moment PAL gets a lock, it means a target has been detected within 15nm (it's an STT lock). Any phoenix launched under PAL lock should guide towards the target as it comes off the rails, right? I mean, this is how it normally works for me. Well, yesterday I got a couple PAL locks and the phoenixes simply went up to space, without tracking. Almost seemed like PAL was giving me invalid locks, somehow (Jester was also acting up, locking on to a really distant target, off to the side... it definitely felt like my radar was fundamentally bugged). Oddly enough, the third time I got a PAL lock, things went back to normal and I got my kill, pretty weird stuff. (And yes, my phoenixes were ready, I didn't forget to prep them) Unfortunately, like I mentioned, I can't provide tracks because they were all corrupted.

If I were you, I'd drop the "add unrealistic features, so I can keep doing things wrong" attitude, it'll do you no good, you'll never learn to fly properly like this. If you're breaking the wings, it means two things: - You're used to jerking the stick when you shouldn't - Your joystick curves need tweaking

Remove all traces of Java and LDT from your system, then follow this video (latest version of MOOSE is 2.5.0):

We should be able to command Jester to switch between TWS tracks without having to jump to RIO seat (which isn't possible in MP)

Did you just coin a new term for trashed missiles? I love it! :thumbup: Seriously, can I borrow it? I'll use it next time I do GCI :D

It certainly was, but I doubt they'll admit it. In any case, just ignore the naysayers, AWACS declaration option should work and I think there should be a Jester IFF command as well (since we can't jump on RIO seat in MP, for instance). As for visual identification, that's not always an option...and even when it's possible, if the enemy coalition has the same airframes available, it's pretty much useless. As for using comms/chat in MP, by the time you get an answer (if you get one), you're long dead. I second the motion that this is a serious issue and I hope HB will do something about it (seems that way, so ty). Another issue I've found is that there doesn't seem to be a way to command Jester to switch between TWS targets (if there is one, please let me know).

I believe that these Lua modules are sanitized by default for security reasons. It's up to users to decide whether they trust the scripts that require de-sanitation.

It only works with units/statics that are present at mission start. I haven't been able to make it work with spawned statics... and believe me, I've tried :cry: As for spawned AI units, it only works in SP and when hosting, but not when connecting to dedicated server... like I said, it's probably a DCS problem, nothing I can do about it.

When replacements are destroyed, that normally leaves craters / wreckage around, that's why I made it so replacements would no longer spawn there. In the absence of proper cleanup/airbase repair functionality (craters/wreckage can't be removed AFAIK), I don't see the point of resetting blocked slots... that would just lead to clients blowing up on spawn. As for spawned statics not being hidden and AI replacements remaining visible in dedicated servers, I'm afraid this is a DCS problem, not much I can do about it.

@pacastro The way it works right now, only replacements that haven't been completely destroyed will respawn. You probably didn't destroy the Ka-50 100% before taking the base, so it was the only replacement allowed to spawn (just guessing). This is still WIP, of course, there are several things to be done before I can release it. Also, DCS seems to automatically disable slots if there's wreckage around (not always, though). As for replacements not being hidden in dedicated servers, I was afraid that would happen. Also, I bet that if you change replacement type to statics, those choppers will spawn half-buried... Looks like I need to write extra code to make it work in dedicated servers... need to figure it out. I'll keep you guys posted.

@pacastro I have modified your test mission, it uses a new development version of SWAPR, which includes base capture mechanics. I've added some ground vehicles for both coalitions, a capture group, an atrillery group and a commander slot for each coalition. Red has a tunguska to the west of Anapa and artillery + tanks to the south. Blue has a Gepard and artillery + tanks to the east. If you own Combined Arms, you should be able to command all these vehicles, or drive them yourself. Feel free to blow up replacement aircraft with the tanks / artillery, this way you can test slot block as well. Anapa will start as Blue, only blue replacements will spawn. If you then move a red vehicle into the airbase area, it'll be captured (as long as there aren't any enemy vehicles within the same area... aircraft replacements don't count). Once the airbase has been captured, all replacements from the enemy coalition will be wiped, and friendly replacements will spawn. I've been testing it for a few days (both in SP and MP), all the obvious issues I found seem to be fixed. AI replacements are correctly hidden on map if I'm hosting the mission. Now all replacements will spawn cold (regardless of clients being set to hot start in ME) and without pilots (except for huey replacements). I haven't tested it on a dedicated server, though, so there's a chance some replacements will spawn half-buried there. Btw, the attached mission is set to run in MP mode, so you'll need the hook as well. Give it a try and report back :thumbup: swapr_test(SWAPR_1_3_1_mod).miz

@pacastro & anyone interested Looks like I managed to implement base/FARP capture mechanics in the development version of SWAPR. Only replacements belonging to the coalition that controls the airbase/FARP will spawn. When the airbase/FARP is captured, all replacements belonging to the previous coalition are wiped and those belonging to the controlling coalition are spawned. Need to do further testing before releasing it, but SWAPR 1.3.1 is looking really nice so far ;)

Told you... can't have it both ways until ED fixes this issue. Btw, I can't set them to "Takeoff from ground" or "Takeoff from ground hot" in ME... have you modified DCS files to be able to do that? I haven't found a way to force wheel chocks... it's either that, turn them perpendicular to/against the wind or force static replacements (but then they'd spawn half-buried as well, IIRC) The new attached mission has SWAPR set to static replacements, that's why Hidden_AI_Replacements isn't working. Warbirds at Sochi are still set to start in air. (If you have modified DCS files to have "Takeoff from ground" available for those planes, let me know. Keep in mind that SWAPR isn't meant to support people's experiments, though) There are still some units that have the same unit name (adding a blank space doesn't cut it for SWAPR). Example: Rome A10C = MercInc #014 Sochi L39C cold = MercInc #014 -- Same unit name with just an extra blank space... don't do that, use underscores instead of blank spaces, please

@pacastro Hidden_AI_Replacements option only works for AI replacements, not static replacements. This is explained in the video / OP / script comment Sure, I can look into base capture mechanics, spawn only those replacements belonging to the coalition controlling the base. Could be tricky to implement, though... we'll see. The hot start issue is already solved in my development build, but it's still not ready for prime time. As for pilots inside AI replacements, they only appear if the replacement is starting hot (unless it's a huey or harrier, I believe) Finally, please always provide the mission file + dcs.log in your reports.

Reducing size is always beneficial. If having to "shuffle files" is a problem, then let's have properly compressed textures, at least. No more 512MB livery nonsense (MiG-21, I'm looking at you :D). $100+ isn't what I call cheap (I'm only considering 500+GB SSDs, since 250GB SSDs wouldn't solve the problem, long term). HDDs are cheap, SSDs aren't (cost per GB is still high)... people are just getting used to inflated GPU/CPU/RAM prices, so SSDs seem cheap in comparison. Also, I don't share the "I'll buy a new SSD, just so I can store liveries that I'll never use or see in MP" mindset. Greetings :)

@zaelu I don't see any problems in the last mission file you provided, ww2 planes are sitting on their parking spots, like they should. Where are you experiencing problems with ww2 planes? Is it another mission? If so, please provide the problematic mission file, otherwise it's hard for me to troubleshoot.

Thanks for the suggestion, looks like the time has finally come for me to start using symlinks. I ended up migrating the terrain folder (which contains the DCS maps) to HDD and creating a junction for it in DCS folder... 82GB freed, jury is still out on performance impact. Still, I think that the livery department needs a serious overhaul, every GB counts. ;) (@Worrazen's proposal looks promising)

I'm afraid not. To improve perfomance a bit, you can disable sheltered replacements and reduce the total number of clients being replaced. I thought about that, but I don't know if it's possible. Even if it were possible, I still wouldn't know how to do it. See if I can come up with a fix... ;)

Please ED, remove unnecessary liveries from DCS builds, put them in separate packs, for optional download. MiG-21 livery folder alone takes 6GB, Christen Eagle's takes ~4GB... all in all, it's like 20GB of unnecessary liveries that I have to remove every time a new OB update comes around (due to limited space in SSD). Since the last big update, I'm forced to migrate the DCS folder to my HDD, update there, remove unnecessary liveries and then migrate back to SSD... it's no fun. I think it would be better for everybody to keep non-essential liveries as separate packs (faster downloads, less stress on the servers, fewer complaints from me...:lol:).

Liveries are ridiculously heavy, they should be separated from DCS builds and mede available as optional packs. MiG-21 liveries alone take like 6GB, it's ridiculous

@LTPERRY I didn't direct you to SWAPR earlier because it seemed overkill... but now that you've explained what you want to accomplish, definitely use SWAPR. I'm currently working on some fixes/improvements and a new tutorial video for SWAPR 1.3, in the meantime, I have a development version available that should work fine. Let me know if you're interested.

Which is why I provided the standard DCS code ;)