Zenophon

Before calling Zen_Cache, all threads that manage those units must be stopped using terminate. Those threads must be stored along with the set identifiers. For brevity, I will implement that in the previous example I gave. The four additional parts are highlighted by comments. Also note that you can use Zen_GetCachedUnits to get the units listed in their groups more efficiently.

I cut the init.sqf to the minimum, and this is what I tested At 25 areas, the fps starts around 60 for me, and declines to around 20-30 during the spawning process, with some stutters to below 10; I did not turn down the graphics from what I normally play at. The spawning process took 165 seconds and spawned 938 AI. While the cache loop was running, I got a fairly constant 35 fps walking around and about 25 while driving fast. If I turn down the graphics to the absolute minumum, I get 45 fps when stationary and 30 when driving fast. All of this was done on Altis, with a i5-6600k at 3.5Ghz, a GTX 970, and 8GB RAM. I didn't run it on a dedicated server, but I imagine a server with a good CPU will be able to manage 35-45 fps with all of the units cached. I urge you to test this init.sqf exactly as I posted it and in an isolated environment (you just need a player unit and an area marker "mkAll" that covers Altis). If the game is unplayable and locked to 1 fps for you, look at your CPU/GPU usage and temperatures. Also, in the full mission, if you have many players in different places, more AI will be uncached at once; the scripts cannot control the performance impact of uncached AI. Estimate or count via scripts how many AI are really uncached at once, if it's beyond a hundred or two, expect poor performance if they are all being managed by the server. Check out the framework's headless client demonstration; even running the HC as a separate .exe on the same machine as the server will help.

The '0 = ' is just a habit I have now that I developed to indicate that the return value was void or unwanted; I'm just used to seeing it when I skim code looking for function calls (mainly spawned threads or calls that have some side effect). I didn't really highlight this before, but this is supposed to run on only one thread. You have spawned 22 threads by dividing the sets of groups into their own thread. The thread should combine every set of units into a single loop. That's the the only way that you can handle 1000 AI with performance issues. You also have to prevent the 1000 AI from all being uncached at the same time.

What you have running on the server is correct, i.e. this sleep 1; loadoutPOW = [[["uniform","LOP_U_AFR_Civ_02"],["items",[["ACE_quikclot",2],["ACE_morphine",1],["ACE_epinephrine",1],["ACE_EarPlugs",1]]]]] call Zen_CreateLoadout; In short, the assignment 'loadoutPOW = ...' is completely separate from what Zen_CreateLoadout is doing with the data internally. loadoutPOW isn't defined on the clients, but the data is there.How Zen_CreateLoadout works is different from how remote execution in general works. Zen_CreateLoadout is an abstract data structure that takes information and stores it with a name; that name is just a string that Zen_CreateLoadout returns. The identifier/namestring/key is returned immediately (thus there is no need for the waitUntil), and it really is just a string; it has no meaning outside the loadout system. Within the loadout system, Zen_CreateLoadout propagates the key and its data to all clients, so the key can be used on the client machines to find the data. When you call Zen_GiveLoadoutCustom on the server, the function passes the literal value of the key to the client, and the client looks up the correct data for that key. The server stores the key string in a variable, but the client receives the key without ever storing it in a variable. If you want to manually do what Zen_GiveLoadoutCustom is doing for you when you run it on the server, then you you would use something like // from the server publicVariable "loadoutPOW"; // and on the client waitUntil {!isNil "loadoutPOW"}; 0 = [player, loadoutPOW] call Zen_GiveLoadoutCustom; Now the waitUntil is useful because the PV is a time-dependent event; in contrast to the assignment operation '=', which is local and instant (or rather uninterrupted). Many framework functions like Zen_GiveLoadoutCustom will do this PV process for you using a RE method built into the framework. There are demonstrations about the framework's RE process that explain how it's doing this.

In this case the core code is a switch based upon the players being near the groups, which is iterated over every set of groups and accounts for them being wiped out. I use a list of markers in the code, but you could also compute the position of the sets directly from the units using Zen_FindCenterPosition or Zen_FindAveragePosition (which is statistically equivalent if they are constrained to patrol within the marker). This time I can test the code and it is working; note that the responsiveness is reduced by each set added due to the 'sleep 1' in the forEach loop. If your mission isn't script-heavy, you could reduce that to 0.5 to 0.25 to get a faster cache/uncache reaction time.

You are correct; Zen_SpawnInfantry should be using rounded numbers. Looking at Zen_FindInRange, it isn't rounding the numbers with an equal distribution (edge numbers are 50% less likely). Zen_FindInRange should use if (_isWholeNumber) then { _return = floor (_rangeMin + (random (_rangeMax - _rangeMin + 1))); } else { _return = _rangeMin + (random (_rangeMax - _rangeMin)); }; instead of _return = _rangeMin + (random (_rangeMax - _rangeMin)); if (_isWholeNumber) then { _return = round _return; }; Also, for next release I will modify Zen_SpawnInfantry (and Zen_SpawnInfantryGarrison) to allow the min/max argument to use the new Gaussian distribution feature of the random command. That will allow a wider range of numbers while making the values more predictable.

Update Overview Greetings fellow Armaholics, after yet another long time, I have ported this mission to 9 maps, fixed old issues, added new features, and updated it to my latest framework. The long-standing issue of respawning with the correct equipment is solved; players and AI will be given their same loadout back on respawn, exactly as when they died. There are new DLC loadouts that will be given to players that have the specific DLCs and to AI. I have placed all of the missions into a single .7z archive for download; the old download link will no longer be available. The new link is: https://drive.google.com/open?id=0B-QFvxyAVKTUYkFjZ0p2Vm16ZWs The Chernarus, Everon, Malden, Nogova, Sahrani, and Takistan versions require CUP terrains: http://www.armaholic.com/page.php?id=30045 The Lingor and Isla Duala versions require their respective files as well as CUP terrains. Lingor: http://www.armaholic.com/page.php?id=29469 Isla Duala: http://www.armaholic.com/page.php?id=27699 Changelog 10/1/16 Fixed: Players receive their previous loadout on respawn Fixed: Respawn time after consecutive deaths now adds properly Fixed: Start marker did not always appear on the map Added: New DLC loadouts Added: Mission parameter for increased damage EH Added: Mission parameter for fatigue Added: Chernarus version Added: Everon version Added: Isla Duala version Added: Lingor version Added: Malden version Added: Nogova version Added: Sahrani version Added: Stratis version Added: Takistan version Improved: Various improvements and fixes included in my latest framework Tweaked: Slightly increased the time between consecutive insurgent spawns

I'm going to release an update for Evade and Survive in the next few days that will port it to most of the maps that Black Ops is now on.

Update Overview Greetings fellow Armaholics, after yet another long time, I have ported this mission to 5 new maps and updated it to my latest framework. Note that the Chernarus, Takistan, Malden, Nogova, and Sahrani version require CUP terrains (http://www.armaholic.com/page.php?id=30045). Lingor and Isla Duala require their respective files (http://www.armaholic.com/page.php?id=29469) and (http://www.armaholic.com/page.php?id=27699) as well as CUP terrains. Also, I have packaged all missions into a single .7z file for download; the old download links to the individual missions will not longer be available. The new link to the full download is: https://drive.google.com/open?id=0B-QFvxyAVKTUTUplWjJqdThpWjA Changelog 9/28/16 Fixed: JIP fire support (Chernarus and Takistan version) Added: Isla Duala version Added: Lingor version Added: Malden version Added: Nogova version Added: Sahrani version Improved: Various improvements and fixes included in my latest framework

On line 87 of Zen_OrderVehicleDrop, it should be 'spawn Zen_OrderVehicleMove' instead of 'call Zen_OrderVehicleMove'; call does not return a script handle. That's what I get for thinking I can add only one line and have it work without testing it.

Update and Release #46 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 framework is back, and this release includes a number of changes appropriate for such a long absence. The only new function, Zen_SpawnFlare, was developed in cooperation with MooseMan (https://forums.bistudio.com/user/906086-pellelil/). This function makes flares much more accessible and should make night and stealth missions (especially without NVGs) more exciting. A variety of fixes and requests that have been discussed in previous posts are now fully tested and released. This includes Zen_OrderVehicleDrop complying with its documentation, various orders functions failing, Zen_Cache stalling on the initial cache, Zen_InvokeTask etc. getting an icon type parameter, etc. The dialog system, now supports the new control angle function from BIS; note that this only works for pictures (that's the way BI made the command). There are two new macros for Zen_GiveLoadoutBlufor etc. giving quick access to a little more variety and control. Zen_UnCache can now add units to the cache identifier without uncaching them (and uncache the already assigned units at the same time). The AI caching demonstration has been updated with this and other improvements. There are various optimizations using new BIS commands as well as basic code optimization. As a general note, when a BIS command and a framework function do nearly the same thing, the BIS command is closer to the engine and thus faster. However, I attempt to make the framework function offer some feature the command cannot (e.g. argument checking, better error messages). Zen_ArrayFilterCondition, for example, can now filter nested arrays recursively for the condition. I'm not going to remove a function like Zen_IsPointInPoly because there's inArea now, so I advise that you be aware of where you need speed (e.g. as I use the commands for internal optimization in the framework) or where you prefer extra features (like when creating a new, complex system or mission where error checking is important). I've clarified the documentation for the six vector transform macros. This is part of a larger effort to standardize the use of vectors across framework functions in terms of how function interpret coordinates and how they accept those arguments. I'm going to be reviewing more function in the future for this; the goal is allow the mission maker to work/think in whatever coordinate system is convenient, and just transform those vectors with the macros whenever necessary. The only function for which current arguments may not work is Zen_InvokeTask; the task icon type parameter is now where the name string parameter was. Another thing to watch out for is Zen_ConvertToObjectArray and Zen_ConvertToGroupArray will now print an error when a nested element isn't a convertible type. That error doesn't mean the function didn't work; it's just a warning that it had to filter something. The topmost readme file has been modified to include the full legal text of the framework (to prevent any confusion between the full legal terms and the simplified version that used to be there). The legal terms have been slightly modified to explicitly state that parts of the framework that were created by someone other than me are covered by the legal terms in the name of their respective author. 9/20/16

Are you describing a GUI that allows the player to modify the loadout of the AI during the mission? A full loadout editing premade GUI like virtual arsenal is not included in the framework (though you could create one using the Dialog system, but that would be a lot of work). Zen_AddLoadoutDialog is an action for players that allows them to pick from a list of preset loadouts; it's possible to order the AI to access that action. Looking at the code, it should be able to detect any activating unit (potentially an AI) and apply that loadout to them; the dialog would be displayed to the machine (i.e. player) that the AI was local to. The same idea could be applied to the BIS virtual arsenal function, but I can't say if or how it would work. I think a reasonable solution (in terms of the amount of work) that doesn't require the player to order the AI around would be to create a dialog that displayed a list of AI and a list of loadouts. The player could activate this dialog, click on an AI name, then click on a loadout name, then click the 'OK' button, and the AI would be given that loadout. Creating a dialog that like isn't that hard with the framework's dialog system, and you could use the framework's loadout system or other loadout scripts to equip the AI. This solution limits the loadout selection to presets (which could potentially be randomized), but it makes the process quick and easy for the player (just a few clicks and their AI squad is equipped). Here's the basic code of such a dialog: Of course, you need a proper list of units and loadouts, some limits on where and how often the player can change the AI's loadout, maybe you prefer a different layout/fonts/colors etc. for the dialog, etc.. You're free to use any alternative to the init.sqf (i.e. these https://community.bistudio.com/wiki/Event_Scripts),while keeping in mind their relative load order (https://community.bistudio.com/wiki/Initialization_Order). All the init files (Init.sqf, InitServer, etc.) for mission start events will begin during the briefing (time = 0). The 'sleep 1' command exists because during the briefing, the simulation hasn't really started, and the server cannot remote execute commands on clients properly. The framework's server-oriented design requires that functions the mission maker calls from the server be able to affect the clients as necessary to do their job (a good example of this is Zen_InvokeTask vs. Zen_InvokeTaskBriefing; in that case I offer special function that must run all clients). However, e.g. Zen_CreateLoadout must run after that sleep command for clients to have the loadout defined on their machine. The briefing is actually a great time for the server to perform any intense calculations that don't require immediate remote exec. Things such as complex Zen_FindGroundPosition arguments, Zen_ConfigGetVehicleClasses, etc. will run much faster because the engine's framerate isn't bogged down by simulating the 3D world, but you still have access to all the data about it (e.g. how many trees are in an area, etc.).

I don't know the details or order of execution of your mission, but, as a simple debug, try these lines at the beginning of the caching function: If those print out empty arrays, there are no units to cache when the function runs. As another correction to the script I posted, I forgot to include the reinforcement groups under the cache identifiers. On around line 90, the code to cache the units should be Next framework release, I'll make it easier to integrate units into an uncached identifier at any time (thus you'd be able to add the reinforcements to the identifier at around line 40 without having to cache any units).

There are actually defenders in those markers? Might seem like a silly question, but since there's no error from Zen_ArrayFilterCondition or Zen_GetAllInArea, they're doing what they're supposed to. If both functions (and you can try the a 'select {_x in Area}' method for good measure) agree that they aren't any units, you should check that those area markers are covering the right spots.

On about line 117, it should be: _defenders = [_blufor, compile format ["!(_this inArea '%1')", _x]] call Zen_ArrayFilterCondition; I forgot that the formatted marker name must be in quotes. Or you could remove the '_blufor = ...' line entirely and use _defenders = [_x, [], west] call Zen_GetAllInArea; Either of those should fix the defender selection error, and thus the Zen_Cache error, and in turn the Zen_IsCached error. Also, the reinforcement function can be defined externally; I just put it in the code for clarity.

Cached units should not be moving on their own; using enableSimulationGlobal freezes them very completely. I don't know the specifics of CBA_fnc_taskDefend, but I would advise against using any patrol function if you are not manually terminating its thread when you cache the units this is more than likely how the units seem to be moving. Also, enableAI/disableAI are unnecessary, as the caching system doesn't alter those settings. The joining of groups and the distinction between _tocache and _defgroup seem strange to me; I'm not sure what the purpose is. Another thing to note about the caching system is that calling Zen_Cache with the units as arguments will create a new cached identifier. Thus, although the variable in the script is reassigned, the caching system retains the data for the identifier internally; because the identifiers are just strings, the caching system cannot determine that no more variables hold the value and garbage collect the internal data. It is more efficient to use '[_id] call Zen_Cache' to recache the units. The function you posted is operating on one marker, which is fine for just a few markers. As an example for you or anyone else reading this, I'll post how I would code the logic you describe for multiple markers. As always there may be a few typos, but I labeled each part of the logic so that the intent is clear.

I think your issue arises in part from your script looking from the perspective of the player; you are looping through checks for the players and then looking for units to cache. My code is looping through units to cache and checking if each one is near the players. The second part of your issue is that the waitUntil loops prevent you from generalizing the script to deal with multiple sets of cached units and multiple areas that the players could be in. You could try keeping the perspective of the players, but instead of waiting for them to fulfill a condition, loop through the conditions (i.e. areas) that players can meet without waitUntil's and cache/uncache according to what the code finds. In that case, the script can cache/uncache in a timed cycle without getting stuck. In the part of my code where I say to get a position for the players (lines 23 and 24), you can replace the logic that compares two positions with code that checks for all players being in an area, as you already use in your waitUntil loops. Now you are left with determining how accurate _cachedPos really is depending upon how many units you've cached under each identifier. The more sets of units you cache seperately, the more accuracy you will have with caching/uncaching them, but you lose performance because the script must cycle through many identifiers. In the case of respawn, you can supply the list of players as a global array, which you can update as players die/respawn using EH's.

For everyone having issues with getting the AI to move, remember that the Zen_Orders functions just boil down to using 'addWaypoint' and/or 'move' in order to actually get the AI to do things. I am aware that using addWaypoint is noticeably less reliable that 'move'; however, I changed the orders functions so that they are compatible with the caching system ('move' doesn't create a valid cacheable waypoint). The quickest fix to the AI not moving is to reinforce the Zen_Order command with your own move command; e.g. As long as the move command you give manually is the same as the one the function gives, there will be no conflict. For next release, I will put that duplicate 'move' into all the functions as a failsafe (such a thing seems impossible when dealing with this AI). I'll give an example assuming that you have at least one of units which cache/uncache independently (a set being an arbitrary list of groups); this should maintain generality and let you decide what granularity you need. Keep in mind I can't test this (still don't have my computer set up and running ArmA, ETA about 1 week), so beware a few typos, but the general pattern is clear. I didn't include patrolling of any kind, as that is covered in the caching demonstration. Thanks, I try to keep up with the new scripting commands, but I am likely to miss a few. The inArea command will improve the performance of Zen_FindGroundPosition. If new BIS commands are significantly better (either in offering new functionality or speed), I generally replace the body of a function with them while keeping its parameters (e.g. nearestTerrainObjects for Zen_GetAmbientClutterCount). Zen_AddLoadoutDialog will propagate in MP, so clients will see the loadouts on the menu. The loadouts will work for any machine since Zen_CreateLoadout also propagates data, as long as it is run after the 'sleep' command in the init (same for any MP synch'ing). I am aware of the dialog list issue and it's one of the two known issues that I cannot fix (nor do I see a fix being possible any time in the future). It it a result of the dialog being created dynamically and without a config class; there is no scripting command to control the expected length of a list. I agree that it's annoying, but it doesn't hinder functionality.

Yes, I can make that an extra parameter; when enabled, Zen_OrderVehicleDrop will use Zen_OrderVehicleMove instead of Zen_OrderHelicopterLand. On the first line, 'params' should be 'private' (assuming you don't want to read all of those variables as arguments). Only _ao appears to be an argument, so private ["_hspawnPos", "_insertionPos", "_heli", "_ispawnPos", "_reinf_grp"]; params ["_ao"]; I don't see anything wrong with the usage of Zen_OrderInsertion; if the helicopter never starts its engines, the AI is likely confused about the move order (i.e. they think it's completed or impossible). You could try spawning the helicopter in the air and observing its behavior. If it thinks it's done with the move order, it should land; if it doesn't get the order, it will just hover there. _heli = [_hspawnPos, ["B_Heli_Transport_03_unarmed_F", "B_Heli_Transport_01_F", "B_Heli_Transport_01_camo_F"], 40, 90] call Zen_SpawnHelicopter; You could also try using Zen_OrderHelicopterLand or Zen_OrderVehicleMove to see if the helicopter responds to anything. That will determine if the issue is with Zen_OrderInsertion specifically.There is no dedicated 'order defend' function in the framework that will make AI take cover, man static weapons, watch all directions, etc; framework function avoid micro-managing the AI whenever possible to maximize compatibility with AI mods that do that. However, if you just want them to walk around and engage enemies that attack them, giving Zen_OrderInfantryPatrol a very small patrol area works.

Looking at Zen_OrderVehicleDrop, the second position isn't really optional; the function just uses the second position without checking if it exists (hence the null array passed to Zen_OrderHelicopterLand). Thus, the positions to drop and move away to must be in an array; I will change the argument check to enforce that. The documentation that is correct for the currently released version of the function is: For example, this is from a test script: 0 = [_testHeli2, [player, "mkTestInsertion"], _box, "normal", 80, true] spawn Zen_OrderVehicleDrop; As for making the osprey fly away and be deleted, you must give a position for it to head toward and manually delete it at some point. On a slightly related note, I am planning to investigate using vehicle-in-vehicle transport with Zen_OrderVehicleDrop to see if it works better than just teleporting the object.

I can have Zen_InvokeTask etc. support setSimpleTaskType; it will just be an extra optional parameter like the destination. A note to all: I'm moving somewhat far away in 2 days (I was not certain when I would travel until now) and will not have access to a computer capable of running ArmA for a few weeks. I will continue to answer questions to the best of my ability and in as timely a fashion as possible; however, I won't be able to test things or release framework or mission updates during this time. Thank you for your understanding; things will be back to normal in no more than a month.

A magnitude and 2 angles (i.e. r, theta, phi) would be spherical polar coordinates, for which the macro is ZEN_STD_Math_VectPolarCart. I understand your confusion about the arguments, as there are different conventions not only for what theta/phi stand for and what order they go in but also for how the polar angle is measured. ZEN_STD_Math_VectPolarCart is formatted for an input like: _velPolar = [<magnitude>, <XY plane trig angle>, <angle from the Z axis>]; _velCart = ZEN_STD_Math_VectPolarCart(_velPolar); where 90 degrees from the Z axis lies in the XY plane and the XY angle is measured from the X axis.In your case, you are using the opposite polar angle convention (i.e. 90 degrees is parallel to the Z axis), thus swapping cosine and sin on the elevation. All six of the vector conversion macros should have their documentation improved about what arguments they expect and outputs they give.

The spawn command returns a thread that you can stop using terminate. For example: _thread = [...] spawn Zen_OrderInfantryPatrol; //... terminate _thread; The Multi Thread Management demonstration mission has further information and a full example of doing this. Note that in the case of terminating Zen_OrderInfantryPatrol, the groups will continue to carry out their existing move orders until new ones are issued.

Update Overview Greetings fellow Armaholics, this release covers all ports to Porto and Zargabad, a rewrite of Silence (the objectives are much more random, but the mission should feel more focused), addition of AI skill as a parameter to all missions, and a few tweaks and fixes to other missions. The default AI skill is now the lowest setting (as it was always in SP), but in MP you must now change that parameter to get a different skill. Missions still scale in difficulty in terms of the number of enemies and other specific things (such as the number of vehicles in Convoy). To equip friendly AI in Silence, order them to get in the weapons vehicle and use command menu 6 to order them to use the equip action. Up next is ports to Sahrani, which will include most of the missions (and hopefully will not be so delayed as this release). Finally, now that CUP Terrains includes islands from ArmA : Cold War Assault (as it's now called), I will be porting missions to those terrains later. Changelog 7/24/16

You are sure that the thread is running with the name of the correct vehicle? For a simple test, try placing a vehicle in the editor (named e.g. truck) and using 0 = [truck, 5] spawn f_VehicleRespawn; Also, here's an improved version of the function that places the vehicle back at its exact starting position (in case it was initially placed close to other vehicles).