module SPAWN GROUP - Advanced Module

[pierremgi 4904]

Hi all,

Here is a new module in MGI Advanced Module addon, for spawning any groups you want, any time... (done)

This module allows:

- to spawn any group, even customized, on any side,

- spawning on multiple possible areas (triggers)

- with a wide randomized choice  or a very specific group.

 

You can place several modules on the map, each of them have their own parameters;

1. Choose the side (applies to all groups spawned from a module, no matter the initial vanilla side). So civilian units can be aggressors.

2. decide if you want to spawn:

    * at total random (so the groups are picked in cfgGroups, but for the side you chose (normal limitation)

    * at randomized or specific faction(s)  . They must exist in cfgGroups (not all factions from cfgFactionClasses are available for groups). All factions (cfgGroups) are available so not depending, here, on the final side

    * You can filter these first possibilities by the type(s) of groups. For example, "infantry" and/or "motorized" and/or "armored"... But, these types must exist in the cfgGroups.

    * you can choose to spawn a specific group (from cfgGroups).. or even an array of units, vehicles... or even an edited group (with all customized textures, pylons, loadouts...)

    * linked group(s) on module, customized or not, will be candidates for spawning. That's fine for spawning not existing groups such as air or sea patrols.

3. Choose the attitude: behavior, combat mode, formation...

4. choose the repeat sequence (limitation and delay)

5. decide on what condition groups module can spawn (not only at start, but any time!)

6. decide for a simple task (or not). Chase players, enemies, defend...

7. run a code for each group  (useful for specific task)

 

 

MODULE(S) IN 3DEN - Position/ area of the module(s) if no synced trigger area. Direction of the module, in 3den, is the direction of the group (if no synced trigger area)

SYNCED TRIGGER AREA(S) - The position, area and direction of the module doesn't matter any more. The group(s) are spawning at randomized positions in randomized trigger area(s), with the direction of the trigger area.

SYNCED UNIT(S) - In 3den, you can place (customized or not) group(s) with the module(s). No matter if you synced one (leader or not) or several units of a group, with the module. The group will be candidate for spawning.

 

 

PARAMETERS

SIDE - Definitely the side of your group(s) for this module.
No matter the choice you did (edited group, chosen faction(s), or type(s) of group or group(s)..) What ever you spawn we belong to this side.
--> But, if you let the module at full random (no synced group, no, faction, no type, no group), in this case, the randomized group is picked among the native possibility from cfgGroups.

So, if you just select a side (say EAST), you'll spawn randomized groups(s) from OPFOR.

 

HOW MANY GROUPS - The number of group(s) to be spawned at each occurrence. Randomization will depend on the possibility of what you want to spawn, so your choice)
Min 1 max 12 (limited for performance saving when spawning heavy customized groups. Feel free to add other modules)

 

NOTE: The modules works with edited groups or existing configs/classes of groups in cfgGroups (see config viewer from console).

So, scripted groups have always the architecture:

                    configFile >> "cfgGroups" >> "side" >> "faction"* >> "type of group" >> "group"  ... then units/vehicles for each group

Example: side like "Indep" , faction like "IND_E_F", type like "infantry",  group like "I_E_InfSquad"

 

FACTION(S)* - If empty, no filter about them. If filled without any more details (type(s), group(s) )  all available factions in cfgGroups can be used to spawn any child type, then any child group.

But ⚠️ all current faction names can't work. Some existing factions in cfgFactionClasses are not present in cfgGroups. For example: "CIV_IDAP_F" (IDAP civilian faction has no group) or even "OPF_V_F" (Arma Viper) can't work in the architecture of cfgGroups. (for Viper, the only group defined in: configfile >> "CfgGroups" >> "East" >> "OPF_F"  >> "SpecOps" >> "OI_ViperTeam" exits. So at faction level, there is nothing to do).

You can fill the parameter with a working class like: "OPF_F" , or the config (configfile >> "CfgGroups" >> "East" >> "OPF_F"), or an array of these possibilities. Not case sensitive.

 

TYPE(S) - if more a filter about what you want to spawn. That should be simple as "infantry" or " motorized or mechanized" or "armored". That doesn't. Even in Arma vanilla, you can find exotic classes as "motorized_MTP". Any dev has his own mind to sort the groups by types. The reason is probably the way you can find sorted groups in 3den's right panel. But, it's just impossible (or needs an updated list of hundreds of names) to filter groups easily. You have to do that job, if you want to do so, writing a config or a class or an array of that, for filtering the type(s). Not case sensitive but do not make typo's error! If wrong, there is no more filter.

You can fill the parameter with a working class (not the config) like: "specops", or an array of these possibilities.
 

Spoiler

 

Check each of them in cfgGroups, like this example :

configfile >> "CfgGroups" >> "East" >> "OPF_F" >> "SpecOps" // OK

configfile >> "CfgGroups" >> "East" >> "OPF_G_F" >> "SpecOps"  // doesn't exist . So, no filter as result.

 

 

SPECIFIC GROUP(S) - a step more for less randomization. You are at the group level. As factions, you can fill it with class (of group) or config or an array of these possibilities.

Much more, you can add arrays of units/vehicles class(es). That's also a way to customize some groups, but one the contrary of synced edited ones, you'll not able to define appearance for vehicles or pylons payload at this moment.

 

RADIUS AREA - radius of the module area, so the spawn area if no synced trigger areas. Useless if any trigger area synced.

 

GROUP(S) DIRECTION - orientation of the module in 3den (shift mousse drag) . Do not write anything on field (it's a result, not an entry). Useless if any trigger area synced.

 

GROUP(S) SKILL - As 3den, skill for whole group, with +/-10% randomized on each units.

 

ENABLE DYNAMIC SIMULATION - As in 3den. See Biki for detailed explanation (recommended)

 

CONDITION FIELD - checked every 2 seconds. So, much more convenient than a simple condition of presence at start! Feel free to do what you want but return a boolean.

Examples:

   * spawning only at night :  sunOrMoon < 0.5

   * strengthening weakened side :   INDEPENDENT countSide allGroups < 3 

   * waiting for more players :     count allPlayers > 2

   * even checking for 1000 m distance at least from any player:

   private _possAreas =  _logic getVariable "possAreas"; (count allPlayers > 0 && allPlayers findIf {private _plyr = _x;  _possAreas findIf  {_plyr distance _x#0 < 1000} == -1} == -1)

but that will not despawn or hide or disable the groups! See the dynamic simulation instead.

 

REPEAT OCCURRENCE - the added times for re-spawning the same groups (not at the same place) . 0 means no more occurrence. -1 means infinite repeat.

So if you want to spawn 3 times a group, set it to 2 (1 shot  + 2 added)

 

INTERVAL FOR REPEAT - A delay between 2 consecutive spawns , if the condition are met. If not, the spawn will wait for condition to be TRUE, then spawn, then wait for interval duration, then check for condition...

min 30 sec max 2 hours.

 

FORMATION OF THE GROUP - As usual. Sometimes this setting is reinitialized to default wedge. I didn't identify why. So check twice before OK button and save scenario.

 

BEHAVIOR - (or behaviour, sorry) Same as usual

 

COMBAT MODE - same as usual

 

SPEED MODE - As usual. same little problem as formation. Check twice.

 

INSIGNIA - I hope that works fine everywhere...

 

CODE FOR GROUP - Blank of any code (without {}). Passes parameters are <group> <<leader>,  <vehicles of the group> . For example, just write:

params ["_grp","_lead","_vehs"];  private _wp = _grp addWaypoint [<aPosition>,0]; _wp setWaypointType "MOVE"; _lead forceFlagTexture "\A3\Data_F\Flags\Flag_red_CO.paa"; {_x setFuel 0.2} forEach _vehs

 

No bracket, just like this.

 

BASIC TASK -  can be:

   * Do Nothing (the preferred one of dumb AIs)

   * Attack nearest known enemy. So the group will start after an enemy knowledge acquisition. Not before. I hope I managed air assets for chasing air assets... I can't imagine infantry running after a jet.

   * Chase nearest enemy. Same as above but the position of nearest enemy is known (for spawning attack waves for example)

   * Attack nearest Player (known enemy) . The group must acquire the detection of a hostile player.

   * Chase nearest player (enemy). The group will start the hunting on player's (updated) position.

   * Defend this area. some SAD waypoints in the area of the group(s).

 

known difficulties

- Mods like Unsung or CUP or RHS (all in fact) requires a sharp attention for the name of the factions/groups but also Types... of groups. You can't imagine hundreds of names for stupid things like "infantry" "armored" "mechanized" ... That should be normalized, but not!

- Too many mods, even non used by mission, but just loaded on server (so ticked), will affect the randomization for nuts, and lead to unwanted results like Arma or CUP units during Unsung play.

 

know bugs

all corrected so far

 

To do list:

- respawn without delay on whole group death

- add a filter for mods... A lot of work.

 

Enjoy!

All feedback welcome.

 

[RELEASED]

 

 

 

[zagor64bz 1225]

WOW..this sounds interesting and very useful...Thank you for the hard work, mate!

[Play3r 147]

Waiting with joy..

[pierremgi 4904]

Should be released soon now: (done)

 

 

The 2 cent question:

Why should I use this module instead of placing my own groups in 3den ?

- In Arma, all presence conditions are checked at start. You can add triggers for enabling simulation and visibility and/ or for spawning/despawning groups but that demands some good knowledge...

- for example, if you randomize a little bit the position, or if you are using the basic BIS_fnc_spawnGroup, you'll experience some weird results. Example: try to spawn a tank platoon in town.

- you can also randomize on multiple areas;

- it's far easier to add conditions like spawning at night only (sunOrMoon < 0.5) or when a side is weakened, or what ever reason you want.

- just follow the video.

 

The other 2 cent question:

Why didn't you share a script instead of publishing a module, and why not a stand-alone module?

There are too many functions and sub-functions to share that in scripts. If you are using just one module, as for BI ones, you will not run all functions but only those which are necessary. So, full mod with all modules, and tiny mod with one module is same in game.

 

See you soon with updated mod.

 

[pierremgi 4904]

Released now. Thanks for feedback.

https://steamcommunity.com/sharedfiles/filedetails/?id=1682280809

 

[pierremgi 4904]

Added the notice in front page. That should be clearer.

[MrStregatto 31]

Hey I know that maybe is not the best way to ask, but the condition field you wrote this code for spawn units when players are near : 

Quote

 private _possAreas =  _logic getVariable "possAreas"; (count allPlayers > 0 && allPlayers findIf {private _plyr = _x;  _possAreas findIf  {_plyr distance _x#0 < 1000} == -1} == -1)

Is there a way to modify to let spawn units when a Blufor/Redfor/Greenfor ai unit is near the trigger?

I want to thank you for your modules, that are a must for me and my friends!

[pierremgi 4904]

Here _possAreas are the synced trigger(s) to the module (logic). Or the module area itself if any trigger.

You can have several modules, then several arrays of areas.

In the code above, the condition is waiting for at least one player (count allPlayers >0) and I suggest you to keep this part, even if not mandatory for the second part you want to change:

allPlayers findIf {private _plyr = _x;  _possAreas findIf  {_plyr distance _x#0 < 1000} == -1} == -1

you can replace allplayers by allUnits  but be sure this array can be huge compared with players one. (this array comprises all units, players, of any side, in vehicles or not).

So, try to reduce it by any means allUnits select {side _x == west}  as example.

something like:

(allUnits select {side _x in [WEST,EAST]}) findIf {private _plyr = _x;  _possAreas findIf  {_plyr distance2D _x#0 < 1000} == -1} == -1

Note: i used distance2D here for quicker evaluation. You can use distanceSqr as well (< 1000000).

 

There are also different solutions, disregarding the proximity of these areas (the condition can be heavy), but similar for your aim :

a simple :  EAST countSide allUnits > 20  could be fine. Or even:  time > 1200  for delaying the first spawn. The complexity, so the resource consuming is on your side.

[MrStregatto 31]

Thanks for the answer!
And thanks for your modules, that are a must have for me and my friends

[pierremgi 4904]

This module is now compatible with DLC S.O.G. Prairie fire. (and probably all further DLCs)

Have fun!

[pierremgi 4904]

Answer to 7r3v0r  (question on youtube)

 

if I set this to 1 group and repeat every 5 minutes, will it spawn a second group or wait until the first is dead? if it does spawn a second group is there any way to set a hard cap on how many it can have spawned at once?

 

The repeat timer is a timer running at each spawn. So relative to the last succeeded spawn.

On the other hand, you have also a condition code adding extra conditions, so you can postpone the next spawn. In your case, you could:

- add a code for group(s) in module:

(_this#0) setVariable ["newRedSpawn",TRUE]

- then add a condition in condition field:

allgroups  select {_x getVariable ["newRedSpawn",false]} isEqualTo []

 

How does that works?

Your first group(s) will spawn and a variable "newRedSpawn" (or else at your hand) will be set on them (groups for this module only)

When the units die, the group(s) is/are emptied (so, by default be deleted after a minute without units). The condition is false until all groups set with this variable are killed.

Then your timer applies (you can set it at 30 sec. min).

If you need more immediate result for wiped out units (instead of groups) you can code something to count units... but it's an "heavier" condition for your engine.

 

 

 

 

[Soapbox0331 17]

 @pierremgi, your mods make mission making so much more enjoyable for me, thanks for these!

 

I have a couple of questions on this module:

 

1) I am creating a battle that lasts overnight (timed) with module Repeat occurrence set to -1.  I would like to stop the AI from spawning from the module at the end of the fight. Deleting the module does not stop spawning. Can it be turned off after a certain amount of time or condition met?

 

2) Concerning the Group skill levels: my friends prefer firefights that are high volume of fire and low accuracy, so I usually have setSkill spotdistance higher and setSkill aimingaccuracy lower, using script called in unit init. Can skill levels be modified like this in the module?

[pierremgi 4904]

1) yes, you can write any condition you want. This condition is checked before each spawn. The basic is to set up finite amount of occurrences (say 10) along with time between two occurrences (interval, say 20 min). You can also initialize a counter for spawned units (say MYCOUNTER = 0 in initServer.sqf) then use the code for groups on module (the first parameter passed is the group. So, something like MYCOUNTER = MYCOUNTER + (count units (_this #0)); should work. Add the condition MYCOUNTER < 100 in condition field (this amount is approx. if you randomize the groups).

 

2) you can also set the skill on module. If the standard group skill cursor is not enough, just write what you want , in code field again:
something like: {_x setSkill ["spotDistance",0.8 + random 0.2]; _x setSkill ["aimingAccuracy", random 0.3]} count units (_this #0)

[panther42 52]

@pierremgi good stuff here.  Have not tested completely, but any chance you could change the module to pull Faction, Type, and Specific Group from drop down via reading the config itself?

I've done some testing on this myself, and seems doable, but didn't know if you've tried this, and ran into issues.

[pierremgi 4904]

2 hours ago, panther42 said:

@pierremgi good stuff here.  Have not tested completely, but any chance you could change the module to pull Faction, Type, and Specific Group from drop down via reading the config itself?

I've done some testing on this myself, and seems doable, but didn't know if you've tried this, and ran into issues.

 

Useless as far as you can copy paste what you want from config viewer cfgGroups.

You're not allowed to modify part of any module from MGI advanced Modules.

[panther42 52]

1 hour ago, pierremgi said:

Useless as far as you can copy paste what you want from config viewer cfgGroups.

You're not allowed to modify part of any module from MGI advanced Modules.

@pierremgi I'm not sure you understood what I asked.  I'm not looking to modify your Modules.

It was a suggested request/improvement for you.  Save time for user.

Side>>Faction>>(Infantry/Motorized/Mechanized/etc.)>>Group

Pulled from config, instead of user verifying correct config and typing/copying.  Your module could provide the available options in drop downs.

 

For instance, let me give you an example of some output from a script I was messing with:

Spoiler

[["CUP_O_TK",
["Motorized",["CUP_O_TK_MotorizedReconSection","CUP_O_TK_MotorizedPatrol"]],
["Mechanized",["CUP_O_TK_MechanizedInfantrySquadBMP2","CUP_O_TK_MechanizedInfantrySquadBTR60","CUP_O_TK_MechanizedSpecialSquad","CUP_O_TK_MechanizedReconSection","CUP_O_TK_MechanizedReconSectionAT"]],
["Armored",["CUP_O_TK_T72Platoon","CUP_O_TK_T55Platoon","CUP_O_TK_T34Platoon"]],["Air",["CUP_O_TK_Mi24_DFlight","CUP_O_TK_Mi_17Flight","CUP_O_TK_Su25Flight","CUP_O_TK_UH1HFlight"]],
["Infantry",["CUP_O_TK_InfantrySquad","CUP_O_TK_InfantrySection","CUP_O_TK_InfantrySectionAT","CUP_O_TK_InfantrySectionAA","CUP_O_TK_InfantrySectionMG","CUP_O_TK_SniperTeam","CUP_O_TK_SpecialPurposeSquad"]]],
["CUP_O_TK_MILITIA",
["Motorized",["CUP_O_TK_MILITIA_Technicals","CUP_O_TK_MILITIA_MotorizedGroup","CUP_O_TK_MILITIA_MotorizedPatrolBTR40"]],
["Infantry",["CUP_O_TK_MILITIA_Group","CUP_O_TK_MILITIA_Patrol","CUP_O_TK_MILITIA_AATeam","CUP_O_TK_MILITIA_ATTeam","CUP_O_TK_MILITIA_Demosquad"]]]]

OR

[["CUP_O_TK-Motorized",["CUP_O_TK_MotorizedReconSection","CUP_O_TK_MotorizedPatrol"]],
["CUP_O_TK-Mechanized",["CUP_O_TK_MechanizedInfantrySquadBMP2","CUP_O_TK_MechanizedInfantrySquadBTR60","CUP_O_TK_MechanizedSpecialSquad","CUP_O_TK_MechanizedReconSection","CUP_O_TK_MechanizedReconSectionAT"]],
["CUP_O_TK-Armored",["CUP_O_TK_T72Platoon","CUP_O_TK_T55Platoon","CUP_O_TK_T34Platoon"]],
["CUP_O_TK-Air",["CUP_O_TK_Mi24_DFlight","CUP_O_TK_Mi_17Flight","CUP_O_TK_Su25Flight","CUP_O_TK_UH1HFlight"]],
["CUP_O_TK-Infantry",["CUP_O_TK_InfantrySquad","CUP_O_TK_InfantrySection","CUP_O_TK_InfantrySectionAT","CUP_O_TK_InfantrySectionAA","CUP_O_TK_InfantrySectionMG","CUP_O_TK_SniperTeam","CUP_O_TK_SpecialPurposeSquad"]],
["CUP_O_TK_MILITIA-Motorized",["CUP_O_TK_MILITIA_Technicals","CUP_O_TK_MILITIA_MotorizedGroup","CUP_O_TK_MILITIA_MotorizedPatrolBTR40"]],
["CUP_O_TK_MILITIA-Infantry",["CUP_O_TK_MILITIA_Group","CUP_O_TK_MILITIA_Patrol","CUP_O_TK_MILITIA_AATeam","CUP_O_TK_MILITIA_ATTeam","CUP_O_TK_MILITIA_Demosquad"]]]

 

Or, better yet, @gc8 has this type of info populated in one of his projects.  Should not be very difficult to implement.

Just a suggestion, as I know each author has their own reasons for why they do things as they do.

[pierremgi 4904]

1 hour ago, panther42 said:

Just a suggestion, as I know each author has their own reasons for why they do things as they do.

 

Yes.