Search the Community

MISSION MAKER FRAMEWORK for ARMA III, ver. 0008 (2021) This MODULE is compatible with BASE GAME (current version) MMF is an easy-to-use function library for mission designers. Live readMe Discord Channel (new) Change Log (new) FAQ (new) MMF Version 8 (install to mission root) (dev) MMF_vX (drive) (new) Demos (new) Images Features Have fun! Credits: Soolie Build Menu GUI SmartGames Function Configs Custom Notification Benchmark, Mr Pants Playtesting Arma Public License No Derivatives (APL-ND) Use:

Here's a couple fire related functions, you_createFire, *Updated you_fnc_houseFire (demo), Burn buildings to the ground! Spawn one central fire with smoke and a number of FX fires (performance) in the building. The building takes damage over time. Once the building is destroyed the performance fires are deleted and later the main fire. Fire will spread based on the distance supplied to the function ("_dist"). Use the parameter "_damage" (default true) to make persistent fire that does not damage the building over time or spread to other buildings.* Use parameter "_time" to determine how long each building will burn (default: 10, demo: 1). 1 second is equal to 20 seconds total burn (each iteration is %10 damage) and the main fire burns for the same amount of time again (1x10x2). The default value is 10 or 200 seconds (100 to collapse and 100 more to extinguish). 1) create a helper object on/near the building(s) ** 2) paste the function in init.sqf (or wherever) 3) see call methods in demo init.sqf * keep track of effects in the supplied array ** editor placed buildings may be "_caller" Have fun!

The latest version of the Simple Radar Warning System, Functions, Vehicle init (for automatic system arm), Player manual system switch, Configurable function call, Fly safely and... Have fun! File Download (Drive) *Original Post*

Access Points A simple to use system which allows mission makers to easily setup access points that allow players to reach places they wouldn't be able to normally reach (but should) *whew*. Why'd I make it? Because Tanoa looks pretty, but the skyscrapers don't have interiors, making players unable to access the rooftops by foot. Download: http://files.bitdungeon.org/arma/AccessPoints.Tanoa.v0.3.zip Multiplayer Compatible! Updated on 6-9-2016 Demo Video License http://www.gnu.org/licenses/gpl-3.0.en.html Setup Preliminary: Copy the "AccessPoints" directory into your mission. Copy the "execVM" statement into your mission's "Init.sqf". 1. Find yourself a nice building that you want to rig. 2. Place a trigger that you want a player to enter to access the roof. 3. Resize the trigger to better fit the doorway (optional) 4. Change the "Text" attribute of the trigger to follow the format "AccessPoint_UniquePairNameHere". This distinguishes this access point pair from the others. 5. Apply the change to the trigger text. 6. Copy the trigger (or create a new one, if you hate yourself). 7. Paste the trigger at the position you want players to be able to access. 8. Tweak the rotation and scaling of the new access point to your heart's desire. 9. Start the scenario and test it out! 10. Boom! That's it! You got it done like the badass you are. Changelog

Hi, I just want to open this post for people who want to test with the New Rewrite of ACE Medical. It is a very simple script that can help you understand the states in which the new medical system alternates. I hope you find it useful. init.sqf addMissionEventHandler ["Draw3D", { { _unit = _x; if (!(isNil "_unit") AND ((side _unit) == west OR (side _unit) == civilian))then{ _pos = ASLToAGL getPosASL _unit; _headPos = [_pos select 0, _pos select 1, (_pos select 2) + 1.2]; _heartRate = _unit getVariable ["ace_medical_heartrate", 00]; _bloodPressure = _unit getVariable ["ace_medical_bloodpressure", [00,00]]; _bloodVolume = _unit getVariable ["ace_medical_bloodvolume", 00]; _Text = format ["HR: %1 | BP: %2 | BV: %3",_heartRate toFixed 1,_bloodPressure,_bloodVolume toFixed 1]; drawIcon3D ["", [1, 1, 1,1], _headPos, 0, 0, 0, _Text, 2, 0.03, "PuristaBold"]; _headPos = [_pos select 0, _pos select 1, (_pos select 2) + 0.5]; _state = _unit getVariable ["cba_statemachine_state0",""]; _text = ""; if(_state == "cardiacarrest")then{ _text = format["cardiacarrest (%1 s)", (_unit getVariable ["ace_medical_statemachine_cardiacarresttimeleft",0]) toFixed 1]; }else{ _text = _state; }; drawIcon3D ["", [0.1, 0.45, 1,1], _headPos, 0, 0, 0, _text , 2, 0.03, "PuristaBold"]; }; } forEach allUnits; }]; Spyke

Base Builder for ARMA III, ver. 0001 (2019) This MODULE is compatible with BASE GAME (current version) Base Builder under construction... Download: you_fnc_camp readMe: Arma Public License No Derivatives (APL-ND) Have fun!

My two current projects contain dozens of script references from this forum all in one place with a script description text to find what you're looking for. JET TOYS SWO Mission Control DEMO If you're an experienced script writer you probably won't learn much from the references. However you're welcome to make suggestions for improvement. Keep in mind the theme of making simple scripts that are accessible to new users and not fellow computer science majors. This forum page is WIP and will expand as the above projects progress.

*********************************************** Sarogahtyps Spawn Script Creator - SSSC Alpha 0.5 the easy way to cache ur units, vehicles and their waypoints by Sarogahtyp Gives mission designers the ability to delete and spawn their editor created units, vehicles and waypoints as often as they want and at the time they wanna. Its partially very similiar to Jebus - Just Editor Based Unit Spawning written by @dreadpirate but has complete different way of using and of course very different scripting methods. Actual version: Alpha 0.5 Key Features: units and vehicles spawn with the same behavior, damage, loadout (and so on) as they had before they were deleted waypoints are synced with other waypoints and triggers as they were before they were deleted every spawned object has the same group assignement as prior deletion see the full list of what is stored and reset after spawning in spoiler: How to apply this script to your mission: Download and unpack the .rar file. copy the content of the folder "SSSC" to ur mission root. If u already have a description.ext then integreate the one in SSSC to your own description.ext If u have a whitelist for remote execution of commands in your mission then you have to ensure that the following commands are whitelisted because they are remotely executed (HowTo): setVehicleVarName How to use this scripts functions in your mission: everey function returns true if it is ended. thats usefull for checking if its ended when using spawn instead of call. ----------------------------------------------------------------------------------------------------------------------------------------------------------------- 1. you have to mark one unit of each group which should be handled (saved, deleted, spawned) at the same time: saroSSC_fnc_mark [_unit, _index] call saroSSC_fnc_mark; _unit is those one unit of the group which should be handled. _index is a number chosen by you to differentiate sets of groups to handle. Example: if u have 2 groups ( A and B ) which should be deleted at start of mission and another group ( C ) which should be deleted after its done something then u mark like this: In the init field of one unit of group A and one unit of group B: [this, 0] call saroSSC_fnc_mark; In the init field of one unit of group C: [this, 1] call saroSSC_fnc_mark; now group A and B r marked with index 0 and group C with index 1 ----------------------------------------------------------------------------------------------------------------------------------------------------------------- saroSSC_fnc_save [_index] call saroSSC_fnc_save; Use this function at the time u want to save the actual behavior of ur prior marked groups. At this point all information is saved and your groups will be spawned later with the behavior of this point of time. [0] call saroSSC_fnc_save; [1] call saroSSC_fnc_save; ----------------------------------------------------------------------------------------------------------------------------------------------------------------- saroSSC_fnc_delete [_index] call saroSSC_fnc_delete; Use this function at the time u want to delete all objects and waypoints of ur prior marked and saved groups. [0] call saroSSC_fnc_delete; [1] call saroSSC_fnc_delete; ----------------------------------------------------------------------------------------------------------------------------------------------------------------- saroSSC_fnc_spawn [_index] call saroSSC_fnc_spawn; Use this function at the time u want to spawn all objects and waypoints of ur prior marked, saved, and deleted groups. Ensure that there is a small delay after using this function until all objects are spawned. This is neccessary because this scripts contents are spawned (scheduled environment) and run parrallel to other stuff. This is the only function which uses scheduled environment because it needs some more time/performance. [0] call saroSSC_fnc_spawn; [1] call saroSSC_fnc_spawn; ----------------------------------------------------------------------------------------------------------------------------------------------------------------- saroSSC_fnc_destruct [_index] call saroSSC_fnc_destruct; Use this function at the time u dont need the information stored with saroSSC_fnc_save before to free some memory. After using this function u could use saroSSC_fnc_save, saroSSC_fnc_delete and saroSSC_fnc_spawn again on the same marked sets of groups. [0] call saroSSC_fnc_destruct; [1] call saroSSC_fnc_destruct; ----------------------------------------------------------------------------------------------------------------------------------------------------------------- saroSSC_fnc_unmark [_index] call saroSSC_fnc_unmark; Use this function at the time u dont like to do anything with ur prior marked set of groups. After using it u have to mark again first before u can save, delete and spawn. [0] call saroSSC_fnc_unmark; [1] call saroSSC_fnc_unmark; ----------------------------------------------------------------------------------------------------------------------------------------------------------------- saroSSC_fnc_update_triggers call saroSSC_fnc_update_triggers; This function is needed only if mission designer creates triggers by script during mission. It should be run after such scripted trigger creation to update known triggers. Thats neccessary because SSSC gets all triggers at mission start only. no arguments and no return value. ----------------------------------------------------------------------------------------------------------------------------------------------------------------- saroSSC_fnc_set_options This function can be used to choose which options should be saved and restored. This is useful if u dont want to save everything which is featured. Less saving means more performance. See fn_set_options.sqf header for further informations. this function has to be called before saroSSC_fnc_save. it will destroy all allready saved information because of array structure changes. ----------------------------------------------------------------------------------------------------------------------------------------------------------------- Planned features: implement option to pass mission designers custom code for execution after spawning (like EHs) store and reset units trait - DONE store and reset units hitparts - DONE store and reset vehicles hitparts - DONE store an reset vehicles loadout - DONE add killed EH for group leaders to ensure group handling works after leader died - DONE add function to update known triggers (if someone creates triggers during mission) - DONE add options array to switch storing of specific info on/off - DONE relase BETA version add function to copy the whole spawn script to clipboard. with this feature mission designers are able to create their own spawn script without saving all information to memory during mission. release FINAL version armaholic release page Script Download (Dropbox) Example Mission (Dropbox) Known issues: 1. A set of group with e.g. index 0 cant interact with waypoints or triggers of a set of groups marked with 1. If u need to interact groups with the same waypoints and trigger then you have to ensure that they are marked with the same index. 2. Found a bug if a group waits at a join (or join and lead) waypoint for the other group and then using save, delete and spawn methods at this situation. Both groups r double spawned if that bug encounters and after that they behave weird. I think I know why that happens and will fix it soon. Changelog: V 0.5 Alpha - 07.06.2017 fixed a bug with editor given variable names (thx for report @gavc) added saving of stuff in backpacks, vests and uniforms inside of vehicle inventories. added saroSSC_fnc_set_options - now u r able to set saving options for units and vehicles. see fn_set_options.sqf header for further informations. this function has to be called before saroSSC_fnc_save. it will destroy all allready saved information because of array structure changes. added support for setFace and face added support for setNameSound and nameSound added support for setPitch and pitch added support for setAmmo and ammo added support for setBleedingRemaining and getBleedingRemaining added support for getOxygenRemaining added support for unitRecoilCoefficient restructured some array for faster handling V 0.4 Alpha - 13.06.2016 added new function saroSSC_fnc_update_triggers to update known triggers added vehicle loadout support substituted some forEach with count to speed up things a bit did some clean up work on scripts added killed eventhandler to leaders to get script also working if a leader dies added support for partial hitpoints of units and vehicles. V 0.31 Alpha - 09.06.2016 fixed a bug with muliple deletions and spawns, it was not working - now it is added handling of units trait (medic, engineer, explosiveSpecialist, UAVHacker, camouflageCoef, audibleCoef, loadCoef) V 0.3 Alpha - 08.06.2016 Initial Release Enjoy! *********************************************** Development Section in this section u can get information about the progress since the latest release and you can get a downloadable dev version with an own changelog and an own dev version number, too. I added that section because I want to give mission designers the ability to add all new features as soon as possible without bothering foxhound everytime I added 2 or 3 commands to the scripts. next steps: global: fix bug desribed in known issues (double spawning maybe caused by group unification and seperation) add function to pass custom code which will be executed after spawning. that could be EHs or disable AI commands or whatever u like. add support for allVariables, getVariable and setVariable units: add support for getObjectTexture and setObjectTexture vehicles: add support for setCollisionLight and isCollisionLightOn add support for getFuelCargo, getAmmoCargo, getRepairCargo add support for isLightOn and setPilotLight add support for locked and lock add support for lockCargo and lockedCargo add support for lockDriver and lockedDriver add support for lockTurret and lockedTurret add support for canUnloadInCombat and setUnloadInCombat add support for getObjectTexture and setObjectTexture groups: add support for setGroupIdGlobal instead of setGroupId release: release Beta version actual dev version: none Changelog since latest relase: none download link: none

. . . 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!