Jump to content
Zenophon

Zenophon's ArmA 3 Co-op Mission Making Framework

Recommended Posts

Sorry for the numerous questions. I am just so dedicated in understanding and learning as much as I can. My question is in regards to the customLoadout. I read the custom loadout in the demonstration and did the following steps-with no success:

#include "Zen_FrameworkFunctions\Zen_InitHeader.sqf"

/
enableSaving [false, false];
if (!isServer) exitWith {};
sleep 1;
                               // Enter the mission code here
_loadout = [
   [["uniform", "U_B_SpecopsUniform_sgg"],
   ["vest", ["V_Chestrig_khk", "V_Chestrig_rgr", "V_Chestrig_blk", "V_Chestrig_oli", "V_TacVest_khk", "V_TacVest_oli", "V_TacVest_camo"]],
   ["backpack", ["B_AssaultPack_mcamo", "B_OutdoorPack_blk", "B_Kitbag_mcamo", "B_Bergen_mcamo", "B_Bergen_blk", "B_TacticalPack_mcamo", "B_TacticalPack_rgr"]],
   ["headgear", ["H_MilCap_mcamo", "H_Cap_tan_specops_US", "H_Watchcap_sgg", "H_Bandanna_sgg", "H_HelmetB_light_grass", "H_HelmetB_light_snakeskin", "H_HelmetB_light_desert", "H_HelmetB_light_black", "H_HelmetB_light_sand"]],
   ["assignedItems", ["ItemMap","ItemCompass","ItemWatch","ItemRadio","ItemGPS","NVGoggles"]],
   ["weapons", [["arifle_MX_Black_F", "arifle_MXC_Black_F"],"hgun_Pistol_heavy_01_F","Rangefinder"]],
   ["magazines", [["30Rnd_65x39_caseless_mag", 9], ["11Rnd_45ACP_Mag", 2], ["HandGrenade", 2], [["SmokeShell", 4], ["SmokeShellBlue", 4]]]],
   ["items", ["FirstAidKit", "FirstAidKit"]],
   ["primaryAttachments", ["muzzle_snds_H","acc_pointer_IR",["optic_Hamr", "optic_aco"]]]
   // ["goggles",""],
   // ["secondaryAttachments",[]],
   // ["handgunAttachments",[]]
]] call Zen_CreateLoadout;
player sideChat str ([_loadout] call Zen_GetLoadoutData);
0 = [player, _loadout, "custom"] call Zen_GiveLoadout;

Failing this, I opened your Evade mission, and tried to replicate all that you did, verbatim.

I copied your CustomLoadout.sqf into my mission folder, and added the code from your init.sqf to my init:

#include "Zen_FrameworkFunctions\Zen_InitHeader.sqf"

/
enableSaving [false, false];
#define BLUFOR_LOADOUTS ["SF Rifleman", "SF Marksman", "SF MG", "SF Grenadier"]

if (!isServer) exitWith {};
sleep 1;
                               // Enter the mission code here
#include "CustomLoadouts.sqf"                            
0 = [group X, BLUFOR_LOADOUTS] call Zen_GiveLoadoutCustom;

This did not work.

What am I doing wrong?

My ultimate goal is to have two types of opfor units (militia and tier 1). The militia units will have, for example, a militaloadout.sqf in which there will be four different loadout to choose from; similarly, the tier 1 opfor will have its own tier1loadout.sqf in which there will be four different loadouts to choose from. I know how to get the loadouts in the correct format, I am just stuck at actually having it apply to the units.

Edited by chondo999

Share this post


Link to post
Share on other sites
Sorry for the numerous questions. I am just so dedicated in understanding and learning as much as I can. My question is in regards to the customLoadout. I read the custom loadout in the demonstration and did the following steps-with no success:

...

No need to apologize for questions; it's no trouble.

When I run that code, I get an error and a stack trace about 'custom' not being a loadout. It should be:

0 = [player, "custom", _loadout] call Zen_GiveLoadout;

Where the 'custom' literal identifier goes before the loadouts names. I will admit that the documentation for that function is a little esoteric. You can just use:

0 = [player, _loadout] call Zen_GiveLoadoutCustom;

Which is a more direct function. Zen_GiveLoadout is meant for situations in which you cannot hard-code the side or even type of loadout. Both of the above are working for me with the rest of the loadout code.

Failing this, I opened your Evade mission, and tried to replicate all that you did, verbatim.

I copied your CustomLoadout.sqf into my mission folder, and added the code from your init.sqf to my init:

...

This did not work.

What am I doing wrong?

My ultimate goal is to have two types of opfor units (militia and tier 1). The militia units will have, for example, a militaloadout.sqf in which there will be four different loadout to choose from; similarly, the tier 1 opfor will have its own tier1loadout.sqf in which there will be four different loadouts to choose from. I know how to get the loadouts in the correct format, I am just stuck at actually having it apply to the units.

For this code, do you have an object named 'X'? This is the generic name I give to the leader of the player group. You could try:

0 = [group player, BLUFOR_LOADOUTS] call Zen_GiveLoadoutCustom;

The only reason I do not use 'player' in my mission is because it is undefined on a dedicated server; in that case the server needs a global object name. In this mission, the loadouts have literal string names that can be used directly. This is not done in the Custom Loadout demonstration.

You have two options when creating the loadout:

// this loadout is given a random name, assigned to _loadout1
_loadout1 = [[...]] call Zen_CreateLoadout;

// this loadout gets the name 'Loadout Name', assigned to _loadout2
_loadout2 = [[...], "Loadout Name"] call Zen_CreateLoadout;

For the first one, you must use the variable '_loadout1' to refer to the loadout. For the second, you can use '_loadout2' or "Loadout Name" when giving the loadout, getting its data, etc.

All the prepreprocessor #include/#define things are just copy-paste commands to make things more compact and avoid repeating code. I would only recommend doing that when the loadouts are already working. You can also put all loadouts in one file; you could #include just one .sqf file that contains dozens of loadouts, then use #define to set up the lists of loadouts.

  • Like 1

Share this post


Link to post
Share on other sites

Zen, could you please extend the "AI State" parameter to the OrderInfantryPatrolBuilding? Secondly, after I create a loadout, how do I apply it to any opfor unit I spawn? I know for players I could just reference to the group or give them names, but I cannot reference to the spawned units. I tried many things including:

_innerGuardsGroupArray set [(count _innerGuardsGroupArray), _InnerGuard];

};

0 = [_innerGuardsGroupArray, _loadout] call Zen_GiveLoadoutCustom;

Edited by chondo999

Share this post


Link to post
Share on other sites
Zen, could you please extend the "AI State" parameter to the OrderInfantryPatrolBuilding? Secondly, after I create a loadout, how do I apply it to any opfor unit I spawn? I know for players I could just reference to the group or give them names, but I cannot reference to the spawned units. I tried many things including:

_innerGuardsGroupArray set [(count _innerGuardsGroupArray), _InnerGuard];

};

0 = [_innerGuardsGroupArray, _loadout] call Zen_GiveLoadoutCustom;

Yeah, adding the AI behavior parameter to Zen_OrderInfantryPatrolBuilding is very easy. That will be included in the next version, which will be released this Wednesday.

For the loadout, it is working for me when I do something like this:

// _loadout is created somewhere above
_patrolGroupsArrayOpfor = [];
for "_i" from 1 to 5 do {
   _spawnPosition = ["mkSpawn"] call Zen_FindGroundPosition;
   _patrolGroup = [_spawnPosition, east, "infantry", [3, 4]] call Zen_SpawnInfantry;
   _patrolGroupsArrayOpfor set [(count _patrolGroupsArrayOpfor), _patrolGroup];
};

0 = [_patrolGroupsArrayOpfor, _loadout] call Zen_GiveLoadoutCustom;

You can also try this after the spawning loop:

player sideChat str _innerGuardsGroupArray

If the game prints out a list of names like O alpha 1-1... etc. then the array has the correct data.

If it still doesn't work, you can give loadouts to the groups individually as they spawn:

_spawnPosition = ["mkSpawn"] call Zen_FindGroundPosition;
_patrolGroup = [_spawnPosition, east, "infantry", [3, 4]] call Zen_SpawnInfantry;
0 = [_patrolGroup , _loadout] call Zen_GiveLoadoutCustom;

Share this post


Link to post
Share on other sites

Before jumping into custom loadouts, I was examining the various framework functions for loadouts that exist. In your "MultiSquadObjective" tutorial you say to use this bit

// Loadout options
0 = [bLUFORLoadouts,["AA Specialist","AT Rifleman","AT Specialist","Grenadier"],-1] call Zen_AddLoadoutDialog;

and when looking at "Zen_CustomLoadout.sqf" in the demonstrations, you state this

/** To strike a balance between letting players pick any equipment they want (VAS) and forcing a single loadout on them (editor), the function Zen_AddLoadoutDialog allows players to select from a list of preset loadouts (and choose for their AI too).  You can include your custom loadouts in this list, allowing the mission-maker to set the style of the players' equipment for a mission.  It is highly recommended that you name your loadout when using Zen_CreateLoadout for this; otherwise, no one will know which loadout is which.  You need to assign this dialog menu to an object (similar to VAS); this can be a box, a car, or any object.*/

// This assumes that _loadout1, _loadout2, and box exist
0 = [box, [_loadout, _loadout1, _loadout2], 2] call Zen_AddLoadoutDialog;

which would lead one to believe that in the tutorial, you have a typo in that you don't want "BLUEFORLoadouts" or you have forgotten to create an object that uses the global "BLUEFORLoadouts" as its variable. Or there is a global somewhere I could not find. Either way, that line of code throws an error for me (specifically Error Undefined variable in expression: bluforloadouts).

EDIT: I was recreating this from scratch to learn with. Seems if I had opened the original mission file (or read the pdf close enough) I would have seen you had created an ammobox in the editor. So there is not a typo in the tutorial, just did it differently than I expected.. however using that bit of code in my mission with a dynamically created object only gives me civilian gear.

Is it accurate that those loadouts in that example (ie. "AA Specialist") are already declared and therefore can be used? I think that is the case, but when I did create an object, and use it in that code sample, all my character ended up with was civilian clothes and no weapons...

0 = [julie,["AA Specialist","AT Rifleman","AT Specialist","Grenadier"],-1] call Zen_AddLoadoutDialog;

I would also assume that if you have an object created and you use that in the call, that one can somehow use this addAction entry to equip one of your ai units? It is like VAS from what I see in that you get near the addAction object and the menu entry appears, but I don't see how to utilize this with an ai unit as you state. Must be missing something.

Also, is it possible to add an option to put some color in the menu entry like VAS does? Yep, I could do it, but first we will see whether thats something you think would be good to include ;)

Edited by m0nkey

Share this post


Link to post
Share on other sites
Before jumping into custom loadouts, I was examining the various framework functions for loadouts that exist. In your "MultiSquadObjective" tutorial you say to use this bit
// Loadout options
0 = [bLUFORLoadouts,["AA Specialist","AT Rifleman","AT Specialist","Grenadier"],-1] call Zen_AddLoadoutDialog;

and when looking at "Zen_CustomLoadout.sqf" in the demonstrations, you state this

/** To strike a balance between letting players pick any equipment they want (VAS) and forcing a single loadout on them (editor), the function Zen_AddLoadoutDialog allows players to select from a list of preset loadouts (and choose for their AI too).  You can include your custom loadouts in this list, allowing the mission-maker to set the style of the players' equipment for a mission.  It is highly recommended that you name your loadout when using Zen_CreateLoadout for this; otherwise, no one will know which loadout is which.  You need to assign this dialog menu to an object (similar to VAS); this can be a box, a car, or any object.*/

// This assumes that _loadout1, _loadout2, and box exist
0 = [box, [_loadout, _loadout1, _loadout2], 2] call Zen_AddLoadoutDialog;

which would lead one to believe that in the tutorial, you have a typo in that you don't want "BLUEFORLoadouts" or you have forgotten to create an object that uses the global "BLUEFORLoadouts" as its variable. Or there is a global somewhere I could not find. Either way, that line of code throws an error for me (specifically Error Undefined variable in expression: bluforloadouts).

EDIT: I was recreating this from scratch to learn with. Seems if I had opened the original mission file (or read the pdf close enough) I would have seen you had created an ammobox in the editor. So there is not a typo in the tutorial, just did it differently than I expected.. however using that bit of code in my mission with a dynamically created object only gives me civilian gear.

Is it accurate that those loadouts in that example (ie. "AA Specialist") are already declared and therefore can be used? I think that is the case, but when I did create an object, and use it in that code sample, all my character ended up with was civilian clothes and no weapons...

0 = [julie,["AA Specialist","AT Rifleman","AT Specialist","Grenadier"],-1] call Zen_AddLoadoutDialog;

I would also assume that if you have an object created and you use that in the call, that one can somehow use this addAction entry to equip one of your ai units? It is like VAS from what I see in that you get near the addAction object and the menu entry appears, but I don't see how to utilize this with an ai unit as you state. Must be missing something.

Also, is it possible to add an option to put some color in the menu entry like VAS does? Yep, I could do it, but first we will see whether thats something you think would be good to include ;)

Zen_AddLoadoutDialog is meant to be put on an object like a car, an ammo box, etc. I actually never tested it by putting it on the player (and I don't recommend that, from both a usability and realism standpoint). All of the preset loadouts (see the documentation for Zen_GiveLoadoutBlufor etc.) can be used with this function, as well as any custom loadouts you have created with Zen_CreateLoadout. You can mix and match them to your liking, just remember to give custom loadouts a real name, or they will display as random ASCII characters.

The dialog does not do anything automatically, you need to use the action and select a loadout from the menu. For the AI, because AI in your group are local to you, when they use the action the dialog appears on your screen and your choice affects them. Use command menu 6 to get them to use the action.

Putting all custom framework actions in a different color is a good idea, just to differentiate them from default BIS actions. Though I will probably opt for a softer color than bright red. Hopefully that makes in to release this Wednesday.

Share this post


Link to post
Share on other sites

I created a heli, named it "julie" and then added

0 = [julie,["AA Specialist","AT Rifleman","AT Specialist","Grenadier"],-1] call Zen_AddLoadoutDialog; 

to the init file. The addAction menu entry was available on the heli once I got close enough. The 4 loadouts were available to choose from. However, when choosing one of them, I was given civilian gear only, each one the same with a random color.

I am under the impression that these are globally defined "loadouts" and that I don't need to declare them in my own custom loadout, is that correct? If so, what might I have missed in the call? Literally I just placed a group with me as leader, a heli named "julie" and that line of code. It should work from what I gather.

I also did not see anything in command menu 6 to do regarding the action, but I will check this all again tonight and see if I can uncover what the deal is.

I did not test it by putting it on a player/unit. I have not messed with custom loadouts, although that will be soon in coming.

Thanks.

Share this post


Link to post
Share on other sites
I created a heli, named it "julie" and then added

0 = [julie,["AA Specialist","AT Rifleman","AT Specialist","Grenadier"],-1] call Zen_AddLoadoutDialog; 

to the init file. The addAction menu entry was available on the heli once I got close enough. The 4 loadouts were available to choose from. However, when choosing one of them, I was given civilian gear only, each one the same with a random color.

I am under the impression that these are globally defined "loadouts" and that I don't need to declare them in my own custom loadout, is that correct? If so, what might I have missed in the call? Literally I just placed a group with me as leader, a heli named "julie" and that line of code. It should work from what I gather.

I also did not see anything in command menu 6 to do regarding the action, but I will check this all again tonight and see if I can uncover what the deal is.

I did not test it by putting it on a player/unit. I have not messed with custom loadouts, although that will be soon in coming.

Thanks.

Is your character a civilian or on the civilian side somehow? This causes the function that determines which side of loadout to give to just give civilian clothes. Because the preset loadouts are for every side the function must give loadouts based upon side to prevent soldiers from getting enemy equipment. For civilians, it never gives weapons as that would make them combatants and not civilians. This does not apply to custom loadouts.

Try playing as a Blufor or Opfor soldier, and see if the presets work then.

Share this post


Link to post
Share on other sites

It was a blufor fireteam group I placed with the editor, then set the leader of the group as 'player'. I then placed a heli near the group and named it 'julie'. I then used that line in the init.sqf. No civilian stuff at all. Like I said, will test it more closely tonight.

EDIT: That is strange yet at the same time makes sense. I setcaptive to true in the units init, so technically it was a civilian. That was for testing the convoys that exhibit an issue, forgot it was there. Remove that and it works as it should.

Edited by m0nkey

Share this post


Link to post
Share on other sites

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 an technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc.

Changelog

This update has 25 changes, which is a good set of improvements, but certainly not that many for a whole week of development. The most important change is a new function: Zen_FindRoadDirection, the first new function since the public release of the framework. Incidentally, it makes use of Zen_ArraySort, the function spotlighted last week.

There are also 6 coding bug fixes, including a major fix for Zen_ArraySort. The change to Zen_ArraySort was hotfixed several hours after release; hopefully no one tried the function and couldn't get it work. Last week's improvements to Zen_SpawnParachute broke its ability to land objects on rooftops; that feature has now been restored and is working 100%. Two task system bugs were also fixed; Zen_AreUnitsTasksComplete is now actually working, and Zen_UpdateTask no longer shows the wrong notification.

The last of the bug fixes are a set of changes in Zen_OrderVehicleMove, Zen_SpawnConvoy, and Zen_CreateObjective to get 'convoy' type objectives working consistently. I cannot solve AI driving problems, but the convoy should now at least attempt to move in all situations. For anyone creating convoys without Zen_CreateObjective, Zen_OrderVehicleMove is now more effective than ever at getting the whole group to move.

Other highlights include optimizations to the various framework action functions, and making those actions a custom color. I chose a light blue that is visible during the day or night and isn't distracting. Also, Blufor soldiers look fairly convincing while wearing a few of the new bandannas; this realistically represents what soldiers might wear in dusty environments. Zen_SpawnAmbientVehicles now puts vehicles at the sides of the road (but sometimes in the middle of intersections) much more realistically than before. Sometimes, it looks more like they were placed in the editor than randomly by a function!

The documentation was not forgotten, with several fixes to the tutorials to make sure they are working perfectly. The sample missions have also received comments and readability improvements, along with a table of contents. For those who thought they were too confusing before, give some of the easier ones a try.

7/23/14

  1. New Function: Zen_FindRoadDirection
  2. Fixed: Zen_AreUnitsTasksComplete was case sensitive for task names and states
  3. Fixed: Zen_ArraySort duplicated some elements and removed others
  4. Fixed: Zen_OrderVehicleMove did not use the move command properly if the given vehicle was grouped with others
  5. Fixed: Zen_OrderExtraction no longer allows the helicopter to run away when under enemy fire
  6. Fixed: Zen_SpawnParachute did not detach the object when the parachute reached a building's roof
  7. Fixed: Zen_UpdateTask displayed a duplicate 'Task Created' notification when a property other than the state of the task was updated
  8. Improved: Zen_AddEject, Zen_AddFastRope, Zen_AddGiveMagazine, Zen_AddLoadoutDialog, and Zen_AddRepackMagazines now use a custom color for their action text
  9. Improved: Zen_AddFireSupportAction, Zen_ShowHideMarkers, and various private functions now check for headless clients (HC)
  10. Improved: Zen_AddGiveMagazine, Zen_AddLoadoutDialog, Zen_AddRepackMagazines optimized by not giving actions to a dedicated server or HC
  11. Improved: Zen_CreateObjective 'convoy' objective now rotates the convoy on the road to best face their destination
  12. Improved: Zen_GiveLoadoutBlufor and Zen_GiveLoadoutIndfor now randomly give facewear to some loadouts
  13. Improved: Zen_OrderInfantryPatrolBuilding now has a parameter for AI behavior
  14. Improved: Zen_OrderVehicleMove logic for stopping the thread and vehicle improved
  15. Improved: Zen_SpawnAmbientVehicles now attempts to spawn vehicles at the side of the road, instead of the middle
  16. Improved: Zen_SpawnConvoy now spawns vehicles in an orderly line on the road and orders them to keep in formation
  17. Improved: Zen_SpawnParachute aesthetic quality of the parachute spawning and opening improved
  18. Improved: Zen_SpawnVehicle now forces flying objects (height > 2) to spawn at the exact given position
  19. Documentation: Fixed tutorial Altis Patrol group reinforcement function spawned unnecessary helicopters
  20. Documentation: Fixed tutorial Mission Briefing solution mission.sqm did not include some markers
  21. Documentation: Fixed tutorial Multi-Squad Objectives target vehicle did not get a crew
  22. Documentation: Added for Zen_FindRoadDirection
  23. Documentation: Added proper table of contents to Sample Missions readme.txt
  24. Documentation: Improved all Sample Missions with comments
  25. Documentation: Updated for Zen_OrderInfantryPatrolBuilding

Roadmap

Looking to next week, some new functions and minor improvements are planned. Zen_ConfigGetVehicleClasses will get a parameter for the selection of DLC vehicles, Zen_FindGroundPosition will help you prevent generating positions off the map (in the black), and Zen_SetAISkill will reduce of presets only at night to a more realistic level.

The new functions are very much work in progress ideas; however, they are meant to determine if a certain area of land is a certain type. Their names might go like: Zen_IsForestArea, Zen_IsHillArea, Zen_IsUrbanArea, and so on. If they are all very similar, I might just combine them into one function with another parameter for the type of land.

The point of these is to provide dynamic evaluation of a unknown area of terrain in code, so that your code can look at an area of the map and make a reasonable decision, like a human looking at the editor would.

Function Spotlight

As users of my framework know, there are 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 found useful, PM me and I can spotlight it.

The function chosen for this week is: Zen_OrderVehicleDrop.

This function makes dynamically dropping any vehicle very easy. You need only provide an existing aircraft, a drop point, and what to drop. It can drop an existing object by teleporting under the aircraft, or give a classname and a new object will be spawned.

You can place a helicopter in the editor, or spawn one with a function, then use:

0 = [Heli, player, "B_MBT_01_TUSK_F"] spawn Zen_OrderVehicleDrop;

This will drop a tank directly onto the player's position. Obviously, a tank couldn't be carried by a helicopter, but you are free to drop any vehicle, ammo box, or static weapon you want. With the improvements to Zen_SpawnParachute, which is used by this function, the objects you drop can land on rooftops as well.

You can also make the helicopter leave the area easily:

0 = [Heli, [player, Heli], "Box_NATO_Wps_F"] spawn Zen_OrderVehicleDrop;

The player will get an ammo drop and see the helicopter returning to its original position. Although, you might want to delete the helicopter later, if you don't use it again.

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).

Feedback

A few 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.

The specific request this week is: function documentation. I want your opinion about how complete and helpful the description of each function is. Was anything left out? Are you unsure exactly what it will do? Any feedback on this, like all feedback, is appreciated.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for informing us about the updated release :cool:

Release frontpaged on the Armaholic homepage.

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

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!

Share this post


Link to post
Share on other sites

Good day, Zen. I wanted to get your advice on something. For example, the mission is to HALO then clear a town. It is more efficient to spawn the enemy patrols in one sweep or more efficient to use a (WaitUntil) player has landed then spawn the patrols? Imagine this on a grander scale. For example, there are 3 towns that need to be cleared. Would using a (Waituntil) Town1 patrols are dead before spawning Town2 patrols, then another (WaitUntil) Town2 patrols are dead before spawning Town3 patrols, more efficient than spawning all Town patrols at once?

Edited by chondo999

Share this post


Link to post
Share on other sites
Good day, Zen. I wanted to get your advice on something. For example, the mission is to HALO then clear a town. It is more efficient to spawn the enemy patrols in one sweep or more efficient to use a (WaitUntil) player has landed then spawn the patrols? Imagine this on a grander scale. For example, there are 3 towns that need to be cleared. Would using a (Waituntil) Town1 patrols are dead before spawning Town2 patrols, then another (WaitUntil) Town2 patrols are dead before spawning Town3 patrols, more efficient than spawning all Town patrols at once?

For waiting until the player lands, their are two questions here. Can the player be shot at will parachuting? When will the player be least likely to see them spawn? If the player is far away and lands out of sight, then waiting is fine. If the player could landing 100 meters away, you want all patrols there from the start.

Spawning multiple areas of patrols is mostly about freedom of movement. Can the player choose which town to attack first? Or is the mission more linear? If you can't be sure where to player will go, you have to spawn all patrols right at the beginning. If the mission is linear, it is more efficient and saves processing to not spawn the patrols. Generally a good rule is: if the player can't see or interact with something, don't spawn it.

There is a middle ground to this: only spawn patrols when the player gets close. You can use a loop or open new threads that wait for the player to get near the town. Something like:

0 = [] spawn {
  waitUntil {
       sleep 5;
       (([player, "mkTown"] call Zen_Find2dDistance) < 500)
   };

   // spawn patrols...
};

If you want to get into more complex solutions, look at the Even Queue demonstration. The system I use there is designed for exactly what you describe: a non-linear mission with patrols and objectives in different places. It also then allows you to have events in your mission change how it plays out; e.g. something different happens based upon which objective players did first.

  • Like 1

Share this post


Link to post
Share on other sites

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 update has 27 changes, just two more than last week. The most important change is a new function: Zen_IsForestArea. This is the second new function, but it was meant to be joined by a few more that I promised. Unfortunately, the algorithm for Zen_IsForestArea and its companion functions is a bit of a grey area.

The next important item is a renaming, the first to appear in public releases. That which was Zen_ConfigGetTowns is now Zen_ConfigGetLocations. Its parameters have also been changed, and it now requires one argument. I apologize for the inconvenience, but as explained in the FAQ, I will make no effort to support legacy code. It only takes 5 minutes to update your mission to use this correctly.

While some things seem unimportant now, the framework tries to look to the future, so Zen_ConfigGetVehicleClasses now has a parameter (optional) for including/excluding DLC vehicles and units. Unless you really love/hate the karts, it's not that interesting at the moment.

There are also 8 bug fixes, ranging from removing debug (which is always cryptic and annoying) to getting the AI to cooperate with Zen_MoveInVehicle. There were issues with AI stopping and getting in/out trying to sort themselves in the vehicle, but no more; they have been convinced that they should stay in their seats. As always, the argument checking bugs are not extinct yet, but Zen_AreUnitsTasksComplete is free of them.

Zen_OrderInsertion is currently being worked on; the current changes improve behavior when the crew of the vehicle are the ones being inserted. Internal testing still intermittently shows some issues, so more work must be done to get that situation working 100%, especially with boats.

In both the fixed and improved categories this week is Zen_FindGroundPosition, which is more than entitled to its five changes considering its size. The bug fixes solve some issues with positions around an object that somehow survived this long. I am also in the process of making major optimization improvements in situations where failure is certain. Previously, giving impossible filters resulted in 1000 iterations and a generic error. This release, roads and water are screen beforehand to make sure they are possible, and the number of iterations scales with the given area. A tiny 20x20 marker will only try a few dozen times before stopping, while an area spanning several kilometers will still use the full 1000 limit. Zen_FindGroundPosition will also print a friendly error when the position is off the map (in the black), but it will not stop you from using that position.

The loadout functions seem to make their way into the changelog every week, this time with minor improvements to taking off units' NVG's during the day. They will still be in inventory in case players need them during a 2-3 hour mission. Finally, Zen_SetAISkill reduces AI accuracy at night, because it is hard to aim in the dark or with NVG's due to the lack of color and contrast. This should make night firefights more fun by not giving the AI an advantage over players.

7/30/14

  1. New Function: Zen_IsForestArea
  2. Fixed: Zen_AreUnitsTasksComplete did not allow a 0 for parameter 2 through argument checking
  3. Fixed: Zen_FindGroundPosition distribution of points around an object was uneven if the minimum distance was small
  4. Fixed: Zen_FindGroundPosition position around a point or object could be within the minimum area if on a road
  5. Fixed: Zen_FindRoadDirection printed a debug message
  6. Fixed: Zen_MoveInVehicle 'All' argument resulted in confusion for the AI and odd behavior
  7. Fixed: Zen_MoveInVehicle now assigns units to their turret properly
  8. Fixed: Zen_OrderInsertion now makes units get out of the vehicle in all circumstances
  9. Fixed: Zen_SpawnInfantry spawned an unarmed FIA soldier
  10. Added: Zen_ConfigGetLocations now has a parameter for location type
  11. Added: Zen_ConfigGetVehicleClasses now has a parameter for filtering by DLC
  12. Improved: Zen_ConfigGetTowns renamed to Zen_ConfigGetLocations
  13. Improved: Zen_FindGroundPosition failure logic massively optimized when water or road preference is not possible
  14. Improved: Zen_FindGroundPosition now prints an error when the return position is off the map
  15. Improved: Zen_FindGroundPosition optimized significantly in difficult situations by scaling the number of attempts
  16. Improved: Zen_GiveLoadoutBlufor, Zen_GiveLoadoutIndfor, Zen_GiveLoadoutOpfor now detect day/night more accurately for unassigning NVGs
  17. Improved: Zen_GiveLoadoutCustom now removes NVG's during the day, but leaves them in inventory
  18. Improved: Zen_IsPointInPoly optimized significantly when the point is near the center
  19. Improved: Zen_SetAISkill now reduces the accuracy value at night
  20. Improved: Zen_OrderInsertion and Zen_OrderExtraction now allow the crew to move freely after insertion/extraction
  21. Improved: Zen_OrderVehicleMove logic for stopping the thread and vehicle, including a check for beached boats
  22. Documentation: Fixed Assault Frini sample mission did not give repack magazines action correctly to JIP clients
  23. Documentation: Fixed SQF Overview file explanation of threads and optimization
  24. Documentation: Added for Zen_IsForestArea
  25. Documentation: Improved for Zen_AreInArea, Zen_AreNotInArea, Zen_AvoidPosition, Zen_GetAllInArea
  26. Documentation: Updated for Zen_ConfigGetVehicleClasses, Zen_SetAISkill
  27. Documentation: Updated Random Battle demonstration explanation of Zen_ConfigGetVehicleClasses

Roadmap

Looking to next week, the functions meant to accompany Zen_IsForestArea are planned. I hesitate to say it is certain, so I'll just say it's inevitable that they get done eventually. Also I plan on another new function: Zen_GetAllInBuilding, which will do what you think.

I am also going to continue optimizing Zen_FindGroundPosition, with changes to some of the smaller functions it uses and more screening for impossible situations. As stated in the changelog section, Zen_OrderInsertion will improve so that it always works when the crew are inserting themselves.

Although the roadmap looks pitiful this week, most of the changes come along serendipitously during testing and development. Do not fear that I will run out of things to add, change, and improve.

Function Spotlight

As users of my framework know, there are 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 found useful, PM me and I can spotlight it.

The function chosen for this week is: Zen_AveragePositions. This function will return the 2d average of all the objects, positions, groups, and markers that you give it. It is ideal for situations when you need to find a good compromise positions, such as a supply drop to a group of player spread out across an area.

Its most impressive feature is that it accepts an effectively infinite number of arguments. You can collect an array of objects any way you want, then find their center with one line. Here is an example:

_townCenter = (nearestObjects [getMarkerPos "mkTown", ["house"], 100]) call Zen_AveragePositions;

This will return the center position of the town by averaging all of the houses. You can also make use of other framework functions to get the objects or positions:

_unitsCenter = (["mkTown"] call Zen_GetAllInArea) call Zen_AveragePositions;
_unitsCenter = ([east] call Zen_ConvertToObjectArray) call Zen_AveragePositions;

The first one will get the center position of all the units in the town, and the second will give the average of all Opfor units in the mission.

Now, what might you do with such a center position? You can use it to make your code react to the distribution of objects in an area. You could use fire support in the area of town near the Opfor, or call for an insertion of players to an LZ away from Opfor patrols. If you want to see how close the average is to all the units, try using Zen_FindMaxDistance and Zen_FindMinDistance.

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).

Feedback

As expected, 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.

The specific request this week is: randomization. I would like to hear how you randomize and create replayability in your missions and scripts. This is one of the primary features and goals of the framework, and one of the things that really separates it from the editor. Thus, I am interested in how you are using random positions and random spawning to keep things interesting.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for informing us about the updated release again :cool:

Release frontpaged on the Armaholic homepage.

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

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!

Share this post


Link to post
Share on other sites

Thanks a lot fro the update bro!! This "Zen_AveragePositions" is some good stuff. Zen is your Infantry Occupy House Script already integrated into Zen Framework?

Edited by chondo999

Share this post


Link to post
Share on other sites

Not sure what I'm doing wrong but in all of your sample missions that I try, I get the following error in the HINT area of the screen:

"-- Zen_FindGroundPosition Error -- No valid position possible, water preference impossible, 8.558 [[0,0,0],0.28702,20,[],1,1,10,0,360,0,0,0,0,0,0,0(etc...)

This specific error is from the StealTheCar sample mission. I have seen similar in every mission I try though. All I did for testing the StealTheCar mission is to copy the Zen_frameworkFunctions folder into the mission folder and then PREVIEW from the editor.

Any ideas?

Share this post


Link to post
Share on other sites
Not sure what I'm doing wrong but in all of your sample missions that I try, I get the following error in the HINT area of the screen:

"-- Zen_FindGroundPosition Error -- No valid position possible, water preference impossible, 8.558 [[0,0,0],0.28702,20,[],1,1,10,0,360,0,0,0,0,0,0,0(etc...)

This specific error is from the StealTheCar sample mission. I have seen similar in every mission I try though. All I did for testing the StealTheCar mission is to copy the Zen_frameworkFunctions folder into the mission folder and then PREVIEW from the editor.

Any ideas?

This is a bug that made it into the release version. It is not any issue with any mission (although StealTheCar has a typo of an extra ']' on line 76 of the init.sqf) but with Zen_FindGroundPosition. Due to the severity of this issue, a hotfix version has been released. Just download the latest version from the Google Drive mirror. Sorry for any trouble, I should have tested everything better.

Share this post


Link to post
Share on other sites
This is a bug that made it into the release version. It is not any issue with any mission (although StealTheCar has a typo of an extra ']' on line 76 of the init.sqf) but with Zen_FindGroundPosition. Due to the severity of this issue, a hotfix version has been released. Just download the latest version from the Google Drive mirror. Sorry for any trouble, I should have tested everything better.

Thank you sir!

Share this post


Link to post
Share on other sites

I am a mission making newbie, done a lot of playing round in the editor, and a lot of VAS configuration, but never any scripting. I am going through all of the tutorials now.

I want to make an insurgency style mission (clear the grids, turn red squares green etc). I am thinking of using EOS (http://forums.bistudio.com/showthread.php?153100-Enemy-occupation-system-(eos)) to handle spawning of insurgents, grid marking and clearing. I want to use The Zen framework to handle side objectives, random start positions, and other such things.

Does this approach seem viable? Any advice would be welcome.

Share this post


Link to post
Share on other sites

EOS has not been updated in awhile. I and a few other people have been having problems with AI behavior when using EOS. Zen Framework can do everything EOS does, so there is no need to use EOS b/c it is just not as capable nor extensive as Zen. For insurgency, the only thing you would mention EOS for would be the red markers that indicate a grid zone still has enemy in it. Zen can be configured to do just that, though, I do not know how to do it myself. EOS also has the bastion spawn system, which can be created through Zen. Point is ,use the more current and updated spawning system, Zen, to get the best result. Just ask specifically what you want to accomplish b/c what you stated above is already in the tutorials.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×