Nife

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:

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

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. ;)

. . . Making missions is tough, it really is. On top of learning a metric ton of scripting commands and SQF syntax, mission makers are also expected to extensively test their scenarios and hope to god everything falls into place as expected. Although it's a job that can feel unrewarding, make no mistake: without missions, no community can exist, and by definition, neither can the ArmA series. So how do we solve these two problems? How do we kindle the interest in making scenarios within the general player-base, without forcing people to spend precious time learning extensive scripting? Throughout the years, BromA - my community of choice - struggled with missions who had a standard of quality, something we could rely on and that wasn't gonna just break at one point or another, pissing off all players and ruining the session. And so, we've started to develop a template for all of our missions, which through lots of testing and debugging, would be stable enough to use and simple enough to be actually utilized. Long story short, as time went by and we got a bit better at scripting, here we are. The Framework comes with a robust and flexible Plugin system, which makes sharing functionality across missions super easy - take a look on what's already implemented. Another powerful feature is the ability to make your missions completely retroactive compatible with any gameplay mods you might want to use: in uses no modules placed from the editor, spawning them all through scripting. On top of making the mission.sqm cleared of clutter that might stop your mission from loading, this also means many module settings are linked to the mission parameters, enabling an unprecedented level of customization. Some of the features include: ACE3, AGM, TFAR, ACRE2, ALIVE and DAC are fully integrated. AI spawning system, complete with unit caching for performance. Cargo loading made simple. Casualty Cap and Body Removal. Casualty Cap for civilians. Commander Lock. JIPs handling. Limit player movement to the AO. Loading screens. Mission time limit. Respawn system with tickets and respawn waves. Setup Zones. Spawn protection. Tasks system which is very flexible and simple to understand. Team Roster. Team killing warning. Very effective Loadout System. Well organized and scenario-agnostic. Important note: this Framework absolutely requires CBA to run. You may need to use a modified version of DAC, compatible with HC to run this properly. Please keep in mind DAC is Silola's work and therefore we ask everyone to keep distribution to a minimum. Yes. Although we don't have any binds like DAC to make its use easier, it's still entirely possible to use ALIVE in your missions and several of our mission makers already have. This project was developed and grew alongside me and its contributors as a great learning experience. As one would expect, we utilized a lot of reference and cannibalized many scripts written by other awesome ArmA modders, so let me stress this as much as I can: although the vast majority of the scripts utilized in the framework have been extensively modified to fit in as a proper Plugin with many hours dedicated to make everything would work, credit to the original authors is fully retained and this is in no way an attempt to upset anyone. That said, this Framework is open-source and free for everyone to use and abuse; if you want to credit me for any of it go ahead but otherwise I really don't care. However, the same might not be true for the authors of the original scripts so please be considerate and don't remove the licenses I've included. List of all Framework contributors. Special Thanks: Ferstaberinde for his work on the F3 Framework and Naught & Olsen for the Core Framework, which basically inspired this one into existing. The BromA and /a3g/ communities, for being nice sports and keeping things always fun to be around. You, for reading all this crap. Although in the future I plan on making a series of video tutorials explaining how to properly utilize every aspect of the Framework, so far the best I've managed is a bunch of dumb streams of myself making missions. This might help you get started on it, but otherwise I recommend the Wiki for documentation. This project is young and still has a long way to go: If you run into some trouble or just have any questions, please hit me up on Steam any time and I'll get back to you ASAP. As a small side note, someone has taken the time to impersonate me on reddit; I do not ever post there so please, kindly ignore whatever is in that account. We hope this Framework helps you to finally make those mission scenarios you've always wanted to make, and then more. Thanks for giving it a shot!

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)

Version (0061) release! Sorry about the delay, we've been a bit busy recently. Changelog: Updated DAC Events to change the loadout of the crewmen from spawned vehicles. Updated the garrison script by Zenophon to its latest version. (#27) Removed the scaleUnits function as it was useless. (#31) Removed unused variables from the DAC plugin's dictionary. (#31) Fixed AI Spawn script issue where AI needed invisible helipads to land on rough terrain. (#32) As usual, grab it on GitHub. I also just want to thank everyone who's been using it and giving some feedback, it was really cool to see people making some use out of it.

Sure thing man. This is a mission in Isla Duala where you have to capture some stuff; it might be a bit out-dated but should be good enough reference - link. Just for the sake of it, another mission in Altis where you have to find some hostages; lots of AI and the objectives are randomized - link. Hope this helps, let me know if you want any specific type of scenario.

You don't necessarily need to disable any plugins in order to use ALIVE, however if you want to save up on some filesize, go right ahead and remove whatever you don't want by commenting the line out from framework\plugins\plugins.cpp and then deleting the folders. Adding functionality into the Framework is not only super easy but one of its strong points: you can use the same methods as cfgFunctions or Params. Check framework\plugins\blank_plugin for an example on how to write your own. Thanks for the feedback on that, I'll link the modified DAC so that everybody can use it. That's really weird. Make sure you also delete the waypoints?

Just tested it myself and everything working right away. To make sure: Run the game with CBA. Make sure DAC is also running, use this version if you want to make sure. You should have a 250m² blue circle within the BLUFOR spawn, and the DAC prompt will notify you of the units spawned. Currently if you run the game with neither AGM or ACE3 you'll get a script error relating to the default medical system included in the cargo, but that won't at all affect the AI spawning. If this persists, feel free to paste your mission_AI.sqf file here.

Are you using the mission\objectives\mission_AI.sqf file to spawn the AI? Take a look over the documentation if you haven't. Another possible thing is that we use a modified version of DAC which I didn't want to redistribute publicly since it's Silola's work, but give it a try see if it solves your problem. As for those units running, apologies for not making that clear in the documentation: that's an example on how to transfer units to the Headless Client, by setting their unit probability to 0%.

Sorry for taking so long on the reply! The DAC functions should work right out of the box, yes. In what context are you trying to use it, and what errors are you getting? I've also added a note regarding CBA: yes, you absolutely need it to run the Framework. Not at all. In fact, if you don't wish to use DAC, simply disable the Plugin from framework/plugins/plugins.cpp and delete the folder from the base. And no, he plays in another group now.

When I started to work on this Framework, I was pretty green on mission making and scripting in general, so as I made them new scenarios, the need for recycling scripts constantly arose, which led me to look for some sort of template. For a loooong time it was just the F2 Framework, but as time went by we started to modify and build upon it, until up to one point it became a very different thing. ArmA 3 rolls in and I decide to basically rewrite the entire Framework to fit into a structure of "engine/plugins/context", and so after like three months of constant work other people started to build upon it with loadouts, plugins, etc, in order to fulfill all the features we deemed important to our own missions, and at that point it became a pretty unique thing. The reason why I'm being roundabout and just telling you why it became the way it is, is that it's hard to answer this sort of question without making it sound like some sort of competitive advertising: I use our Framework instead of F3/Core/Zenophom's because personally I consider it to be very feature complete and stable enough. Although I'm very confident in the quality of this project, I still recommend you give everything that's out there a try. Hope this helps. ;)

In what way? I don't want to say one is better than the other, different designs and all.

Thanks a lot foxhound! However, do you think it would be possible for me to edit this page or submit my own? EDIT: Done so, waiting for it to be approved.