Zenophon

The delay is the result of Zen_SpawnInfantry using Zen_ConfigGetVehicleClasses to find a unit of each side (the delay only happens once because Zen_ConfigGetVehicleClasses saves its search results). You are right that this is unnecessary and the classnames can be used directly. In the interest of making as few changes as necessary, the spawning code can just be changed to: Which you can benchmark with: I get about 0.1 seconds now.

I don't see any errors when testing the missions on a dedicated server. I'm on stable branch with no mods. If you can post the errors or send me the log that would be appreciated. Make sure than none of the players is JIP (i.e. that they are all loaded and ready during the briefing). The way that select loadout does not work for you indicates that the dialog isn't being drawn correctly; however, I can see it in testing. As for difficulty, on Sweep each AT soldier should have three missiles. If you are using a mod like ACE that makes the launcher disposable, it might be impossible to use the other two missiles. This is one of the reasons I enable the debug console for admins. Some enemy AI will be carrying AT weapons that you can scavenge. The mission is intended to be playable with just one AT soldier without mods. The mission caps the number of Opfor to 8 per player and 4 vehicles (+ 1 that appears after 10 minutes) when there is a sniper team. There may be fewer than that based upon the size of the town. There is a typo in which it caps to 10 per player when there is no sniper; that should be less than if there are snipers. I will change it to 7 per player and 2+1 vehicles total with a sniper and 6 per player and 2 vehicles without. The AI is intentionally challenging when all slots are filled with players. However, because both the number of AI and their skill increases, having an AI group flank or surprise you becomes more likely and more dangerous. Because of varying player skill levels, it makes sense to allow the host to set the AI skill based on a few presets. I'll update all missions with that for next release; the number of enemies will still scale with player count (maybe at a slightly reduced rate for some missions).

Update and Release #45 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 An auspicious day; the framework now enters its second year since initial release. There have been 696 changes during those two years, including the changes in this release. The highlights here are waypoint features for the AI caching system as well as several small ease-of-use improvements for the template system. Zen_Cache now saves all waypoint data and Zen_UnCache restores it. I won't go into detail here, as you can now avail yourself of the new AI caching demonstration, which unremittingly shows every part of the AI caching process. For compatibility, all orders functions now assign real waypoints using addWaypoint rather than using the move command. Zen_CreateTemplate has received a small but very useful tweak; it saves the simulation state of objects. This is used to disable physics for many small objects that would otherwise appear strangely when Zen_SpawnTemplate was used (e.g. things falling through tables). Zen_RotateAsSet can now rotate objects individually after the set rotation; this is used to rotate spawned templates and maintain their exact appearance. Zen_SpawnGroup places units in a small circle around the point given, this should reduce instances of units being stacked on top of each other or being stuck inside objects when spawned with a template. By user request, Zen_SpawnAmbientVehicles can be given a list of classname to choose from when spawning vehicles. I already posted that for those who wanted to try it early, and it's now incorporated into this release. Finally, I noticed that addon buildings that can be placed in the editor (e.g. CUP buildings) are not detected by nearestBuilding. Thus, giving the object name directly Zen_FindBuildingPositions will force it to generate positions for that object (provided it is a building) instead of using nearestBuilding. 7/10/16

I can see how someone might want to spawn specific type of vehicles with the placement Zen_SpawnAmbientVehicles uses. I added the DLC a parameter primarily so that the DLC karts would not appear by default. In order to avoid having to give Zen_SpawnAmbientVehicles all the arguments to Zen_ConfigGetVehicleClasses, it's a quick change to allow for a list of classnames to be given rather the DLC (which will still be supported). Since it'll be a week or two for the next framework release, I'll just give the new code for that function and you can copy-paste it over the old one. Here's the new function: and the new accompanying documentation: As a simple test for the new code, you can stand in a town and run this from the debug console: 0 = [player, 200, 20, ["b_mrap_01_f"]] call Zen_SpawnAmbientVehicles; Of course, there's no reason that the list of classnames can't be generated by Zen_ConfigGetLocations before calling Zen_SpawnAmbientVehicles. For an overview of all its parameters, see the Random Battle Showcase.

Zen_Cache basically has three modes, which it determines from the pattern of arguments it receives. The first mode is the caching of new units that the system has not cached yet. For this, giving only the units is enough: This code caches _group1 and assigns an identifier to them. The second mode is the caching of units already assigned an identifier; in this mode you need only give the string identifier and Zen_Cache will find the units. In all cases, Zen_UnCache works like the identifier mode of Zen_Cache; Zen_UnCache cannot create new identifiers. The final mode is an additive mode, in which Zen_Cache adds new units to an existing set of units given by an identifier. This mode requires an existing identifier. That third example started with _group1 being uncached, but it is not necessary to uncache units assigned to an identifier before adding new units to cache under that identifier. Thus, this is valid: Finally, in the additive mode, whether or not the identifier is already cached, you can give a unit or group (be careful giving a group, as caching/uncaching will null old group variables) from the units already assigned to the identifier to join the new units to. Note that I had to save an object from _group2 (the leader in this case) in order to find that group again. Even when the units previously in _group2 are uncached into a separate group, the new group will not be referred to by _group2. That was a rather lengthy explanation (and about half of the test script for the cache system), but I wanted to give examples of all the different usages of Zen_Cache. The error it is giving you means that you used the 'additive' mode before using the 'new' mode, and it hasn't been able to create an identifier for those units yet.

Update and Release #44 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 With some delay, I have taken the time to bring an entirely new feature to the framework; the new additions bring the total number of public functions above 200. AI caching has been a potential addition for a long time, and I believe it is time for a framework solution for this. The highlights of the framework's caching system are very fast cache/uncache times due to disabling the units rather than deleting/respawning them as well as a robust, dynamic object-oriented structure for managing cached groups. Currently, the only information lost when caching a group is their waypoints (a result of the implementation used to workaround the 144 groups per side limit). This will be corrected in the next release, with full waypoint information being restored to each group as well as abstract waypoints and patrols allowing groups to moved while cached. For now, as a (fairly easy) workaround, just reapply any waypoints or Zen_Order functions after uncaching. The second major component of this release is an overhaul of Zen_CreateTemplate and Zen_SpawnTemplate. They now use a object-oriented data structure with string identifiers (that's now a framework signature with a current total of seven and likely another one eventually) and are supported by the expected Zen_DeleteTemplate, Zen_GetTemplateObjects, and Zen_RemoveTemplate. The template system is basically the opposite of the caching system, it stores data on non-human objects so they can be copy-pasted dynamically in a mission. The information saved by Zen_CreateTemplate has been expanded to differentiate between vehicles (everything with an inventory and crew), weapon holders (everything with just an inventory), simple objects (like chairs and tables). The inventory, animation states (these can be used to remove e.g. the doors of a truck), damage to specific parts, and fuel of vehicles is saved. Zen_GetUnitLoadout and Zen_GiveLoadoutCustom (and indirectly Zen_GiveLoadout for custom loadouts) now support vehicles. Zen_GiveLoadoutCargo no longer exists; simply renaming all usages of it to Zen_GiveLoadoutCustom should work. Note that because vehicles cannot wear a single uniform, etc., those will appear as items rather than in the 'uniform' etc. slot, which is for humans. 6/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. This release's example is a compact way to continually spawn vehicles and have them patrol in an area. The advantage to this code is that everything is condensed into three threads (two for patrols and one for spawning). You can extend this code to spawn multiple vehicles, different types (such as adding a list of MRAPs and a check for them), or infantry (and another patrol thread for them). Function 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. On some releases, 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 week is: Zen_CreateTemplate and the various other template functions. The template system is the framework's response to the Eden editor; it allows you to take complex, hand-crafted object placements and turn them into a dynamic template that you can spawn anywhere during the course of a mission. I will now briefly show an easy way to start using this system. First, you would create some arrangement of objects in the editor; since the placement of the template is random in the mission, you can just move the original to some far corner of the map where no one will notice it. Then place an area marker over the template, e.g. 'mkTemplate', and

Is the core (i.e. the parts it says to never change) part of the JIP code given in that demonstration running on the client machine? Code taken out of context from that will likely not work; the server's function, publicVariable's, waitUntil, etc. are all necessary. The decision for friendly AI or no friendly AI (line 68 of the demonstration) is required for applying the tasks correctly. The lines you're using are for a player taking over a slot previously controlled by an AI (which is why they must use the private function Zen_InvokeTaskClient directly). I'm guessing you've disabled friendly AI, so the task line is { 0 = [_x, player] call Zen_ReassignTask; } forEach ([_refUnit] call Zen_GetUnitTasks); However, you still need the code above to determine what _refUnit to copy tasks from (a group leader, a team commander, a dummy unit, etc.). This should copy all tasks (included completed/canceled ones) to the JIP client. An important note: if you are testing JIP alone and there is no unit to copy tasks from, this will not work (the code doesn't know which tasks you want to copy). In this case, you need to setup a dummy unit to hold the tasks that should be assigned to JIP players, then reference that unit directly in the arguments to Zen_GetUnitTasks.For you example, if you assign a task to all west units _task = [west, ...] call Zen_InvokeTask; // and you have a dummy unit on the west side name 'TaskDummyWest' // then the JIP task code should look like { 0 = [_x, player] call Zen_ReassignTask; } forEach ([TaskDummyWest] call Zen_GetUnitTasks); To answer accuracythruvolume's question: changing where or how the code executes doesn't affect the implementation. didJIP is (to my knowledge) a shorthand for traditional JIP check code. The same considerations about AI being present, requesting the necessary public variables, etc. will always be present.

Yes, an array of positions is list of each XYZ position as a nested array. The framework tries to remain neutral in terms of supporting hard-coded names, and in general you want to setup things in whatever way gives you easy access. For example, _group = [_building, west, "infantry", 3] call Zen_SpawnInfantry; _positions [_my_pos_array, 3, true] call Zen_ArrayGetRandomSequence; { _x setPosATL (_positions select _forEachIndex) } forEach units _group; If you spawn units with Zen_SpawnInfantry, you get the group directly. If you place a group in the editor, then it's just _group = group X; where X is what you've named a group member. Basically you want to save yourself from having to name dozens of things in the editor and then having to type out unit1, unit2, etc.setPosATL aught to be faster than just setPos, but setPosWorld is acting on the 3D model center and above sea level. Zen_FindBuildingPositions returns above ground level positions, as that makes more sense on land. You can always do ASLToATL or ATLToASL. count is used for conditional counting. You may find examples where the condition is used to execute code, but in general a forEach loop will work just as well (and be easier to read later). The wiki also has some examples of using exitWith inside count, and you'll likely be able to get a speed advantage for simple code; however, count is not an equivalent to forEach for more complex statements (forEach loops may go on for dozens or hundreds of lines).

I can experiment with spawning of saved data, as I'm almost done improving the Zen_CreateTemplate/Zen_SpawnTemplate functions into a more robust system for copy-pasting non-human objects dynamically. Disabling the units does have the advantage for selecting certain things to disable; if one wanted to e.g. target cached units with artillery, damage alone could be enabled quickly (without having to turn on AI FSM's, etc.) for that and the surviving units hidden again (without having to completely rescan the units and save the data again). For patrols, Zen_OrderInfantryPatrol is primarily designed for large, open areas in which the patrol area is designed with some larger features of the terrain in mind (e.g. patrol within a valley, avoid a swamp, etc.). It does not handle urban areas differently or use Zen_OrderInfantryPatrolBuilding. However, units in the 'safe' behavior will automatically follow any roads between their waypoints. Zen_OrderVehiclePatrol prefers to put waypoints on roads if it can. Zen_OrderInfantryPatrol ends up working fairly well for both large urban areas and small villages with surrounding countryside. Typically I assign units to buildings and street patrols separately in a mission, as the AI don't move in/out of a building very smoothly. For an example of how I populated an urban area, see the mission 'Sweep' in my ZMCM pack. For the building position, the selection of the building to use is determined by the nearest building to the point given to Zen_FindBuildingPositions. This uses what the engine considers to be the 'center' of a building, regardless of the details of its 3D model. You might have to adjust the random area in order to get a certain probability of selecting one building over the other. Once the building is selected, Zen_FindBuildingPositions is rather strict about which positions it will return (a quality over quantity approach). You can use the 'number of positions' argument to override the default number of attempts it makes and force it to searching longer. The default is based upon the 2D area of the building (not counting multiple floors) and can be too low for very small shacks or buildings with many floors. Something like 100-200 should render some usable positions.

AI caching is certainty something I've considered adding. Existing caching scripts that are generalized should work regardless of how units are spawned, but I can understand that they present features in a way that isn't always easy to fit into your existing mission structure. I want the framework to support larger-scale co-op missions just as well as small ones, and AI caching is certainly useful there. Since I don't have much to release in a new framework version at present, I'll hold off and see what I can do with AI caching in a week or two. A framework caching system would give scripters a different interface for caching than (probably all) existing caching scripts. I would just present the features of a caching system as functions and let mission makers use them however they like. I would all be tied together by a data structure that handled cached objects in an object-oriented way (like the task, fire support, etc. systems do now). I would also provide a basic example that shows how to automate caching and uncaching as well as using various features of the system. I'll also look at whether it's more efficient to disable the units (as you did in your scripts) or delete them entirely and store various information necessary to respawn them. That choice could effect caching/uncaching time depending on the total number of units that are cached, how many units are considered to be cached together as a group, how to get features such as abstract patrols to work. Regardless of the internals, the caching system will reduce the amount of visible information about the units to what is necessary to keep track of them.

Update Overview Greetings fellow Armaholics, this release ports 4 missions to Takistan (for a total of 7 missions on Takistan). Changelog 5/10/16 Feedback By default, the missions do not use the handleDamage EH, so there shouldn't be anything stopping ACE from working. Feel free to open the .pbo's and make an ACE version of the missions by changing the loadouts or adding ACE modules, etc..

It seems to be an issue with VA. Using the action added by this code (tested in SP) kicks the player out of the helicopter and gives some errors: I'm guessing that the whole line is If you use ["Open",false] spawn BIS_fnc_arsenal the GUI opens properly and keeps the player in the helicopter, but there is no gear to choose from (only the player's current gear is shown). I also had no luck with the 'AmmoboxInit' mode.

Update and Release #43 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 the definitive release for version 1.58 stable. It includes some fixes and requested additions. I've improved the reliability of positions returned by Zen_FindBuildingPositions, as well as let Zen_AreIndoors and Zen_AreNotIndoors use the same precision. There are still more tweaks to be done. I'm not sure what exactly to do for the task changes BIS has just released. They are really only cosmetic and don't affect the operation of the task system, but I would like to give users access to the new possibilities. It doesn't seem like BIS is finished with the changes, so I'll give them some time as well as figure out how to best present their new features as arguments to the framework's task system. 4/28/16

I didn't realize how old that example spawning code is; it's almost 9 months out of date. The faction and class have probably changed, and RHS is using the DLC property as well. The DLC parameter is mentioned only once or twice in the documentation, but it is necessary for finding classes that specify it. Here are two lines that spawn RHS units (I tested them this time): _group = [player, resistance, "infantry", 2, "Men", "rhs_faction_insurgents", [], "RHS_AFRF"] call Zen_SpawnInfantry; _group = [player, west, "infantry", 2, "rhs_vehclass_infantry_ocp", "rhs_faction_usarmy_d", [], "RHS_USAF"] call Zen_SpawnInfantry;

I've never actually tested having a player join but not pick a slot. I would define JIP as a player entering (i.e. having control over a unit) the mission (either taking over an AI or spawning as an unplayed slot) after the briefing. To avoid any JIP issues, every player must pick a slot and be ready during the briefing (box next to their name in the players tab is filled); the admin/host shouldn't get a message like 'Player X is not ready' when clicking start. I didn't put in any JIP code into the missions because they have so few player slots compared to larger scale co-op missions, and most of them are fairly short. Every mission requires slightly (or sometimes significantly) customized code to support JIP properly. Even with JIP provided for, there are issues like players spawning in the middle of combat or being separated from their teammates.

Update Overview Greetings fellow Armaholics, this release ports 5 missions to Chernarus (for a total of 8 missions on Chernarus). Changelog 4/12/16 Feedback The issues with loadouts and AI don't happen to me when testing this latest version on a dedicated server. Is the problem consistently reproducible if you restart the mission without restarting the server? Is any player JIP? (the missions don't support JIP). "Update of nonlocal object" appears in the server's log when everything works; it's just debug for BIS's recent netcode changes (I'm guessing for the remoteExec commands among other things). I don't know how to stop it from spamming the log.

Sorry for the belated reply... . You're right, it should be: Also, for next release, I'll make Zen_SpawnParachute have the parachute inherit some of the velocity of the object, so things like the ammo drop will look more realistic.

That's a good point, as I did the fastroping stuff before there was FFV. The condition on the action is: (_this in _target) && (_this != driver _target) && (speed _target < 10) && (((getPosATL _target) select 2) > 5) which is why I suggest there is some MP issue and the action hasn't been added. That condition should work for in a turret or in cargo in any helicopter. When calling Zen_OrderFastRope directly, units in FFV positions should be forced out just the same as if they were in cargo seats. This applies to Zen_OrderInsertion with fastroping as well.The only issue is when the player is leading an AI group and uses the Zen_AddFastRope action; in that case, only AI group members that are 'assignedCargo' will be fastroped with the player. There is no 'assignedTurret' command, so to fix this I'll likely use 'turretUnit' on all the vehicle's turret paths and filter for AI that belong to that player.

Zen_ConfigGetVehicleClasses is a search tool for finding everything in a category. If you have just a few ammo boxes you want to use, you can just name them: Zen_FindBuildingPositions is using whatever building is nearest the point given, so you can just give it the building itself as the first argument. To build the blacklist, you would have to examine each building in-game and add its classname (CUP makes a lot of them placeable in the editor). Once you have that, you can search for a building: For a whitelist, just switch the while loop condition to !((typeOf _building) in _whitelist). The type of vehicle shouldn't affect the function; the action appears in my testing for SP and MP. Try it in SP, if there's an action there, it's likely a MP issue. In MP, do either of you get the action? If either of you were JIP that would cause an issue if unhandled.

1. The first argument of Zen_ConfigGetVehicleClasses is the 'vehicleClass' property of a class. So Box_East_Wps_F has vehicleClass = "Ammo", Boat_Civil_01_base_F has vehicleClass = "Ship", etc... This and more about Zen_ConfigGetVehicleClasses is discussed in the Random Battle demonstration. 2. For a quick debug, you can try this: _positions = [player] call Zen_FindBuildingPositions; _spawnPos = [_positions] call Zen_ArrayGetRandom; _box = [[0,0,0], "Box_East_Support_F"] call Zen_SpawnVehicle; _box setPosATL _spawnPos; player setPosATL _spawnPos; If you try that on various buildings you'll see it's not 100% successful. It will give a few positions in/outside the walls or where the box is damaged. There's a limit to what can be achieved by assuming that walls have no thickness, that there are no empty, non-enterable spaces in the 3D model, that a window and a missing wall are the same thing, etc. If you are dealing with completely non-enterable buildings, Zen_FindBuildingPositions won't handle that. It should be able to handle partially enterable buildings, such as the hospital in Kavala on Altis. I'll tweak Zen_FindBuildingPositions with a few more ray casts, but it will never be perfect.3. If all five are destroyed one at a time, then you never have to check on all of them at once. I would break it into parts like this:

Update Overview Greetings fellow Armaholics, this release brings 4 new ports to a few smaller maps as well as some minor improvements. The increased damage feature is now a mission parameter and is disabled by default; if you wish to play the missions in SP with increased damage enabled, just host a LAN server and change the parameter. Also note that additional map versions require only CUP terrains, not the CUP weapons, vehicles, or units packages. Changelog 3/24/16

Update and Release #42 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 numerous changes and fixes. The foremost is the framework's response to the new Eden 3D editor in the form of Zen_CreateTemplate and Zen_SpawnTemplate. Zen_CreateTemplate will scan for editor-placed objects within a radius or an area marker and compile them into a format that Zen_SpawnTemplate can use. This will help combine the ease new ease of use for placing objects in the 3D editor with the framework's dynamic spawning and randomization. The remainder of the changelog is not nearly as exciting. A few technical errors about variables, stack traces, and debug were fixed. Zen_GiveLoadoutCargo now places backpacks in vehicles properly. Another change of the Eden editor is that Opfor and Indfor sides can place FIA units, so Zen_SpawnInfantry now filters them out. You can get them back the usual means. The framework has also adopted the new nearestTerrainObjects command; it seems to be an improvement for everything except roads. 3/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. This release's example is for endlessly delivering reinforcements to a patrol area. Each time the number of units on the east side falls below the number set (currently 30), a helicopter will ferry more troops (currently 60) from the first given point to the area marker given as the second argument. You can change many things about this code, from the side and number of units, to the time between reinforcements and the minimum number of units. Like most of these, this is just a starting template you can adapt to your teams. If you are using this code in a larger mission, you may be concerned about spawning Zen_OrderInfantryPatrol for every squad. If you want an example of how to combine dynamically spawned squads into a single patrol thread, just post or PM me. Feedback In writing all that documentation I forgot to provide a simple example of how to call them. The syntax is: ZEN_FMW_Code_InsertionPatrol(_dudesToPatrol, _vehClassname, _startPoint, _patrolMarker) with '()' surrounding the arguments instead of '[]'; the ';' is omitted at the end because the macro returns void (it won't hurt to include it though). Another example the documentation doesn't provide is what it means by 'variable array'; it means that an array literal cannot be declared within the arguments.

You're right that the EH will conflict greatly with ACE and it's damaging/medical system. The easiest solution is to make applying it a mission parameter and disable it by default, then suggest that those wishing to play the missions in SP with it enabled just host a LAN server in order to change the option. Otherwise, it's not clear when to add/remove the EH using the debug console during the mission (some spawn reinforcements during the mission to which the EH must be added/removed). I'll add that for the next release, along with a few ports to small maps (Utes, etc.) and minor tweaks. I'm aiming to release that in about a week. I probably won't do any new missions until a lot of the ports are done. I'm going to port the missions map-by-map going through CUP and beyond at about 1-3 weeks per map (if anyone prefers one map over the others, let me know and I'll prioritize them according to popular demand). Some of the missions will have a very different feel (e.g. urban setting instead of rural), while other will play about the same. Some won't be ported to many maps due to some map-specific need (e.g. Cleaner).

Zen_ConvertToObjectArray (which Zen_AreNotInArea uses) should filter out the null objects/groups. Failing that, you could always run Zen_ArrayRemoveDead before. For something like your specific case, this code: should be: player, true/false (depending on where you place mkTest), group player. Post how the groups are being deleted and the error that prints out. It's interesting that the gunner doesn't receive ammo but the driver does. I would have said that the vehicle is local to the driver and therefore any argument-local, effect-global command (e.g. setVehicleAmmo) run on the driver's machine will affect the gunner. I'd have to look at the specific implementation; it may be that the vehicle was local to the gunner before the driver, so a script running local to the driver didn't work until the gunner got out. Here's the code from one of my mini missions (Pursuit), with an option #2 added for including the gunner (and any other crew members) in the rearming. Try the code with options #1 or #2 and see if there's a difference. Both options dynamically find the owner of the vehicle.

Update Overview Greetings fellow Armaholics, this much belated release updates every existing mission to my current framework and includes various tweaks and fixes to almost every mission. I also plan to port more missions using the very well made CUP Terrains. Changelog 3/12/16