Zenophon

According to the changelog, the release on 11/20/16 included this fix to Zen_SpawnInfantryGarrison; I've checked the current release and it definitely has it (there have occasionally been code and changelog discrepancies). Thank you for the detailed bug report so I could verify that.

Update Overview Greetings fellow Armaholics, this release fixes an issue with playable slots not spawning the unit in some missions (resulting in the player controlling a seagull). Changelog 8/11/17 Fixed: Non group leader slots could not be used

I can reproduce this issue and I'll be releasing a fix shortly. The solution, for anyone having the same issue, is to delete and recreate every playable unit in the editor (except the group leaders). I have no idea why this fix works.

You'll have to write a function that creates the jet, makes it fly over, etc. and then given the name of your custom function as the second argument to Zen_AddSupportActionCustom. The documentation for Zen_AddSupportActionCustom lists the arguments that will be passed to your function. Note that you could even call a regular fire support (from Zen_CreateFireSupport) manually in your custom function to do the actual explosion (and the jet would just be for visual effect).

Update and Release #51 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 falls on the third anniversary of the framework's first release; thusfar, I have counted 806 total changes to the framework. I am truly grateful for all of the comments and suggestions that allowed for so many fixes, improvements, and additions. The vast majority of what I had planned to do is finished; I will continue to maintain the framework with bugfixes and small improvements. Added in this release is Zen_ArrayRemoveType, which is basically the remove version of Zen_ArrayGetType. This might be a useful shortcut instead of writing a code condition for Zen_ArrayFilterCondition; it also searches recursively and should be slightly faster. Now that BIS have allowed ctrlCreate to use control classes defined in the mission's .ext file, the dialog system can take advantage of that to be on truly equal footing with tradition dialog creation. Zen_InvokeDialog will look for the type of defined control and apply properties appropriately (e.g. types 1, 11, 16, and 41 are considered buttons). The template subsystem is now tied into the action system, with Zen_CreateTemplate and Zen_SpawnTemplate being able to copy-paste existing actions onto the new objects. This greatly reduces the hassle of manually applying your actions to the correct spawned object. 7/10/17 New Function: Zen_ArrayRemoveType Fixed: Zen_ExtendVector did not use relative height if its second argument was a vector Fixed: Zen_RefreshDialog did not remove controls properly in some cases Improved: Zen_CreateControl now allows mission defined control classes as the first argument Improved: Zen_CreateTemplate and Zen_SpawnTemplate now copy actions added using the framework's action system Documentation: Added for Zen_ArrayRemoveType Documentation: Updated Notepad++ SQF language and autocompletion file with ArmA 1.72 stable commands

The framework's task system appears to fail when all objects assigned to a task are deleted (like when the players leave) because it automatically deletes tasks for which there are no units. This is done because there is no direct command to remove the data entry itself, only units that have the task. This is most likely the issue if you are testing the JIP code alone by joining, leaving, then joining your persistent server with team AI disabled. To account for this, you need to manually create a proxy unit that will hold the task for players. Any invisible/disabled proxy AI unit (preferably local to the server) somewhere on the map will work; you would include this unit with the players when you use Zen_InvokeTask (or you could use Zen_ReassignTask to this unit when some players still exist). You can then use Zen_ReassignTask normally for this task on JIP players.

Update Overview Greetings fellow Armaholics, this release ports appropriate missions to Tanoa, for a total of 45 variants on 9 maps. Changelog 6/17/17 1. Added: Fatigue parameter for all missions Abduction 1. Added: Tanoa version Ambush 1. Added: Tanoa version Checkpoint 1. Added: Tanoa version Convoy 1. Fixed: Removed debug markers (Takistan version) Sweep 1. Added: Tanoa version

Update and Release #50 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 introduces a major addition to the framework, a system for managing actions. It currently uses ArmA's traditional action menu, since it is simple and doesn't seem to going anywhere. There are several benefits of this system; you no longer have to write your own functions for adding and removing actions, all MP synch'ing is done for you, and adding actions to JIP client is much easier. All framework functions and documentation have been updated to take advantage of this new system. This now allows you to interact with actions added by framework functions; you can add and remove them manually during the mission. All framework actions now have a global variable stated in their the function's documentation. The JIP demonstration and all sample missions that implement JIP have been updated. The updating of actions and the usage of many framework action functions has changed. Also of note is another new function, Zen_ArrayTranspose. This function makes a two dimensional transpose of an array, which means it leaves nested, nested arrays and lower intact. It is mainly intended for transforming data structures to separate a list of properties from their assigned identifiers. ZEN_FMW_Code_GetRemoteVarArray and ZEN_FMW_Code_GetRemoteVarArrayT have been added to make remote access to such data structures easier. In order to provide the greatest possible performance increase to the dialog system, Zen_RefreshDialog now allows the user to optimize the refresh process for their specific dialog/refresh. You can now specify which controls to force refresh (without checking for changes, i.e. you know there were changes), which to ignore (i.e. you know there were no changes), and which to check and update normally (the remainder from those two arguments). This allows you create separate, efficient refreshes for different parts of your dialog, massively speeds up refreshing of large text blocks (e.g. cycling pages of text), and improves the users' experience. 5/24/17

There's nothing wrong with your code or the arguments to Zen_OrderVehiclePatrol. After testing a lot of different possibilities, the fix for this is a simple 'doMove' command added to the existing 'move' and 'addWaypoint' commands in Zen_OrderVehiclePatrol. Testing a large sample (30 vehicles) without 'doMove' gives about a 60% compliance rate; adding doMove makes it 100%. I cannot explain why 'doMove' works when 'move' does not; repeating the 'move' command does not always work. Various other factors (vehicle type, side, the method for spawning the crew, checking if the vehicle has complete a move order) have no effect on this as far as I can tell. This fix will be duplicated to various other Orders functions for the next framework release (which should be in about a week, as I'm finishing up some new things). If you want to modify Zen_OrderVehiclePatrol yourself, just add (driver _veh) doMove _mpos; as lines 60 and 93 after the 'move' line.

You are correct, publicVariable does say you don't need to manually publicVariable anything to JIP clients, if the latest value has been PV'd previously (which is the case with your code). I don't remember if I every tried using this when I was creating my JIP code. I probably just did it manually to be certain it would work. This is somewhat a case of 'trust but verify'. publicVariableClient must be run on the server; it's essentially repeating the automatic synch'ing that PV should already have done. Note that variables that are not always PV'd from the server at every update (i.e. a 'server-side' variable that is not guaranteed to be up to date on a client) do require this (e.g. the catch-all Zen_JIP_Args_Server). You're using the variables as global rather than server-based, but this is an alternate style. I cannot reproduce this; can you post the exact arguments you gave the function? It might be an issue with how the function is interpreting the patrol area (e.g. giving the vehicle a destination it cannot reach). Also, there are issues with AI simply not obeying a move order, but I've never been able find a cause for it. You could also try adding more vehicles, if none of them move, it's not just random AI confusion. The type, side, etc. of the vehicle should have no effect on the result (you can even mix vehicles of different sides).

Detecting that a client in JIP should be done correctly by the framework; it will give you the _Zen_Is_JIP boolean in the init. It will also wait for the player to initialize before compiling the framework. Task1 is undefined because running publicVariable only sends the variable to current clients. The JIP client doesn't have this variable defined, or any of the information it needs when it starts. Zen_SyncJIPServer is given as a template in the JIP demonstration to show how to the JIP client 'asks' the server for the information it needs, but you must define it in your mission and customize it. For example, in your mission it could include (owner _this) publicVariableClient "Task1"; Once the waitUntil is over, the JIP client can use that variable. Also, using Zen_ReassignTask assumes that the JIP player's object did not previously exist. That means that other clients have no information about it either; thus, every client must be updated with the tasks of the new object. If you've disabled friendly AI, then using Zen_ReassignTask is correct. If the player object did exist (as an AI), the JIP demonstration shows how to use the private function Zen_InvokeTaskClient to update tasks. There is a mistake in the JIP demonstration with Zen_InvokeTaskClient; the line should end with '(_x select 6), (_x select 8)] call Zen_InvokeTaskClient;', since tasks now support different icons. The error doesn't stop tasks from working though.

Update and Release #49 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 focuses mostly on the dialog system. The first important addition is support for control eventhandlers provided by the engine using the Event property; the full list is in the documentation. The arguments of the EH will be passed, along with the standard arguments from data and linked controls; there is no limit to the number of events that can be stacked. For the arguments and exact behavior of each EH see the BI wiki (https://community.bistudio.com/wiki/User_Interface_Event_Handlers). Note that only EH's for controls are handled through this property; display EH's for the whole dialog must be added manually to (findDisplay 76). The code behind Zen_RefreshDialog has been improved and updated to fix some issues and provide a smoother user experience. It no longer resets which item in a list the user had selected; note that this is tracked by index only, if you rearrange elements of the list the selected value will change. Zen_RefreshDialog also supports a variable update time, for smooth transitions between values. I will be working on further optimizations in the future to improve the response time of Zen_RefreshDialog. The map control can now be manipulated using the MapPosition and MapZoom properties; this allows you to scroll the map in response to user actions. An important note: because the user can manually move/zoom the map, the MapPosition/MapZoom value of a map control is not necessarily the true; in order to restore the position/zoom of the map, that value must have changed in the control's data before you use Zen_RefreshDialog. That means that you need to slightly change the position, e.g. with (vectorAdd [random 5, 0, 0]); otherwise, Zen_RefreshDialog will not know that the control requires updating. A new StructuredText control type is supported; this control uses parseText on the regular Text property to interpret HTML/XML-like codes in the text. Refer to the BI wiki (https://community.bistudio.com/wiki/Structured_Text) for the formatting of such strings. Zen_InvokeDialog now has a parameter to catch the Esc key and prevent it from closing the dialog. Warning: this will lock the user into the dialog and prevent them from closing it or exiting the mission; if the dialog does not provide another way to close it, the user will have to Alt-F4 out of the game. 4/18/17

The "Vehicle is of unknown vehicleClass type" is just a warning that did not recognize the type of vehicle and spawned the default rifleman as the crew (b_soldier_f, etc.) rather than a tank crewman, helicopter pilot, etc.. There should still be a crew in the vehicle. For example, these lines _rhs_veh = [player, "rhsgref_ins_g_btr70"] call Zen_SpawnVehicle; 0 = [_rhs_veh] call Zen_SpawnVehicleCrew; produce the error but result in a working vehicle. You can use Zen_GiveLoadout and similar to change the crew's appearance, or as cdn_biggdogg said use Zen_SpawnGroup/Zen_SpawnInfantry and Zen_MoveInVehicle. The Generic error in expression at 'sleep' looks like the result of running in an unscheduled environment. If you're using the function from an EH, you'll need to use 'spawn' to get a scheduled environment. This is discussed the FAQ. Since the usage of addon vehicles/units is much more prevalent than when I wrote Zen_SpawnVehicleCrew, there's no reason the function can't keep up with the times. For the next release (for which it's about time), Zen_SpawnVehicleCrew will use the classname defined in the vehicle's config under 'crew' ("rhsgref_ins_g_crew" in the case of this BTR-70). That will allow it to automatically spawn addon units that fit their vehicle; if a vehicle lacks this property or the user gives a side that disagrees (so you can still force e.g. Blufor in a FIA truck), the old method will be used. I'll put the names of the class properties into the function's description. Unfortunately, it's easy to miss the FAQ file; it's an odd combination of general questions and a few important details (class properties and the scheduled environment mainly).

You mean a one-way insertion that waits for the players to get in the helicopter? As an example, I cut this out of the Abduction mission from ZMCM: _heli = ["mkBase", "b_heli_transport_01_f", 0, random 360] call Zen_SpawnHelicopter; waitUntil { sleep 2; ([_players] call Zen_AreInVehicle) }; _h_insert = [_heli, [_lzPos, "mkBase"], _players, "full"] spawn Zen_OrderInsertion; How you determine _lzPos is based upon the mission; it could be random, given by player input, etc. A self-contained function for that is not provided by the framework, but the logical parts required to do it are. You can use Zen_GetAllInArea to find the units inside the marker, as well as Zen_AreInArea and Zen_AreNotInArea to check for specific units being inside. The exact logic of the script depends upon what you consider to be 'conquered' as well as if the Opfor can recapture the zone, but for as a simple example of one-time capture // let's call it "mkTown" waitUntil { sleep 2; (count (["mkTown", [], east] call Zen_GetAllInArea) == 0) }; "mkTown" setMarkerColor "colorBlufor"; If you are using the task system, the above code is basically the same logic as that of Zen_TriggerAreaClear. Using the config viewer in the editor, 5, 6, and 8 would be 'vehicleClass', 'faction', and 'expansion' data fields. Note that units are sorted and categorized in the editor based upon these, so e.g. all the Apex guerrilla units share the same 3 values (and thus are all in the same unit submenu). You can also make use the blacklist argument to exclude any units from that set you don't want. The code for those Apex units would be: _group = [_pos, resistance, "infantry", [3,4], "Men", "IND_C_F", ["I_C_Soldier_base_unarmed_F", "I_C_Pilot_F"], "Expansion"] call Zen_SpawnInfantry; where we've left out the unarmed unit and the pilot (and confusingly the expansion value is 'Expansion', but that's the value for all Apex classes).

Saving in SP works for most things; all running scripts are restored and the mission will proceed as intended. There have been issues reported in the past about UI scripts stopping, addons not loading properly, etc. (which I've never seen myself), so at the time I released my framework I made a blanket statement against saving to prevent such issues in SP. I was also mostly thinking about missions written for co-op being played in SP, where saving would not be part of the mission's design (and thus not necessary in SP). If a save/load cycle works in your mission, then of course you can enable it. There's nothing built into the framework against saving.

Update Overview Greetings fellow Armaholics, this latest release ports this mission to Tanoa and offers 3 new enemy factions to choose from. You can use the additional mission parameter to choose between the AAF (the default and original faction), CSAT, FIA, or Apex guerrillas. Note that if you choose the Apex faction, you'll need that DLC to scavenge enemy weapons. I've also added random DLC loadout (for both marksmen and Apex); you'll need to have the DLC in order to receive those loadouts (you'll also see the AI using them). There is now a mission parameter for fatigue, for those who want to disable that. Changelog 2/3/17 Added: Tanoa version Added: Mission parameter for enemy faction Added: Mission parameter for fatigue Added: New DLC loadouts Improved: Various improvements and fixes included in my latest framework

Co-8 Black Ops Overview An open-ended co-op mission featuring random objectives surrounded by enemy patrols. Uses heavy randomization of enemy patrols and dynamic and reactive AI for maximum replayability. Numerous mission parameters are provided for extensive customization of difficulty, weather, and other options. The mission can be played in SP or MP, local or dedicated and with or without AI teammates. The mission is fully JIP compatible and optimized for smooth performance on clients. There is no saving or respawn to promote realism; however, unused player slots can still be joined to continue playing. Features Total randomization Accessibility and customization AI improvements Teamwork and realism Tested and optimized Misc features Most of this is done using my Co-op Mission Framework (see my signature) (shameless advertisement, I know). Download All map versions https://drive.google.com/open?id=0B-QFvxyAVKTUTUplWjJqdThpWjA Installation Copy the .pbo file to the Mission or MPMission folder in your ArmA 3 install directory. This is by default at (Windows 7) C:\Program Files (x86)\Steam\steamapps\common\Arma 3. Changelog Known Issues None at this time. Feedback Any feedback about the mission is welcome, particularly about new features or content that would make things more interesting. Obviously, if you find any bugs or issues, I would like to know. Either this thread, PM, or email is fine. Contact the author: ZenophonArmAFramework@gmail.com Legal This mission is released under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) http://creativecommons.org/licenses/by-nc/4.0/

The issue occurs in the absence of Zen_OrderAircraftPatrol, just with the simple spawning code I tested. Zen_OrderAircraftPatrol is using 'move' and 'addWaypoint'; the aircraft always goes to [0,0,0] after a move order is complete. Since Zen_OrderAircraftPatrol gives a new waypoint after that, it means that Zen_IsReady returned true for the aircraft. I don't think anything is ordering the AI to move [0,0,0]; it seems like an intrinsic bug in their AI. Instead of circling their last waypoint (or their spawn point), they forget it and go to [0,0,0].

Co-6 Evade and Escape Overview A medium-length co-op mission focusing on small-scale infantry tactics, with heavy randomization for maximum replayability. Dynamic and reactive AI patrols will relentlessly hunt down and surround players. Numerous mission parameters are provided for extensive customization of difficulty, weather, and other options. The mission can be played in SP or MP, local or dedicated and with or without AI teammates. It also features an unorthodox respawn system, which promotes teamwork like a revive system, and still punishes players significantly for dying. Mission Features Total randomization Completely randomized starting and objective locations, you could be fighting anywhere on Altis Completely randomized enemy patrols; their equipment, patrol routes, and starting positions are entirely random Endless enemy patrols that will relentless hunt you down to the realistic extent of their knowledge Nearly endless replayability and fun for fans of asymmetric co-op infantry combat Random and dynamic weather and fog during the mission Random starting date and time, with day/night options Accessibility and customization No mods or addons required, all features are done purely through scripting Full JIP compatibility, for both enabled/disabled friendly AI, for players joining at any time Play the mission in either MP (local or dedicated) or SP with no differences or issues Numerous mission customization options in MP, including AI skill/strength, time/weather, and mission duration Special settings for SP, fine tuning the difficulty and length for one human AI improvements AI can detect player gunfire at long range, even at night, and react realistically, without being psychic Realistically use diversions that the AI reacts to, then exploit the holes in AI patrol patterns Fix for ridiculous AI accuracy on dedicated servers, their skill will be the same as in SP or local MP Teamwork and realism No saving in SP or MP, to promote teamwork and realism, and punish players for their mistakes Teamwork-oriented and simple respawn system You respawn where you died However, if your teammates are not close by, you cannot respawn Dying increases your respawn time Tested and optimized Carefully optimized for minimal performance impact, a loss of 6 fps with 80 AI and all scripts running Removal of distant AI and dead bodies to improve performance and keep the action centered around the players Server-oriented scripting so that clients have a perfectly smooth experience All functionality and features, including JIP, fully tested on a dedicated server with multiple players with and without AI Gear and loadout improvements Optional increased weapon lethality, 1-2 shot kills are now the norm Easy repacking of magazines with an action, which takes a realistic amount of time Easily share magazines with teammates for their primary weapons, perfect for assistant MG soldiers Realistic and stylized loadouts for players, with heavy aesthetic randomization Simple and quick loadout selection system for resupplying, no time wasted fiddling with a virtual ammobox Most of this is done using my Co-op Mission Framework (see my signature) (shameless advertisement, I know). Download Google Drive: https://drive.google.com/open?id=0B-QFvxyAVKTUYkFjZ0p2Vm16ZWs Installation Copy the .pbo files to the Mission or MPMission folder in your ArmA 3 install directory. This is by default at (Windows 7) C:\Program Files (x86)\Steam\steamapps\common\Arma 3. Changelog Known Issues None. Feedback Any feedback about the mission is welcome, particularly about the difficulty and pacing. Obviously, if you find any bugs or issues, I would like to know. Either this thread, PM, or email is fine. Contact the author: ZenophonArmAFramework@gmail.com Legal This mission is released under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) http://creativecommons.org/licenses/by-nc/4.0/

You can edit the missions if you want; just add new playable units to the existing group in the editor. Those new slots will be detected automatically by the code (and they can JIP). It's all generalized, so you could add as many slots as you wanted. I'm assuming they're all human players, so it doesn't matter that they're all in the same group; if you want multiple groups that requires some coding changes. You might find that the mission is too easy with 12 players; you can change the values of all the difficulty parameters in ParseParams.sqf. For example, in case 2 of AI strength, put '_maxIndfor = 160;'. The mission will accommodate any values you choose.

Update Overview Greetings fellow Armaholics, this latest release ports this mission to Tanoa and offers 3 new enemy factions to choose from. You can use the additional mission parameter to choose between the AAF (the default and original faction), CSAT, FIA, or Apex guerrillas. Note that if you choose the Apex faction, you'll need that DLC to scavenge enemy weapons. Changelog Added: Tanoa version Added: Mission parameter for enemy faction Improved: Various improvements and fixes included in my latest framework

Zen_OrderAircraftPatrol does have a bug; for some reason ArmA didn't print an error for an undefined variable. Line 45 should have '_center' replaced with '_movecenter'; I've checked other patrol scripts and they don't have this bug. if (typeName _movecenter == "STRING") then { \ However, this is not the cause of the [0,0,0] bug; it was only preventing Zen_OrderAircraftPatrol from negating that bug. After a quick test, that bug is not caused by the framework; it is a result of spawning an aircraft using standard SQF script commands. I tested this code in an empty mission with only the player (I didn't even save the mission): plane = createVehicle ["c_plane_civil_01_f", (getPosATL player) vectorAdd [0,0, 100], [], 0, "FLY"]; createVehicleCrew plane; The aircraft always flies towards [0,0,0]. I have no idea what is causing this; however, it does not affect aircraft placed in the editor. My guess is that BIS have introduced a bug with either createVehicle or something in the AI's flying code; it is possible that the editor-placed object is running some internal code when it spawns that fixes this bug. I don't know what SQF commands to use to replicate this fix, if any can. Aircraft spawned with createVehicle will follow move commands and waypoints, but when their final waypoint is complete, they will always immediately move to [0,0,0]. One solution is to issue them new waypoints forever (through Zen_OrderAircraftPatrol or a similar script).

Update and Release #48 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 a new function, Zen_SubdivideMarker, which acts exactly as you would expect. It breaks up large rectangles (it pretends ellipses are rectangles) into smaller rectangles. You can use this to spread out spawning and patrols more evenly, quickly get more granularity in zone capture style gamemodes, etc.. We have reached a total of 90 preprocessor macros with the addition of ZEN_FMW_Code_GetRemoteVar. This is handy for dealing with cases where every client may have a different value of the same global variable. Also, in the case where the server is managing data attached to each client, retrieving the client's data on-demand typically saves bandwidth compared to always publicVariable'ing the data from the client when it changes. The dialog system has received several improvements. Zen_InvokeDialog can now move the origin of the dialog anywhere on (or off) the screen; that argument works with safeZoneX etc. for determining screen edges. There is a new type of a control, the map itself. Other than size and position, there's not much customization to do, but it can be a useful alternative to have the real map open behind the dialog. Zen_InvokeDialog now allows you to enable user input while a dialog is open. This a bit of a hack and isn't really intended; you enable it at your own risk. 1/26/17 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 for an example, your own example to present, or if find any bugs, please let me know. One issue that arises in creating co-op missions with a large mission area and/or a high number of players is having AI patrol in separate areas so that a reasonable portion of the map is populated. While this is of course possible, it results in having dozens or more threads managing each separate area's patrols. The solution I've arrived at is Zen_OrderMultiInfantryPatrol; it will not included as a framework function (due to how it accepts arguments). Rather it is an external script (that still requires the framework) that generalizes Zen_OrderInfantryPatrol so that all patrols can be handled by a single thread. This single thread can scale its execution to maintain good performance regardless of how many patrols it is given. The code is basically a copy-paste from Zen_OrderInfantryPatrol, but below it I will show the unique way it accepts arguments. The function itself has no arguments; it should be spawned as a thread on the server. You can compile it as a separate file (hence the #include's at the top) or make it an in-line function in the init. It relies upon a global variable, Zen_Multi_Infantry_Patrol_Array to receive its arguments. For simplicity, Zen_Multi_Infantry_Patrol_Array doesn't support defining the patrol area with a marker. I'll probably add that in the future; if anyone really wants it now, just ask and I'll show you what to add.

Update and Release #47 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 endless road towards perfection continues, if a bit slowly recently. This release is a mix of suggestions, bug fixes, and other minor improvements I've found. Most notably, Zen_FindTerrainSlope has been removed, and Zen_FindTerrainGradient modified to handle both its original duties as well as Zen_FindTerrainSlope's. The conversion should be // the old Zen_FindTerrainSlope is now the same as (90 - (([_pos] call Zen_FindTerrainGradient) select 2)) This also relates to the standardization of coordinate system among framework functions (such as measuring that second angle from the Z axis). Zen_ExtendPosition has been renamed Zen_ExtendVector; I am aware that this is a common function and renaming it is annoying, but no other change to is arguments is necessary. Zen_ExtendVector has the same parameters, with the addition of an optional parameter sequence using a standardized vector. Also, Zen_FindAveragePosition now averages the Z coordinate, so it can now be used with other vector functions by converting to Cartesian coordinates.Zen_FindInRange (and indirectly Zen_SpawnInfantry and all other functions that use it) has had its distribution corrected when using rounded numbers. Specifically, Zen_SpawnInfantry can spawn the maximum number of units given; Zen_SpawnInfantry also supports a Gaussian distribution of random units. Zen_OrderInfantryPatrol should prevent units from chasing a spotted enemy even though they can no longer see them (or had already killed them). This keeps the AI in the patrol area better and reduces aggressive behavior in which the AI kept chasing players after the player had evaded them. Zen_SetAISkill has a new present for 'player' skill. This sets all skills except accuracy and spot time to 1; accuracy has been tuned such that the AI has comparable accuracy to an experienced ArmA player (obviously player skill varies widely, so this is just an estimate). The AI fires more slowly than a player at long range, but they can reliably hit a standing target at 400-500 meters. The spotting time skill of the AI is much more subjective, as I don't know the details of internal AI code that allows them to spot enemies. Its value is meant to be an estminate of how much situational awareness the average player has, particularly when they are engaged in a firefight. As for documentation, I have added a new demonstration for the Dialog System. This demonstration includes five dialogs with explanations of the specific properties as well as how the dialog system work conceptually. This should provide good examples to support the (somewhat terse) list of controls and properties within the dialog system documentation file itself. Also, a relatively short section has been added to the AI caching demonstration. 11/20/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 for an example, your own example to present, or if find any bugs, please let me know. There are several issues about friendly AI in ArmA that have always bothered me, and while the AI can be useful in some situations, they end being a hindrance or just becoming cannon fodder in others. I wanted to find a way to being the friendly AI on a more equal footing with players and give players the sense that the AI can be an effective tool. Setting their skill to a high value helps, but having an aimbot AI do all the work for you isn't fun. The new 'player' Zen_SetAISkill preset is designed to find a balance between spray-and-pray and aimbot AI. However, teamwork isn't just about who can kill the enemy. The code below intends to correct the issue of AI communication with players. Typically, AI say something like 'Enemy spotted, 300 meters, south.'; which is generally vague and useless. Compare that to a message like "He's in the second story window of the yellow building bearing 137"; this is extremely specific and allows teammates to immediately engage the threat. My solution allows the mission to simulate the AI calling out enemies like human can by marking the enemies the AI spots on the map. This varies in effectiveness based upon whether the player is marked on the map, if they have a GPS, how much map/situational awareness they have. The information is taken directly from the AI knowledge, and the marker fades away when the AI cannot see the enemy. To use this code, just copy-paste it into the init.sqf and let the thread run. The main things of interest that you might want to tweak are the 'sleep 5; \' in the marker thread, and the sideChat message about the spotting. The sleep command controls how quickly a marker fades, so having it fade quickly means the players will have to pay closer attention to the map. The sideChat is a very accurate spotting report in the form of 'X distance at Y degrees'; by default it only appears when a new enemy is spotted.

The AI's skills, loadout, etc. will remain the same since the cache system uses enableSimulationGlobal rather than deleting and respawning them.