Nife

Awesome work man, keep it up. I still lurk the forums from time to time, feel free to drop me a DM whenever you think you're finished with your work. And don't worry about the license, feel free to play with the source code as much as you wish, it's all yours.

Thanks for the reply. Is there an example of what the CBA settings should look like and where should I put them? Or will just run these scripts on preInit fix it?

Is there are reliable way of setting the side frequencies for LR radios to be the same in 1.0? Currently trying during postInit: TF_same_lr_frequencies_for_side = true; And on the server: ["TFAR_SameLRFrequenciesForSide", true, true, "server", true] call CBA_settings_fnc_set; But still the same thing, everyone has their own frequencies - it's pretty damn frustrating. Would really appreciate some help on this one, thanks in advance!

HOW DID I NOT THINK OF THAT

We love it. It's the AAR tool we couldn't even ever dream of having. Seriously, it's awesome and please continue working on it.

Yeah, it does. It's basically made entirely for ACE3.

Update 1.0.5: The mod is now available in German! Huge thanks to nic547. Remember, if you wish to contribute, Tabler is an excellent tool! Dispensers now have a property for a specific barrel, so it's now possible to add dispensers that give you different barrels. You can now spawn dispensers with Zeus. Added some safe distance between the helicopter and the barrel, as some vehicles like Little Birds were a bit too close and would sometimes be damaged. Latest release

An unofficial extension Workshop GitHub "War is expensive: from laser-guided missiles to large-yield bombs, getting things done can be hard on your pocket. When funds start going low and budget cuts roll in, that's when warfare becomes about improvising and being creative. Sometimes, that means dropping barrels loaded with TNT and shrapnel on refugee camps." - The Guy Who Invented Barrel Bombs (probably) Description So both in celebration of the Laws of War DLC, and Al-Assad's birthday, I've decided to give myself the challenge to make a mod which in my opinion was long over-due: the ability to deploy Barrel Bombs in ArmA 3. After about three days of intense development, it's finally ready to ship: Customize the payload according to your strategic needs, load it into a helicopter, and drop away! How to use In the editor, search for and place Barrel Bomb Dispenser (Large) in your mission. ACE Interact with the dispenser, and Prepare a Barrel Bomb. You may now select between the types of fuse (Air-burst or Impact detonation), and the strength of the payload, or how many cluster munitions will be included in the barrel. If your dispenser has enough materials remaining, hit CONFIRM. As soon as you're done, a new barrel will appear, ready to be loaded. You may also inspect any barrels and read their label in order to confirm their properties. Carry the barrel to the desired Helicopter, then Prime and load it. Keep in mind that vehicles only have a limited amount of barrels that can be loaded - all barrels take up the same space. From the Helicopter - as either the pilot, copilot, or turret-gunners - ACE Interact with the vehicle and Check Barrel Bombs. Select the desired barrel and simply hit the confirmation button. F.A.Q. Yup. Should work with all Helicopters, I reckon. You bet. Both for self-hosted servers and Dedicated, works all the same. Use this function. Start an issue on GitHub. If you don't have an account there, use the Steam Workshop discussions. If none of these methods is accessible to you, then you can reach me on Steam and yell until things are fixed. Kind of. Regardless, be careful whenever deploying over a populated urban environment, as the paramedic/journalist/child-seeking shrapnel module is currently active, and it never misses. Sorry, not at this time. Shout-outs BromA, for being the coolest group of badasses autistic losers out there. McGabe and Wronglets, for helping me test this thing. The ACE3 Team, for keeping their mod the way all mods should be: open-source and extendable by the community. Cheers, fellas. And of course, Bashar Al-Assad, for re-popularizing this absolutely reprehensible, but still very amusing type of ordinance. Happy belated birthday! License This mod has absolutely no license whatsoever. Steal it, repack it, rename it, stretch it, twist it, lick it or suck it, it's your problem, I really, really don't care. Just to be real clear, you ARE free to: Unpack this mod and edit the everliving shit out of it. Rename it into something else and claim credits for yourself. Sell it or commercialize it, which in that case you've found someone stupid enough to buy it so my personal congratulations. Re-upload or re-repack it on any other website or re-distribution service, just don't blame me if your version is out-dated. Using it for real-life military purposes of any kind. Actually, if this mod ends up being used by actual armed forces for training, someone please let me know so I can tell all my friends and family about it. However, If you do plan on improving it it, this mod is stringtabled and can be translated - so that and any other contributions are better off done at Github so everyone else may benefit from it. AND REMEMBER KIDS:

Any hopes we'll be seeing the ACE3 damage fixed for the weekend? A lot of the communities I know have already dropped this for any possible Halloween events (which is a huge shame), but I still want to wait a bit more before declaring it a lost cause.

This is a really great step on the right direction, I'm very excited about smoke being finally useful again. However, judging by the last scene in your demo video, I had the feeling that the obscuring area for the AI is a bit too large, to the point where you had clear sight on the enemy and yet he would not open fire himself. I'm a bit concerned this can affect the balance of the game. Either way, very nice, keep it up.

Just finished setting this up on my community's server, and I have to say that "impressed" doesn't even begin to describe how amazed I am at the technical work you've put into this, with so much polish and stability even at beta: the installation process was very streamlined and easy to understand, and aside from the deflated GZIP issue some people have had as well, everything eventually worked like a charm bar my own lack of paying attention. Some features I personally would like to see in the future: Being able to go back/forward in the playback, otherwise it's a little bit annoying to rewatch specific moments. Ability to define custom Events that would be later displayed, any string would already give mission makers a lot to work with. Opening the list of replays without having to refresh the page. In any case, congratulation to the creator - this is a fantastic project and I'm very excited to see how will it turn out.

After reading through the thread, I would like to leave my two cents on this matter. Before anything, I need to go on record on congratulating BI for their excellent work on EDEN, which was a sorely needed improvement over a tool that's already far beyond its life span - thanks for listening to the players and working as hard as you do, we all deeply appreciate it. This post is in no way an attempt to advocate against EDEN - just hopefully bring some attention to its flaws so that they can be fixed and everyone is happy. However with that said, I have to say that under its current state, EDEN is not yet ready to substitute the 2D Editor. Now, it seems that if this thread is anything to go by, people assume that this is some knee-jerk reaction to change and that we are all grumbling haters with nothing better to do, but I'd ask those with this point of view to reconsider over how stupidly simplified that sounds: development of either missions or addons in ArmA takes many shapes and forms, and I think that before completely scrapping the tool we've used for nearly a decade, some further improvements are required in order not to alienate those out there making content for the game. With this in mind, I'll list some of my concerns and annoyances with EDEN - some small, some big - and hopefully this will make things a bit clearer to those unable to sympathize with our stance. The loading times These have already been mentioned in the very OP, but just to make sure this doesn't go unnoticed: EDEN has lots of moments spread out through its workflow where it'll hang up for an increasingly annoying amount of time, in particular during loading a mission, and going back to the editor - things that for most mission makers will go down as a minor inconvenience, but if you make addons or work on scripts, you will know that this is a major pain in the ass. I have to be honest, this sort of soured EDEN a bit for me, because it was just that tiny thing that managed to taint perfection. If improvements could be made around this area and bring the speed back to what it used to be, I would gladly kiss the 2D Editor goodbye with no regrets. Not reading description.ext Headers EDEN has the great functionality of editing variables previously only accessible through editing the description.ext file, which is awesome, but for some scenarios this can be quite confusing. Case in point: I maintain a mission framework which makes use of extending the description.ext class Header in a separate file. It has already occurred to have people asking which is the valid one and if those are now obsolete and what-nots. Of course this is much more of a case of adapting, but it would really be great if EDEN could read and fill the relevant fields into class CustomAttributes from the mission config whenever loading, in order to avoid confusion and redundancy. Weird scripting behavior Now this one I'm leaving last because I'm not sure if I can call this a bug or if this is by design - either way there should be a solution to this issue, so if you don't mind I'll get a bit technical. In the previously mentioned framework I maintain, there has been a bit of a weird behavior I've noted: in the task condition checker script, once I run the mission once and return to the editor, for some reason the while loop declared in line 32 will keep running, which will result in script errors since the objects being checked do not exist within the context of the editor itself. I'm going to assume this is a simple matter to fix and so if anyone has any ideas on how to work this out, I'm all ears. Binarized mission.sqm breaks everything This one I'm leaving left because it was fixed very quickly and once again, for all I know might just be an issue with legacy code. With that said, running the framework with a binarized mission.sqm will basically break every single damn script running, with no survivors. However since this is easy to fix, I'm not really upset. It's too damned good and I feel awful for not making full use of it while sticking to the 2D Editor OK, this one is obviously not a real complaint but it's still true to I'm sure most of us complaining ITT. I love EDEN and I am looking forward to what people will make with it, but for us who like to use ArmA to script and make dumb addons, there are still too many things that need to be worked out. Just to make sure: a huge thanks to BI to get this far with the in-game editor. I for one am very excited for Apex and I'm sure it'll be a huge boost to the game's popularity - but in the middle of all this excitement, I would like to ask for some extra attention with this particular group of users which have been supporting the game in their own way for a long time. ;)

Version (00631) This is a very small patch that fixes an issue with ACE3, where the scores from deaths wouldn't be given to the appropriate killers. It uses a bit of a workaround but it seems to work just fine.

Version (0063) release! Featured in this release is a brand new plugin made from scratch for the Framework: the Round System. Following the philosophy of always making mission making as easy and automated as possible, this plugin aims to provide a sort of second-layer framework to make TvTs which rely on quicker rounds, instead of long and drawn out fights. The Round System plugin was designed and coded from scratch to be a very flexible and easy to use, and as the name suggests, manages rounds. Features include but not limited to: Choose how long rounds last, how long players can prepare in between and the interval time between them. Define the condition for victory in a round, with either complex expressions, percentage of casualties taken, or simply decide who wins by default when the timer runs out. Of course, you can also choose to end it in a draw. Setup zones so that players may only stay within their designated spawns before the round starts. Supports multiple spawn zones per side. Display round info such as points every round end. All these features are heavily automated and can be configured in few minutes of changing just a couple of settings. If you wish to modify the script yourself, all events are clearly named and organized by server/player, and if necessary, you are encouraged to alter them to fit your own scenario. Of course, that wasn't all that was added with this update: read here for all changes. As always, thanks for everybody who has shown their support, added me on steam asking questions, and to those who contribute to the development of this project.

Good stuff. B)