Zenophon

Update Overview Greetings fellow Armaholics, after a long time, I have updated this mission to use my latest framework and made a few minor tweaks. The main benefit of this is that all supports are integrated into my framework's support dialog. Changelog 3/12/16 Fixed: AAA Site vehicle is no longer drivable Fixed: AAA Site vehicle now contains enough explosives to destroy it Improved: Various improvements and fixes included in my latest framework Note For those who wish to edit the mission to add Virtual Arsenal to the insertion helicopter or the ammo box support drop, the code for this is in the correct place and merely commented out (just search for the text 'Virtual Arsenal' in the init.sqf).

Update Overview Greetings fellow Armaholics, after a long time, I have updated this mission to use my latest framework. Changelog 3/12/16 Improved: Extraction task title and description Improved: Various improvements and fixes included in my latest framework

As biggdogg says, the fifth parameter must also match the classes you want. Here's an example specifically for RHS: _group = [_pos, west, "SOF", 4, "rhs_vehclass_infantry_ocp", "rhs_faction_usarmy_d"] call Zen_SpawnInfantry;

For AI you can spawn them again with Zen_SpawnInfantry and use ZEN_FMW_Code_GiveLoadoutsOrdered with either the preset loadouts from Zen_GiveLoadoutBlufor et al. or a custom loadout. The custom loadouts have a demonstration detailing how to format them and use Zen_GetUnitLoadout. As for players I would use Zen_GetUnitLoadout and apply it with a MPRespawn eventhandler. You can refer to the Respawn Patrol sample mission or several of the tutorials for dealing with respawning players. I don't think there's an example specifically for reapplying the same gear, but getting the loadout with a killed/dammaged EH should work. As biggdogg said, if you post here I'm of course to going to suggest framework functions and help you use them. If you're looking for an all-in-one respawn system that's easy to use, you can probably find something searching around or making a request thread that outlines your specific needs.

Update and Release #41 Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the links to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog This release sees the final upgrade to the Support Action System and the first new function in almost 5 months. I've dropped 'Fire' from the name as it now supports custom functions in which scripters can do anything they want. These custom supports are added using a new function and integrated into the existing data management function (I didn't change the names so as to save users the trouble). A custom support shows up in the menu like the fire supports and is of course MP and JIP compatible. The custom supports can be canceled after 10 seconds, so to prevent abuse by players I suggest waiting 10 seconds in your support function before doing anything. A cancellation by the player will terminate your support function's thread. Custom supports run local to the player that called them. The arguments given to your custom function are included in the documentation for Zen_AddSupportActionCustom. 2/9/16 Code Example In this section, I will present a function or piece of code that shows something not present in the existing documentation. These examples are adapted to be general, accessible, and customizable. They are meant to be useful to mission makers who want to include the code as part of their mission, as well as those who want to learn general coding techniques and specific framework implementations. These are not contrived or coded with any specific skill level in mind; they are taken from full missions I have finished or am working on with minimal changes. Of course, if you have any questions about an example, suggestions or your own example to present, or find any bugs, please let me know. Our first example is a straightforward roadblock function. Its only parameter is a marker; it uses the direction of this marker to orient the roadblock, making the direction easy to determine visually in the editor. It spawns an MRAP and two guards on the road as well as guards patrolling beside the road and a supply truck. It returns all the AI units spawned, the supply truck, and the MRAP in an array. You can change the side, the vehicles spawned, the skill and number of the AI, give different loadouts or put equipment the vehicles, etc. to customize this to suite your mission.

The function f_SupplyDrop (line 152) handles all of the non-artillery supports. In the case of the ammo box, the box is spawned before being dropped so that its contents can be customized. You can add the VA action after the addMagazineCargoGlobal commands (lines 169-175); it must also be MP synch'd: // ... _supplyClass addMagazineCargoGlobal ["Titan_AT", 2]; _args = ["addAction", [_supplyClass, ["<t color='#2D8CE0'>Virtual Arsenal</t>", {0 = ["Open",true] spawn BIS_fnc_arsenal;}, [], 1, false, true, "", "(_target distance _this) < 3"]]]; ZEN_FMW_MP_REAll("Zen_ExecuteCommand", _args, call) }; _index = ([Comm_Support_Array_Local, (_this select 1), 0] call Zen_ArrayGetNestedIndex) select 0; // ... I didn't test that, but it should be mostly correct. This mission is long overdue for an update, which means at the minimum redoing the support options to use my framework's overhauled support action system (it will still be easy to add VA).

Zen_SpawnInfantry dynamically reads the config file using Zen_ConfigGetVehicleClasses to find units to spawn. Every unique search is saved by Zen_ConfigGetVehicleClasses and reused if the same search parameters are used again. The searches must run again each time a mission runs, and the search time is largely dependent upon the simulation's framerate. You can avoid having to do this during the mission by using the engine down-time (and hence high framerate) during the briefing (shift-click on the preview button in the editor to force the briefing to appear) to quickly complete these searches and allow Zen_ConfigGetVehicleClasses to automatically save them for later. Something like: There's no need to assign the result to a variable. If you are giving specific factions or other class types to Zen_SpawnInfantry, you can prime those as well here (use Zen_ConfigGetVehicleClasses's documentation). A few seconds spent looking at the briefing is all that should be needed to complete every search. Also, SQF is not truly multithreaded; there is only one engine thread serving as a SQF virtual machine (the compiler/translator that makes SQF code change the state of the simulation). 'spawn' creates a logically separate thread that is rotated through this single VM along with every other SQF thread. Thus, spawning something like Zen_SpawnAmbientVehicles allows the init.sqf to have a share of the processing time rather than halting completely, but it's at the cost of speed to both threads.

I'm familiar with how github works; I'm thinking of potential users who aren't aware of that. People will have questions like: Which version do I use? Can you fix a bug in this other version? When will you add feature X from fork Y into the main framework? How do I combine features from multiple forks I've downloaded? It's not that I'm against open source software. It's that a closed development has allowed me to design the API carefully and deliver a cohesive product. I encourage users to write their own scripts that rely on the framework; for example, if someone writes a revive script that uses framework function as part of its code, I'll promote that in this thread. Those are extensions to the framework that enhance it for users but are not directly part of it. I choose what I add to the framework carefully based upon what existing feature it could improve or if it would really add something useful or unique. For example: the dialog system; everyone seemed to be writing their own dialog configs and using SQF GUI commands (lbAdd etc.). So I took a different perspective and created a high-level GUI programming system; it turned out fairly well considering the limitations (I can only dynamically create built-in BIS control classes). I limit the framework to generalized, widely usable functions (whether they are large or small). Another issue is that the framework is approaching 15 thousand lines of code, and while the public documentation is complete, there is no internal documentation about how things are actually done (there aren't even more than a few comments in the code); even the function documentation follows a bunch of formatting rules. If someone has a bug report or a feature request, it is much faster that I do it than wait for someone to code it on their fork (then I still have to do QA and documentation for it). That's sort of a long-winded reply, but I just wanted to explain my thought process and reasoning for anyone who's interested. Also, it's been a while since I put this request out there: if anyone has a function or system that you've created as part of a mission that you think would be useful to other mission maker, release it. The best way to design scripts that other people can use is to see what's useful to you when making a mission.

I have considered github, but the biggest issue for me is that I have to be able to guarantee the quality of the framework. I'm not saying this would happen for sure, but if I put the framework on github and a dozen people fork it, there's an issue with version control. A wiki might be nice, but the strength of a wiki or any web documentation is the ability to link to other pages. The vast majority of documentation is self-contained function descriptions or sample code. Using the Notepad++ function hints is just as fast as searching a wiki, but people who don't use Notepad++ are left out. Maybe a Sublime Text SQF and function hint plugin would be nice, but don't use ST and don't know how to make a custom language for it. Develop of the framework is about 90% done; of course there are hundreds of potential things to add, but most of them don't fit the framework's premise. I think confused people a little when a picked the word 'framework'; 'function library' really is a better name. It's a base to code on more than a 'plug-in' system. Thanks, I'm glad other people don't have to repeat all the work I did go right to creating missions.

It should be: _altistownMarkers = [["NameVillage", "NameCity", "NameCityCapital"]] call Zen_ConfigGetLocations; However, that appears to be the same line that's in the most current release. Check that you've updated to the latest version; use the google drive link to be sure.

Update and Release #40 Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the links to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog Another framework release welcomes you to the new year. This release contains mostly improvements and fixes for Zen_AddFireSupportAction and its fellow fire support action functions. Now each fire support is menu entry on a dialog, and the dialog is accessed via an action by players who have supports available to them. Bugs have been fixed, the MP synchronization streamlined, and cancellation improved. The order of arguments to Zen_AddFireSupportAction has changed, correct those if you are using guided supports. A note for players, please use the refresh button provided on the fire support dialog. The dialog will never update itself automatically. I've tried to eliminate any errors or incorrect behaviour that occur when the dialog is not refreshed, but it's better if you just refresh. A note for mission makers, please update the framework #includes in your description.ext to what's in the sample description.ext; the communication menu entry previously used by the fire support action system has been removed. Otherwise, you will get a crash to desktop. Also for mission makers, update your JIP code to account for the new fire support actions (if you use those actions in the mission). You'll also need to update the PV's the server sends to include every framework public variable. These changes are reflected in the JIP demonstration. 1/11/16 Feedback Not for more than about 10 seconds, then they should get a new point to move to. I tested it briefly by standing next to a building and using: _group = [player, west, 1, 2] call Zen_SpawnInfantry; 0 = [_group, player, false, "aware", 2] call Zen_OrderInfantryPatrolBuilding; Do the units begin by moving around and then eventually stop, or do they never move around at all? Example As mentioned last release, the dialog system does not have built-in check box or radio button controls, but you can create them from the existing controls. Here's the example code for that.

Update and Release #39 Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the links to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog This release features another control type for the dialog system as well as updated and modernized documentation code. I have reviewed almost all of the documentation and corrected old information, old typos, and attempted to correct any logical or MP mistakes as well as modernize the code style (such as by using ZEN_FMW_MP_REAll, etc.). All the sample missions have been tested once more and are still in working order. The tutorials have not been reviewed; those will be updated next release. The new ProgressBar control type is likely one of the last additions to the dialog system. I've seem to run out of control types that can be dynamically added. Things like check boxes, radio buttons, etc. can be created using buttons and text boxes. For next release, I'll give example code that implements a multiple choice type dialog. 12/7/15

This is not a spawning script; the method of spawning the units has no impact on the effects of this script. It's intended to work in the editor and with SQF scripts that spawn units. Spawning units leads to things like AI skill, loadouts, etc. that are up to the mission maker and outside the scope of this script. There are many scripts and systems for spawning units out there; anything that returns the units it spawned can be used with this script.

You don't need _x = 0, and _x should be reserved for forEach loops. Next, I'm assuming the global variables PARAMS_GarrBuildings, currentAO, and PARAMS_AOSize as well as local variables _dt, _pos, and _enemiesArray are properly defined. Using pushBack on _enemiesArray is more efficient than + []. I see currentAO being used as a marker; Zen_OccupyHouse requires that the first argument is a position. Then, the second argument is a group, when it should be an array of units. The other arguments look good. All those changes give: for "_i" from 0 to PARAMS_GarrBuildings do { _randomPos = [[[getMarkerPos currentAO, PARAMS_AOSize],_dt],["water","out"]] call BIS_fnc_randomPos; _spawnGroup = [_randomPos, EAST, (configFile >> "CfgGroups" >> "East" >> "OPF_F" >> "Infantry" >> "OIA_InfSquad")] call BIS_fnc_spawnGroup; if (random 1 > 0) then {"O_Soldier_AA_F" createUnit [_randomPos, _spawnGroup];}; [_spawnGroup, _pos] call BIS_fnc_taskDefend; nul = [getMarkerPos currentAO, units _spawnGroup,(random(300)+25), true, true, true] execVM "scripts\Zen_OccupyHouse.sqf"; _enemiesArray pushBack _spawnGroup; };

Update and Release #38 Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the links to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog This release includes only one minor fix and an update for the dialog system. A new text entry control has been added; you can link it to buttons to get the entered text as a string. I'm also happy to report that the preprocessor up directory command has been fixed by BIS. You can now use "..\ " to point up a directory. That means it's no longer necessary to put the framework and standard preprocessor libraries in every sub-folder. I'm now returning to a once a month release schedule, as the dialog system is almost complete. I'm planning on overhauling the fire support actions to use dialogs as well as renovating a lot of code examples in the documentation. 11/2/15

For fastroping not working, that might be reference to engine-based fastroping. The fastrope code will just force each unit to exit, then just move their position in steps until they get to the ground. I doesn't always look that smooth, but it works. In the fastrope.sqf script, you have the vehicle to fastrope from in the action's arguments // replace air1 with _vehicle. 0 = [_vehicle, _x] spawn Zen_OrderFastRope; Zen_OrderInsertion with the fastrope argument is the easy way to force players/AI to fastrope. If you want to present an action, Zen_AddFastRope is fairly close to what you're doing; it's not quite as smooth because each player can fastrope independently, causing Zen_OrderFastRope to run multiple times. In general, you can always use 'air1 = this' in the editor init field to get a global variable rather than the name field. Thanks, I must've missed that when I added the variable distance change.

Update and Release #37 Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the links to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog Here we have a relatively minor release, including various fixes for Zen_FindCenterPosition and a new control type for the dialog system. Zen_FindCenterPosition now operates in 3 dimensions, and an infinite loop bug is fixed. The new 'Picture' control type will allow you to display any .paa texture file. The picture will be scaled to fit in the size of the control given, so beware of stretching and compression. 10/17/15 Feedback Thanks, one of the framework's main goals is to enable mission-makers to do things that would have been too difficult. So you want to know which town was selected? You could reverse the process and find the town nearest the marker, but that's not a very efficient solution. For what purpose do you want the name of the town? Is it to display the name, run specific code for each town, etc.? I think the easiest solution is to make the name of the location the marker's text, which won't be shown for area markers. I'm just wondering if there's another solution for your situation, in case it's not that easy.

Thank you, I've tried to be as thorough as possible in terms of providing critical mission features. It depends on exactly how much control you want over what spawns. For a quick implementation, I allow the infantry to be any west soldiers and select a single vehicle: // get the position somehow _pos = [<...>] call Zen_FindGroundPosition; _infantry = [_pos, west, "infantry", 4] call Zen_SpawnInfantry; _vehicle = [_pos, ["<classname>"]] call Zen_SpawnGroundVehicle; 0 = [_infantry, _vehicle] call Zen_MoveInVehicle; I could make this a function and pass in the position, vehicle classname, size of the infantry squad, etc; whatever arguments are required to meet the needs of the mission.There are many paths to doing this because you can have a lot of randomness, or you can completely control the exact classname, loadout, skill, etc. of every unit that spawns. There's also the spawning of addon units to account for in the documentation. Yes, that does look like a typo. I'll change that and test for the next release. Thanks for the bug report!

Those sections aren't supported mostly because players in MP have their profile voice/face setting enforced for any unit they control. Also, I figured players won't be looking to closely at the faces of the enemy (though you can hear their voices at close range). It's quick to make your own function to do this, e.g.: Then look at the wiki for the argument/effect locality: https://community.bistudio.com/wiki/setFace In this case, args are global but effect is local, so it must be run on all clients for them to see the effect: For this command, I'm guessing it must be synch'd in JIP as well, so let the JIP client as the server for the current face of a unit: and so forth for the other commands. I didn't test that, but it should be mostly correct. You'll also need to set up the JIP data to find which units to synch faces for.

There is no information about specific buildings in the script. If a building is detectable by nearestObjects command and has preset buildingPos spots near windows, the script should be able to do something with it. It's mostly up to the building's config as to whether or not it will work. Test it out (use a radius that includes the building instead of -1) and see what happens.

Update and Release #36 Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the links to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog The highlight of this release is, of course, the dialog system with two new controls added: sliders and drop lists. A drop list, or combo box, functions just like a list box, except it lacks tooltips and double click events. Sliders operate on integer detent positions, with the maximum given when it is created. There is no data associated with each slider position, it's up to you to do something with the position index. Sliders have position changed events ("SelectionFunction") when moving the bar; the returned bar position is always rounded to an integer when the player drags it. I have fixed the annoying "SelectionFunction" event firing when invoking a dialog. This was due to the function automatically selecting the first element in a list. Zen_RefreshDialog wasn't getting every changed control properly, as some changed data fields were not being detected due to hashing inaccuracies. 10/3/15 Roadmap I'm changing the release schedule to once every two weeks once again, as most of the possible control properties are in and working. I'll be adding more control types and any more properties that look useful in future releases. The support action system (notice I've dropped 'fire' from the name) is progressing towards offering custom supports. I'm trying to present it so that there is a good balance of flexibility and usability. However, presenting the options on a dialog requires a complete rewrite of the internal code due to MP locality. Spotlight As users of my framework know, there is an enormous number of functions at your disposal. The amount of documentation that has to be sifted through can be extremely daunting. Each release I spotlight a function and talk about its usefulness. If you have found an obscure function (not in tutorials, barely seen in demonstrations or sample missions) that you think is useful, PM me and I can spotlight it. The function chosen for this release is: The Dialog System. I've added quite a few control properties over the last few weeks, and now, with the addition of the slider and drop list control types, there isn't a good example of how to use everything. Thus, I give you the code for my 'debug dialog' that tries to test absolutely everything. You'll need your own Test.paa texture file in order to actually run this, but it's main goal is a code reference. Also ignore Zen_HashControlData; that's in there for debugging the selective control refresh.

Update and Release #35 Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the links to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog Although the changes look pitifully few, it's only because I put all the new properties on one line. Refreshing of only certain controls is a fairly large feature as well; it eliminates menu blinking for most controls and prevents lists from resetting their selection to the first element (and triggering a selection event on that element). The process of selecting which controls to refresh should have no performance impact. Also, some Notepad++ SQF language mistakes have been corrected. I didn't include a dialog for the fire support actions, as I'm going to be making other improvements to that system. It will become an all-round support system, allowing for not just fire support, but any sort of player-called assistance or actions from the AI. I plan for mission makers to be able to plug-in their own functions and have their custom support actions show on a dialog. It could be used in a very general way to present any event-driven action players. Next week for the dialogs, I'm planning on doing more control types; they'll likely be drop lists and sliders. They'll get appropriate events and as many visual properties as possible. 9/25/15

You'd only need to change the calls to Zen_SpawnInfantry to search for RHS units, then remove any loadout changes that are applied to those units (that will give them their default RHS equipment). If you want to give them modified RHS equipment, you'll have to set up custom loadouts. All of this is now in the realm of my framework's documentation; you can find an FAQ.txt answer about spawning addon units, and the function documentation for Zen_SpawnInfantry will explain what extra arguments do what. Here's an example of it: _group = [_pos, west, "Infantry", 4, "rhs_vehclass_infantry_ocp", "rhs_faction_usarmy_d", ["rhsusf_army_ocp_crewman", "rhsusf_army_ocp_combatcrewman", "rhsusf_army_ocp_driver", "rhsusf_army_ocp_fso", "rhsusf_army_ocp_helicrew", "rhsusf_army_ocp_helipilot", "rhsusf_army_ocp_jfo", "rhsusf_army_ocp_sniper"]] call Zen_SpawnInfantry; Then there's a demonstration for custom loadouts as well as a way of getting a unit's default loadout into the custom format. Here's a start for what needs to be changed: I would suggest making the soldier type and faction preprocessor constants, like '#define ENEMY_SIDE east' is; then use those macros in the arguments to Zen_SpawnInfantry. That will allow you to change what soldiers spawn for the entire mission once all the arguments are changed.

Here's what I've used in one of my other missions to show virtual arsenal: Box1 addAction ["<t color='#2D8CE0'>Virtual Arsenal</t>", {0 = ["Open",true] spawn BIS_fnc_arsenal;}, [], 1, false, true, "", "(_target distance _this) < 3"]; Just replace Box1 with any object; the hex color code can also be changed to anything. I don't know what the difference is between that and using BIS function to add the action.

That code is now: sleep 5; _exfilTask = [_rangers, "When all objectives are completed, the extraction point will appear on your map.", "Move to Extraction"] call Zen_InvokeTask; _infilHeli allowDamage true; sleep 45; ZEN_STD_OBJ_DeleteVehCrew(_infilHeli) starting on line 780. Which you should still be able to replace with: sleep 5; _exfilTask = [_rangers, "When all objectives are completed, the extraction point will appear on your map.", "Move to Extraction"] call Zen_InvokeTask; _playerGroups = [_rangers] call Zen_ConvertToGroupArray; { _playerGroups set [_forEachIndex, leader _x]; } forEach _playerGroups; _args = [_playerGroups, "Zen_SupplyDrop", "Ammo Drop", "[_pos, 'Ammo Drop'] call f_SupplyDrop"]; ZEN_FMW_MP_RENonDedicated("f_GiveSupport", _args, call) _infilHeli allowDamage true; sleep 45; ZEN_STD_OBJ_DeleteVehCrew(_infilHeli) I just modernized the code a little with ZEN_FMW_MP_RENonDedicated. '_supplyClass = ["AmmoboxInit",[this,true]] spawn BIS_fnc_arsenal; ' will work on the dropped ammo box exactly as it would for any placed/spawned ammobox. The name '_supplyClass' is misleading and can refer to either the ammo box object or the ATV classname (hence the 'Ammo Drop' check).