Zenophon's ArmA 3 Co-op Mission Making Framework

[Zriel 12]

Nope, this does not work with alive. Patrols are not stored (which may seem obvius) and Alive names groups differently. I would really like to talk more about that caching system you proposed to build. What do you think?

[Zenophon 110]

Nope, this does not work with alive. Patrols are not stored (which may seem obvius) and Alive names groups differently. I would really like to talk more about that caching system you proposed to build. What do you think?

A caching system written in a similar style to parts of the framework (e.g. the task system) would probably be most compatible with it. I would use a data structure in an OO style with each abstract group represented by a string identifier. The data would basically include:

• The classnames of the units in the group (let this tell you the size of the group)
  
• The loadouts of each unit (this is optional, default loadouts will be fine at first)
  
• The position of the group
  
• The velocity of the group, if it is abstract (not spawned), (maybe their destination)
  

I would then design cache and invoke functions to transition from spawned to abstract and vice versa. It is a good idea to get the basic system to work manually (i.e. calling the functions in a hard-coded test mission) before you create an automatic caching manager.

The automatic manager would run on its own thread in a turn-based fashion operating on the current data regardless of what it is. Thus the proxy functions for caching, invoking, deleting, etc. work from any thread (i.e. the manager is subject to external interference).

You can then introduce detector logic and data so that the manager can use the caching and invoking functions in a simple, logical way. I would leave it up the mission maker who can trigger the caching whether they are players or AI.

The manager is also responsible for updating the group's position if they are not spawned. This basically involves some calls to Zen_FindGroundPosition for random patrols. When the group is spawned, the manager would translate those abstract movements into actual AI orders.

That's how I would approach designing and coding this system. If you want to take the lead and code the system, I'm willing to help you with anything you need. Otherwise, I'll code it myself because it is a worthwhile addition that will make the framework an excellent stand-alone resource to create 40+ player co-op missions.

[Zriel 12]

A caching system written in a similar style to parts of the framework (e.g. the task system) would probably be most compatible with it. I would use a data structure in an OO style with each abstract group represented by a string identifier. The data would basically include:

• The classnames of the units in the group (let this tell you the size of the group)
  
• The loadouts of each unit (this is optional, default loadouts will be fine at first)
  
• The position of the group
  
• The velocity of the group, if it is abstract (not spawned), (maybe their destination)
  

I would then design cache and invoke functions to transition from spawned to abstract and vice versa. It is a good idea to get the basic system to work manually (i.e. calling the functions in a hard-coded test mission) before you create an automatic caching manager.

The automatic manager would run on its own thread in a turn-based fashion operating on the current data regardless of what it is. Thus the proxy functions for caching, invoking, deleting, etc. work from any thread (i.e. the manager is subject to external interference).

You can then introduce detector logic and data so that the manager can use the caching and invoking functions in a simple, logical way. I would leave it up the mission maker who can trigger the caching whether they are players or AI.

The manager is also responsible for updating the group's position if they are not spawned. This basically involves some calls to Zen_FindGroundPosition for random patrols. When the group is spawned, the manager would translate those abstract movements into actual AI orders.

That's how I would approach designing and coding this system. If you want to take the lead and code the system, I'm willing to help you with anything you need. Otherwise, I'll code it myself because it is a worthwhile addition that will make the framework an excellent stand-alone resource to create 40+ player co-op missions.

XDDD I'm a SysAdmin, so my speciality is integrating code to systems and debuingg, but i'm horrible when coding from scratch.

Also, I'm impressed on how you are managing things right now, and I do not have any concern on waiting until it's oficially released.

[Zenophon 110]

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 link 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 should be on Armaholic when Foxhound sees this or I PM him. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc.

Changelog

This release fixes some old issues and provides compatibility and improvements for 1.34 stable. The first new function is Zen_OrderSlingLoad; it gives you a simple way to have the AI sling-load vehicles without any player involvement.

There are some minor fixes to arguments for Zen_OrderInfantryPatrol, Zen_SpawnAircraft, and Zen_SpawnHelicopter. Two macros have been renamed, to follow a more logical nomenclature, and there is a new macro, ZEN_STD_Code_SwapVars. Zen_SpawnItemsOnTable now treats the table as a rectangle instead of a circle.

The helicopter engine on/off issue with Zen_OrderExtraction and Zen_OrderInsertion has finally been fixed by keeping the invisible helipad that Zen_OrderHelicopterLand generates. Something about the AI makes it take off when that landing spot isn't there.

The two new helicopters have correct fast-roping rope locations in Zen_OrderFastRope, and the right doors open for both fast-roping and landing with Zen_OrderHelicopterLand. With the addition of fire-from-vehicle positions, the new 'allTurrets' command is used in several functions instead of Zen_GetTurretPaths (which is likely to be deprecated next release and removed entirely in a month).

Finally, and I have saved the best for last, the very old issue with Zen_FindGroundPosition and limited angles in uneven markers (there were more points near the center and short sides) has at last been fixed. The function that does this, Zen_QuantizeAngles, is so named because the angles take discrete steps, or 'quanta' (as in quantum theory), rather than being continuous. The steps are not always equal, but rather are generated such that the areas of the arcs they sweep out inside the shape are equal. This produces an even distribution of areas instead of an even distribution of angles and thus a truly random selection of 2D points.

The function that can actually use those quantum angles has been overhauled and made a public function, called Zen_FindPositionPoly. This week's function spotlight is about these two functions, as they warrant some examples and some explanation for those who are curious.

11/12/14

1. New Function: Zen_FindPositionPoly
   
2. New Function: Zen_OrderSlingLoad
   
3. New Function: Zen_QuantizeAngles
   
4. Fixed: Zen_FindGroundPosition point distribution is now perfectly even for all marker shapes
   
5. Fixed: Zen_OrderInfantryPatrol used the wrong type to check parameter 7
   
6. Fixed: Zen_SpawnAircraft and Zen_SpawnHelicopter reversed parameters 2 and 3
   
7. Added: Standard macro ZEN_STD_Code_SwapVars
   
8. Improved: Standard macro ZEN_STD_Misc_SleepFrames renamed to ZEN_STD_Code_SleepFrames
   
9. Improved: Standard macro ZEN_STD_Misc_WaitScript renamed to ZEN_STD_Code_WaitScript
   
10. Improved: Zen_SpawnItemsOnTable randomly places the object using a rectangular shape algorithm
    
11. Improved: Zen_OrderFastRope has correct rope positions for the two new helicopters
    
12. Improved: Zen_OrderFastRope and Zen_OrderHelicopterLand open the doors on more helicopters
    
13. Improved: Zen_OrderExtraction and Zen_OrderInsertion force the helicopter to keep its engines running
    
14. Improved: Zen_OrderHelicopterLand no longer deletes the invisible helper helipad used to guide the AI
    
15. Improved: Zen_SpawnVehicleCrew no longer spawns crew for fire-from-vehicle positions
    
16. Documentation: Added for Zen_FindPositionPoly, Zen_OrderSlingLoad, Zen_QuantizeAngles, ZEN_STD_Code_SwapVars
    
17. Documentation: Updated for ZEN_STD_Code_SleepFrames and ZEN_STD_Code_WaitScript
    
18. Documentation: Updated Notepad++ SQF language and autocompletion file with ArmA 1.34 stable commands
    

Roadmap

The most significant addition now planned is an AI caching system designed to be perfectly compatible with the framework and designed similarly to other framework systems. It will provide a very open (i.e. documented) API that you can generalize to do almost anything by coding with small, functional parts (which also describes the entire framework). I might have a basic working build of this for next release.

Zen_GiveLoadoutCustom will offer an 'additive' option, allowing the loadout data to give items without removing anything. It might also extend to replacing equipment in certain slots. Zen_GiveLoadout with be updated with that 'additive' parameter as well as a parameter for remote execution. This sounds minor, but it allows an arbitrary organization of loadouts. If you simply want to give all units a GPS (which everyone would have in 2035), that becomes a loadout with all of the features the loadout system provides. You can make very specific loadouts for certain styles of uniforms, equipment, etc. that you then combine into a final loadout.

I also plan to improve Zen_OrderFastRope and Zen_OrderHelicopterLand to open the correct doors on every helicopter, as well as dynamically read the config files of addon helicopters and open their doors as well.

There will also be a Zen_IsWaterArea to determine how much of an area is water. This would be useful for finding beaches, ponds, lakes, rivers, etc. It might also help artillery scripts decide not to fire 50% of their rounds into the ocean.

Finally, although I very much want to use the new physics ropes to drastically improve the aesthetics and physics of Zen_OrderFastRope, I'm going to be honest and say it looks rather bleak. After a while experimenting with the new ropes, I don't see a simple engine-based way of attaching an object to any point on a rope and having the physics engine take over. I really hope BIS is planning to add fast-roping integrally as they did sling-loading. Otherwise, it's an unfortunate missed opportunity.

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. Each week 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_FindPositionPoly, and a bit of Zen_QuantizeAngles. As explained briefly in the changelog section, Zen_QuantizeAngles is a fundamental change in how a limited angle range is used. First, I will quickly show why the old method does not work.

Assume you have a marker that is very uneven (e.g. it goes 100 meters East and West and only 10 meters North and South) and you can pick any angle from 0* to 360* (I will use compass angles, but the math is done with trig angles). If you randomly select from the continuum of angles, then getting 0* or 90* (or any angle) is equally likely. However, at 0*, the greatest distance to go is 10m, but at 90*, you have 100m within the marker. If you do this very many times, on average, the point will be close to the center (numerically, (5 + 50)/2 = 27.5m). So although we picked the angle at random, the point is biased towards the center.

The intuitive reason that Zen_QuantizeAngles works is that it looks at areas rather than curves. Selecting a continuous angle at random does not account for the 2D shape, while looking at the area between two angles does. It follows that a 2D angle selection algorithm produces an even 2D distribution. The angle that gives the area is the difference between any two angles in the array generated by Zen_QuantizeAngles. That step will change as the radius from the marker's center does. Although it currently on deals with ellipses and rectangles (the only polygons in ArmA 3), it could be used for any closed 2D surface for which the radius can be defined as a function of the angle.

Zen_QuantizeAngles is used separately from Zen_FindPositionPoly mostly for performance reasons. The angular quantization of a marker is not random; it is deterministic and predictable (i.e. running Zen_QuantizeAngles twice for the same arguments give the same result). Once the quantum angles have been calculated, you can use Zen_FindPositionPoly infinitely for the marker. This is what Zen_FindGroundPosition does, but you can now do the same thing (without all the filtering) faster with just these functions.

// From the example above, corrected with angular quanta
_quantumAngles = [[100, 10], 0, 0, 360, "rectangle"] call Zen_QuantizeAngles;
for "_i" from 1 to 1000 do {
   _pos = ["mkTest", [100, 10], 0, "rectangle", _quantumAngles] call Zen_FindPositionPoly;
   0 = [_pos] call Zen_SpawnMarker;
};

That takes about 4.1 seconds for me, and using Zen_FindGroundPosition takes about 40.3 seconds without using any filters. If it has always bothered you that Zen_FindGroundPosition is slow (though it makes up for it in features), then you can now generate points 10x faster (an average of 4ms per point).

If you've never noticed the issue that I'm making a big deal about, you can observe it for yourself now:

// This is the result of the example without quantization
for "_i" from 1 to 1000 do {
   _pos = ["mkTest", [100, 10], 0, "rectangle", [random 360]] call Zen_FindPositionPoly;
   0 = [_pos] call Zen_SpawnMarker;
};

The contents of the angles array for Zen_FindPositionPoly are arbitrary as long as they are numbers. Giving only one random angle is perfectly fine. If the marker dimensions where exactly equal, there would be no difference and you wouldn't need Zen_QuantizeAngles. However, observe the result of that code, and you can see why I've written such a long-winded explanation of this.

Beta

As already stated, the framework is in the beta stage of development. I am making every effort to quality control releases, but there will be bugs. Both new features and old ones could have bugs, issues, and things people just don't like.

There is no ETA or plan for a 'final' version. The framework is a work in progress, and it will continue to progress while there are improvements to be made (there always will be).

Some of the bugs have been pointed out by users, and those fixes are included in the changelog above. I want to thank everyone who has used/supported the framework.

[Zriel 12]

Keep up the good Work!

[Guest]

Thanks for informing us of about the newest version :)

Release frontpaged on the Armaholic homepage.

Co-op Mission Framework and SQF Library 11/12/14 beta

================================================

We have also "connected" these pages to your account on Armaholic.

This means in the future you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

[Toasterbr 12]

NICE!!!

Thanks for the update, Zen! Especially the good work on Zen_FindGroundPosition!

We will start a new map and I'm looking forward to use the new update.

Again, thanks for the hard work! Keep it up!

Toaster

[ke6jzs 1]

I'm almost certain this is going to be the wrong place to post this, but I try to see someone posting what I'm interested in an post in this same area.

Would anyone be willing to assist me in forcing Zen_Framework to use a custom enemy AI instead of the extra-terrestrial looking Opfor? I would like to use a Russian faction I downloaded, "RHS: Armed Forces of the Russian Federation" and the framework use all their equipment for them.

Maybe I could learn to spawn my choice of BluFor, instead of only using NATO?

Please.....

[Zenophon 110]

I'm almost certain this is going to be the wrong place to post this, but I try to see someone posting what I'm interested in an post in this same area.

Would anyone be willing to assist me in forcing Zen_Framework to use a custom enemy AI instead of the extra-terrestrial looking Opfor? I would like to use a Russian faction I downloaded, "RHS: Armed Forces of the Russian Federation" and the framework use all their equipment for them.

Maybe I could learn to spawn my choice of BluFor, instead of only using NATO?

Please.....

This is the right place to post anything about using the framework. You can also PM me if you prefer; it's up to you.

I'm going to quote myself here; all of this still applies even after four months.

In general, all the functions related to directly spawning people and vehicles can spawn addon units, and everything spawned using the framework can be 100% controlled by the mission maker. The framework does not use any preset lists of units that spawn. Whenever it spawns soldiers or vehicles randomly, it dynamically reads the config files looking for certain kinds of objects.

Specifically to your question, I assume you mean spawning soldiers using one of these functions:

• Zen_SpawnGroup
  
• Zen_SpawnInfantry
  

For Zen_SpawnGroup, you can simply list the classnames from the addon units as they appear in the editor or the readme of the mod. This is the fastest, simplest option to get addon units into your mission. For example:

_group = ["mkSpawn", <Array of Addon Classnames Here>] call Zen_SpawnGroup;

This will spawn the soldier objects in order at 'mkSpawn' and return the group. You still might want to set the AI's skill though, using Zen_SetAISkill.

For Zen_SpawnInfantry, getting addon units requires a little more work and some basic knowledge of config files. You need to provide information about certain config file values. However, you then get to use the features of Zen_SpawnInfantry, such as a randomized number and type of units.

You must open the config files in the editor, then find the addon units classnames under cfgVehicles (BIS really needs to add a search/filter option). The values for parameters 5 and 6 are called 'vehicleClass' and 'faction'. See Zen_SpawnInfantry documentation for parameters 5 and 6. For example:

_group = ["mkSpawn", east, 0.3, 5, <vehicleClass value (String)>, <faction value (String)>] call Zen_SpawnInfantry;

This will spawn 5 random soldiers whose side, vehicleClass, and faction match the arguments at 'mkSpawn' with skill 0.3 and return the group.

For vehicle spawning functions, you can give classnames just like Zen_SpawnGroup. However, the crew of the vehicle (for those functions that create it) will be from the vanilla pool of units (they cannot default to anything else). You should first spawn the vehicle empty, using Zen_SpawnVehicle, then spawn the addon crew and put them inside like so:

_vehicle = ["mkSpawn", <Addon Vehicle Classname (String)>] call Zen_SpawnVehicle;
_crew = [_vehicle, <Array of Addon Classnames Here>] call Zen_SpawnGroup;
0 = [_crew, _vehicle, "All"] call Zen_MoveInVehicle;

The vehicle at 'mkSpawn' now has all possible positions filled with addon units from the group. Just be sure to list the right number of classnames for that particular vehicle. You could also use an empty vehicle from the editor instead of spawning one in the code. This lets you put any crew you want into any vehicle.

Finally, if you want to directly generate the classname lists the functions are using, the function to use is Zen_ConfigGetVehicleClasses. See the demonstration mission entitled RandomBattle.Altis for a very detailed explanation of that function and what I just posted about config values.

[callmesarge 7]

I can confirm the framework works perfectly with the RHS faction. It took me a while to identify the faction correctly - I used this code in my mission:

_enemyGroup = [_spawnPos, ENEMY_SIDE, AI_SKILL, [4,8], "rhs_vehclass_infantry", "rhs_faction_msv"] call Zen_SpawnInfantry;  

[ke6jzs 1]

Oh man! Thanks a lot. I really had a feeling it wasn't such a complicated task, but if you don't know, then you don't know. It's 1031 pm and I'm excited to try this! Also thanks for taking PM's. As you know, you've really done a great job with this framework enabling an easy way to make exotic missions.

---------- Post added at 22:36 ---------- Previous post was at 22:35 ----------

Hey Sarge, thanks my friend.

[Zriel 12]

Hi Zen, just a point. until you release the caching system, I'm using ZBE Cache System and it seems to be working pretty nice. Unit captains remain and units are hided/disabled simulation, so it is not a Spawn/UnSpawn, which greatly helps being compatible with many ways of spawming units.

[Zenophon 110]

Hi Zen, just a point. until you release the caching system, I'm using ZBE Cache System and it seems to be working pretty nice. Unit captains remain and units are hided/disabled simulation, so it is not a Spawn/UnSpawn, which greatly helps being compatible with many ways of spawming units.

That script looks very good. There's really no point in me duplicating all that work, so I won't write my own AI caching script until I can offer some unique features. As long as there's some AI caching script that works with the framework, it's not really a missing feature. I will look at existing AI caching scripts and see if there's some significant features I could offer that they don't.

[Zriel 12]

That script looks very good. There's really no point in me duplicating all that work, so I won't write my own AI caching script until I can offer some unique features. As long as there's some AI caching script that works with the framework, it's not really a missing feature. I will look at existing AI caching scripts and see if there's some significant features I could offer that they don't.

XD well, it suits for me.

[Zriel 12]

I've almost finished creating my first mission for our community. It's based on the example mission of assault on airbase Stratis, with a bit more of units and buildings/objects, a briefing and intro, tasks. etc. It's also JIP compatible (worked on it this weekend and as you say, once understood, it's pretty simple and straight forward.)

I'm looking also to some other scripts from various sites to add them into my mission and have a final template, to ease things for the future. I've seen a script that spawns gunners only, so transport choppers are not always empty when transporting people to one side to other.

Could you make an option to "Zen_SpawnVehicleCrew" to only spawn gunners in their positions?

Edited November 24, 2014 by Zriel

[Zenophon 110]

I've almost finished creating my first mission for our community. It's based on the example mission of assault on airbase Stratis, with a bit more of units and buildings/objects, a briefing and intro, tasks. etc. It's also JIP compatible (worked on it this weekend and as you say, once understood, it's pretty simple and straight forward.)

I'm looking also to some other scripts from various sites to add them into my mission and have a final template, to ease things for the future. I've seen a script that spawns gunners only, so transport choppers are not always empty when transporting people to one side to other.

Could you make an option to "Zen_SpawnVehicleCrew" to only spawn gunners in their positions?

I can make Zen_SpawnVehicleCrew only spawn a driver or turrets; I'll add that as a parameter for the release tomorrow. However, the copilot position of helicopters is considered a turret (or any commander type seat on a ground vehicle), so the vehicle will only be missing a driver.

I would have to inspect each turret and try to determine if it really has a weapon, which I'm fairly certain can be done. This warrants a the return of Zen_GetTurretPaths with some new features.

[doman 21]

Zenophon can You please describe how to use Zen_ConfigGetVehicleClasses ?

I tried to modify Zen_RandomBattle to achieve spawning only vehicles and/or soldiers from RHS, but without luck. Can You please explain how to use this function?

[Zenophon 110]

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 should be on Armaholic when Foxhound sees this or I PM him. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc.

Changelog

This release features another 18 changes, including some new features in the form of extra arguments to some common functions. The new function is Zen_IsWaterArea, which is a logical progression from functions like Zen_IsUrbanArea, etc.

Although things looked grim for Zen_GetTurretPaths due to the new allTurrets command, Zen_GetTurretPaths has returned with new life. It can now filter types of turrets based upon what function that turret really has. It can distinguish between commander type turrets, such a copilot or observer with no weapons, true gunner turrets that have access to vehicle-mounted weapons, and fire-from-vehicle turrets for passengers. Of course, I can't test every possible vehicle, so give it a try and report any mistakes it makes.

Zen_MoveInVehicle and Zen_SpawnVehicleCrew can now make use those turret types when they call Zen_GetTurretPaths. Zen_SpawnVehicleCrew also has a parameter to not spawn a driver. This adds a lot of flexibility for what positions are spawned or filled.

The interesting new macro, ZEN_STD_OBJ_AnimateDoors, reads a vehicle's config file and opens or closes all of its doors for you. Zen_OrderFastRope, Zen_OrderHelicopterLand, and Zen_OrderVehicleDrop make use of this macro to add some realism to insertions and resupply drops.

It turns out that setMass is the magic command for Zen_OrderExtraction and Zen_OrderInsertion, and, contrary to all physics logic, setting the mass to 0 makes it impossible to move an object. In reality, an infinite mass is impossible to move with a finite force. However, Bohemian physics aside, those functions now keep the helicopter on the ground at all times with no glitches or performance impact.

Finally, in addition to the usual documentation updates and spot-check fixes, I have done a comprehensive proofreading of all text documentation (everything except function documentation and tutorials) to fix many errors ranging from typos, logical errors, and false information.

11/26/14

1. New Function: Zen_IsWaterArea
   
2. Fixed: Zen_SpawnConvoy used Zen_FindRoadDirection when the given position was not near a road
   
3. Added: Standard macros ZEN_STD_OBJ_AnimateDoors, ZEN_STD_Parse_ToStringLower
   
4. Added: Zen_GetTurretPaths now has a parameter for turret type
   
5. Added: Zen_GiveLoadout now has parameters for additive giving and remote execution
   
6. Added: Zen_GiveLoadoutCustom now has a parameter for additive giving
   
7. Added: Zen_MoveInVehicle now has a parameter for what turret positions to fill
   
8. Added: Zen_SpawnVehicleCrew now has parameters for what turret positions to fill and whether to spawn a driver
   
9. Improved: Zen_FindRoadDirection is now a Position Function
   
10. Improved: Zen_QuantizeAngles uses a more accurate slice of area
    
11. Improved: Zen_OrderExtraction and Zen_OrderInsertion keep the helicopter on the ground when on a slope
    
12. Improved: Zen_OrderFastRope, Zen_OrderHelicopterLand, and Zen_OrderVehicleDrop now open and close all vehicle doors at the proper times
    
13. Documentation: Fixed numerous typos, errors, inconsistencies, and out-dated information in various documentation texts and demonstrations
    
14. Documentation: Fixed ZEN_STD_Parse_ToArray and ZEN_STD_Parse_ToString had their descriptions switched
    
15. Documentation: Added for ZEN_STD_OBJ_AnimateDoors, ZEN_STD_Parse_ToStringLower, Zen_IsWaterArea
    
16. Documentation: Updated for Zen_GetTurretPaths, Zen_GiveLoadout, Zen_GiveLoadoutCustom, Zen_MoveInVehicle, Zen_SpawnVehicleCrew
    
17. Documentation: Updated Zen_CustomLoadouts demonstration
    
18. Documentation: Improved for Zen_GetSide, Zen_GetSideColor
    

Roadmap

While I'm still planning on doing an AI caching system at one point, I'm going to wait until I can bring some unique features that aren't already out there in other AI caching scripts. It may or may not end up as a separate script that requires the framework but isn't directly a part of it.

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. Each week 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_FindRoadDirection. This function makes it easy to place vehicles and road based objectives in a way that makes sense. Putting a car in the middle of the road doesn't make for a very realistic IED.

A good example of placing a vehicle on the side of the road is taken from Zen_SpawnAmbientVehicles:

_carPos = ["mkTown", 0, 0, 1, [1, 100]] call Zen_FindGroundPosition;
_roadDir = [_carPos] call Zen_FindRoadDirection;
_car = [([_carPos, 4, _roadDir + 90, "trig"] call Zen_ExtendPosition), "C_Hatchback_01_F", 0, 90 - _roadDir] call Zen_SpawnVehicle;

Zen_FindRoadDirection will return one direction of the road; the other direction is obviously 180 degrees the other way. At crossroads, the function makes a decision for which road's direction to return. It does not return the average of the four roads, but picks one (the one with more area in the region it's searching) and returns that direction.

You can also use it to place roadblocks convincingly:

_roadblockPos = ["mkTown", 0, 0, 1, [1, 100]] call Zen_FindGroundPosition;
_roadDir = [_roadblockPos] call Zen_FindRoadDirection;
_car1 = [([_roadblockPos, 3, _roadDir + 90, "trig"] call Zen_ExtendPosition), "b_mrap_01_f", 0, _roadDir] call Zen_SpawnVehicle;
_car2 = [([_roadblockPos, 3, _roadDir - 90, "trig"] call Zen_ExtendPosition), "b_mrap_01_hmg_f", 0, -_roadDir] call Zen_SpawnVehicle;
_guards = [([_roadblockPos, 7, _roadDir, "trig"] call Zen_ExtendPosition), west, "infantry", 3] call Zen_SpawnInfantry;

You can also put crew in the vehicles and make the infantry patrol in a small area around the checkpoint. Using Zen_FindRoadDirection and a little trigonometry you can quickly create good roadblocks or IED's that look as good as anything placed in the editor.

Beta

As already stated, the framework is in the beta stage of development. I am making every effort to quality control releases, but there will be bugs. Both new features and old ones could have bugs, issues, and things people just don't like.

There is no ETA or plan for a 'final' version. The framework is a work in progress, and it will continue to progress while there are improvements to be made (there always will be).

Some of the bugs have been pointed out by users, and those fixes are included in the changelog above. I want to thank everyone who has used/supported the framework.

---------- Post added at 21:19 ---------- Previous post was at 21:08 ----------

Zenophon can You please describe how to use Zen_ConfigGetVehicleClasses ?

I tried to modify Zen_RandomBattle to achieve spawning only vehicles and/or soldiers from RHS, but without luck. Can You please explain how to use this function?

That demonstration names the actual config values that the function is looking at:

• vehicleClass = class types (1)
  
• textSingular = subtypes (3)
  
• faction = vehicle faction (4)
  

You can look in the config files in the editor, find the addon unit, and find the values at those config entries. Alternatively, you can use SQF code to read those values for you, e.g.:

systemChat str getText (configFile >> "CfgVehicles" >> (Classname of addon object) >> "vehicleClass");

All of them will use getText; you can also use 'copyToClipboard'. Once you have all the types, subtypes, and factions you want, enter them and the correct side into Zen_ConfigGetVehicleClasses.

[Guest]

Thanks for informing us of about the newest version :)

Release frontpaged on the Armaholic homepage.

Co-op Mission Framework and SQF Library 11/26/14 beta

================================================

We have also "connected" these pages to your account on Armaholic.

This means soon you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

[Zriel 12]

I think there's a bug with Zen_SpawnGroundVehicle and the new Zen_GeturretPaths;

This is what I do:

_o_B_apc1 = ["mkAPC1", ["b_apc_wheeled_01_cannon_f", "b_apc_tracked_01_rcws_f"], 55] call Zen_SpawnGroundVehicle;

This is the error I get.

http://i.gyazo.com/2abb8c139ed3f62d32fbfe411da4d50d.png (287 kB)

[cdn_biggdogg 29]

Hey Zenophon! Great script! It's helped me get into and understand scripting for Arma. Many thanks for that.

I seem to have an issue with spawning the FIA OpFor units using Zen_SpawnInfantry. They are "EAST" units, they are vehicleClass "Men" and the faction name is "OPF_G_F". But when I try to spawn them it gives me an error and they won't spawn.

They are a vanilla arma faction and not from an addon so I'm a little stumped with this.

The code I'm using looks like this:

_group = [_groupPos, east, 1, [3, 5], "Men", "OPF_G_F"] call Zen_SpawnInfantry;

And I get this from the .rpt:

17:53:09 "No soldiers found for the given side, type, faction, and blacklist"

17:53:09 99.091

17:53:09 [[15394.5,17112,0],GUER,1,[3,5],"MEN","OPF_G_F"]

17:53:09 "-- Zen_CheckArguments Error --"

17:53:09 "Argument 2 is void"

I also tried using resistance for the side but it gave me the same result.

I'm a very novice scripter and might be doing something wrong so if anyone else can confirm this???

Edited November 27, 2014 by CDN_BiggDogg

[Zriel 12]

You are doing correctly, seems the framewok is not finding those factions. As it is not in the editor, I didn't even knew they existed XD

[cdn_biggdogg 29]

Thanks Zriel for confirming that. I'm guessing it may be more of a BIS issue than Zenophon's framework since it's true that they don't show up in the editor. However if you call them in ALiVE's CQB module they do spawn.

Also Zenophon I found an error in your Zen_MoveInVehicle.sqf found in the Zen_FrameworkFunctions\Zen_ObjectFunctions folder at line 23. You have:

ZEN_STD_Parse_GetArgument(_turretTypes, 3, ["All"]) and it returns an error with _turretTypes being an undefined variable which breaks the Zen_SpawnGroundVehicle and broke my mission (LOL) ... probably because of the way I have it set up.

I changed it to:

ZEN_STD_Parse_GetArgumentDefault(_turretTypes, 3, ["All"]) and all returned to normal again. All my tanks and such returned to try and kill me.

Anyway thought you should know and again thanks for the wonderful framework!

CDN_BiggDogg

[callmesarge 7]

Hi Zen,

I just updated to the latest version of the framework, and I seem to be encountering a stange issue with loadout code. It is strange because the issue only presents when the mission is running on a dedicated sewrver - testing in editor or hosting locally, the mission runs fine.

The error messages below show the issue. The bottom message happened at the start of the mission, and the unit did not recieve the correct loadout - however, the loadout could still be obtained from the loadout box. Then when the enemy units spawned, I saw the top issue. However, it appeared that the units I saw spawned with the correct loadout (i was unable to check all of the spawned units however). The loadout being called in the upper line is either loadout1, line 82 in the init, or loadout11, line 119 in the init. I am unsure why the name is garbled in the error.

Errors:

Mission init: http://pastebin.com/FzL7dr4D

Is this an issue with the server I am running on do you think? Any advice would be appreciated.

[Zenophon 110]

Hey Zenophon! Great script! It's helped me get into and understand scripting for Arma. Many thanks for that.

I seem to have an issue with spawning the FIA OpFor units using Zen_SpawnInfantry. They are "EAST" units, they are vehicleClass "Men" and the faction name is "OPF_G_F". But when I try to spawn them it gives me an error and they won't spawn.

They are a vanilla arma faction and not from an addon so I'm a little stumped with this.

The code I'm using looks like this:

_group = [_groupPos, east, 1, [3, 5], "Men", "OPF_G_F"] call Zen_SpawnInfantry;

And I get this from the .rpt:

17:53:09 "No soldiers found for the given side, type, faction, and blacklist"

17:53:09 99.091

17:53:09 [[15394.5,17112,0],GUER,1,[3,5],"MEN","OPF_G_F"]

17:53:09 "-- Zen_CheckArguments Error --"

17:53:09 "Argument 2 is void"

I also tried using resistance for the side but it gave me the same result.

I'm a very novice scripter and might be doing something wrong so if anyone else can confirm this???

Zen_ConfigGetVehicleClasses uses the 'access' attribute to filter out a lot of base classes. Only classes with access = 2 are shown in the editor, and those the only classes Zen_ConfigGetVehicleClasses checks as possibilities. Without this optimization it's harder to identify and skip over unspawnable classes. You can use Zen_SpawnGroup as a workaround, as it only checks if the class is a subclass of "Man".

Thanks Zriel for confirming that. I'm guessing it may be more of a BIS issue than Zenophon's framework since it's true that they don't show up in the editor. However if you call them in ALiVE's CQB module they do spawn.

Also Zenophon I found an error in your Zen_MoveInVehicle.sqf found in the Zen_FrameworkFunctions\Zen_ObjectFunctions folder at line 23. You have:

ZEN_STD_Parse_GetArgument(_turretTypes, 3, ["All"]) and it returns an error with _turretTypes being an undefined variable which breaks the Zen_SpawnGroundVehicle and broke my mission (LOL) ... probably because of the way I have it set up.

I changed it to:

ZEN_STD_Parse_GetArgumentDefault(_turretTypes, 3, ["All"]) and all returned to normal again. All my tanks and such returned to try and kill me.

Anyway thought you should know and again thanks for the wonderful framework!

CDN_BiggDogg

Good find, I meant to set the default on the previous line as in Zen_SpawnVehicleCrew. I guess that's what happens when I test optional arguments only by giving the optional argument.

Hi Zen,

I just updated to the latest version of the framework, and I seem to be encountering a stange issue with loadout code. It is strange because the issue only presents when the mission is running on a dedicated sewrver - testing in editor or hosting locally, the mission runs fine.

The error messages below show the issue. The bottom message happened at the start of the mission, and the unit did not recieve the correct loadout - however, the loadout could still be obtained from the loadout box. Then when the enemy units spawned, I saw the top issue. However, it appeared that the units I saw spawned with the correct loadout (i was unable to check all of the spawned units however). The loadout being called in the upper line is either loadout1, line 82 in the init, or loadout11, line 119 in the init. I am unsure why the name is garbled in the error.

Errors:

http://i227.photobucket.com/albums/dd250/joelees/2014-11-28_00002_zps8b2fe42f.jpg

Mission init: http://pastebin.com/FzL7dr4D

Is this an issue with the server I am running on do you think? Any advice would be appreciated.

The issue is only in MP because Zen_GiveLoadoutCustom does not remote execute itself with the correct arguments. I forgot that the default of optional arguments must be appended to the remote execution arguments.

The loadout name being shown is the internal string name of the loadout. You can set this when the loadout is created using the second argument to Zen_CreateLoadout.

-----

I've updated the latest framework version for the Google drive link with these two fixes.