So BCRs are limited to the starting group number and are the units that parachute in at the HQ. So what effect does setting the force pool to dynamic have? Would the BCRs not just replace killed units up to the levels of 100 and 400 respectively and keep them there until the pools run out? Perhaps I've missed something here, but I don't see what difference the number of objectives held by either side would make if they are spawned at the HQ up to the predefined level. Wouldn't this mean the Blufor always get reinforced up to 100 and Opfor to 400?

I was assuming that the sizes were individual units, so a company (100) would be 100 men or roughly 10 infantry squads. I would have thought that these would run out pretty quickly, as if only one squad is left at each objective you'd only have 50 mobile units left to attack once 5 objectives have been taken.

In invasion mode does every objective get defenders assigned, or is it only the most forward objectives?

Oh I know ALiVE is heavily randomised, it's what attracted me to it in the first place.
My original hope for OFP was for it to have a Falcon 4.0 style dynamic campaign, and ALiVE is the closest thing to replicating that.

What I'm wondering is this.

I know a specific answer is not possible really because it wouldn't work exactly like this, but as a hypothetical I'd like to know how this would play out:
Two squads with an Invasion commander assault an objective and take it. The commander assigns one group to garrison the objective as defenders.
Will a third squad be spawned to join with the mobile squad to form another two-group unit to attack further objectives, or would there now be only one squad available to attack?
Or do the two squads retain their attacking role and a third is spawned to act as defenders for the taken objective?

If I have an Opfor Occupation force of 400 spread over a third of Altis and a Blufor invasion force of 100 spawned only in one small area with a single objective, will the invasion force be able to progressively capture territory as long as reinforcements keep coming, or will they stop attacking as soon as they've captured the amount of territory that the force of 100 can hold, with replacements only coming in for dead units, retaining the overall size of 100?

I know these might seem like vague questions, but I'm trying to get a feel for how I can guide the progression of a scenario. I'm wanting there to be a long-running battle with Blufor slowly taking territory piece by piece. I'm trying to create a main effort that players can contribute to in whatever way they wish and I need to work out how to balance unit sizes and composition in order to achieve this without it either ending in a quick decisive battle, or fizzling out into stalemate.

How is the force balancing best set up when running Invasion vs Occupation AI Commanders?
I have Blufor starting in a single custom objective at the southern tip of Stratis set to Invasion. Opfor are set to Occupation and have 90% of the island.
What I'm struggling with is how to set it up so that Blufor slowly push north. If they start with 100 units does this means that they'll take over the southern sections with the full strength of 100 units and slowly leave more and more behind, until they get to the point where they've spread the whole 100 over the taken objectives and then run out of steam?
What I'd ideally like is for two infantry squads and a mechanized squad to assault enemy objectives, and for garrison units to spawn in behind to hold it while those three squads move on to the next one.

If Blufor capture an objective within Opfor's TAOR will Blufor units then begin to spawn within it? Or do Opfor units just stop spawning there until they retake it?

I don't really want a situation where Blufor steamroll over Opfor in the south, but eventually both sides reach stalemate in the middle as the unit numbers actively fighting reach parity. I'm looking for a situation where Blufor have a very slight advantage at all points and player intervention is needed to push the fight forward.

Ok, update on this. I've got it working, confirmed on a server as well.

The ALIVE_autoGeneratedTasks parameter is very picky about what it will accept, after a fair bit of messing around I managed to write a script that will set the parameter to a random mission type from a list:

task = ["Assassination", "Sabotage", "MilAssault", "DestroyVehicles", "DestroyInfantry"] call BIS_fnc_selectRandom; // Selects mission from types in array.
ALIVE_autoGeneratedTasks = [task]; // Sets the ALiVE task to the one selected in the last line.

This does have a limitation; it doesn't reselect the mission type until you run the script again so you have to make provisions to run the script regularly or you will get a random selection the first time and then you'll get the same type every time.

To check the currently selected type, you can add this line to the end of the script so it shows up when a mission is selected, and you can also set it on a radio trigger to debug:

 hintSilent str ALIVE_autoGeneratedTasks; 

To actually incorporate this into my missions I set up two radio triggers linking to scripts, one to activate a mission and another to set the mission type to blank:

Random Task.sqf

task = ["Assassination", "Sabotage", "MilAssault", "DestroyVehicles", "DestroyInfantry"] call BIS_fnc_selectRandom; //returns one of the variables
ALIVE_autoGeneratedTasks = [task];
PAPABEAR = [West,"HQ"]; PAPABEAR sideChat "Confirmed. Unit is available for immediate tasking.";
// hintSilent str ALIVE_autoGeneratedTasks; // Debug. Lists selected mission as hint.
Sleep 120; 
ALIVE_autoGeneratedTasks = [""];
PAPABEAR = [West,"HQ"]; PAPABEAR sideChat "Confirmed. Unit is unavailable for tasking at this time.";

The "Sleep" in this followed by ALIVE_autoGeneratedTasks = [""]; means that the mission type will be selected but will revert to blank after two minutes. This means that if you do not get a mission quickly you will be informed and can activate the trigger again to get another type, and it also means that by the time a mission is completed you will not get another until you activate the trigger again. The chat messages are there to inform you that this has happened so you don't lose track of what's going on.

No Task.sqf

ALIVE_autoGeneratedTasks = [""];
PAPABEAR = [West,"HQ"]; PAPABEAR sideChat "Confirmed. Unit is unavailable for tasking at this time.";

This one allows you to manually set the mission type to blank, and can be used on a "present" trigger at a spawn point to prevent players from getting missions before they have requested them.

Running these scripts in a loop would work fine, I'm sure. It just turns out that this setup is exactly what I need for my application of it.

I've used the "waituntil {!isnil "ALIVE_autoGeneratedTasks"};" before and it makes no difference in the script I posted above, and it isn't necessary if you're using single triggers.
I'll try the one you just posted to see if that helps, as I'd rather have a random selection than being forced to select one each time.
I've noticed that assassination and sabotage are generated instantly when selected, whereas the others are dependent on the area you are in and will only generate if suitable enemy units are within a decent range.

OK, I've been busy with work for a few days, but I think I have it worked out now.
The only way the auto-tasks can be modified in multiplayer is with single selections, so ALIVE_autoGeneratedTasks = ["Assassination"]; will work, but ALIVE_autoGeneratedTasks = ["Assassination","SabotageBuilding","DestroyVehicles"] will not.

Setting this in the init.sqf also fails to work, you have to activate it once the mission is loaded. Doing so with a trigger works, and presumably a script will work as well.
I have my missions set up with this on radio triggers, so I set the task type by that. It works fairly well with my scenario, but might not with others.

I think the best way to get selectable but randomised tasks would be to have a loop script activated on a trigger that only requests one type at a time and cycles through the list you want available.
If it changed task every 15 seconds you'd get a perfect representation of random tasks, as the "current" task would change every 15s and you will only be sent a task when you do not have one active, giving the illusion of random selection.

I'd do this but I have no idea how I'd make a script to loop like that. The rough layout would need to be:

1. Select task type 1
2. Sleep 15
3. Select task type 2
4. Sleep 15
5. Etc
6. Loop to start

As I say, I think that'll work, I just don't know how to write it.

@SpyderBlack723 : Thanks for that, on further testing the method I detailed above isn't working either, so I'm testing with single triggers for a moment to narrow down what the problem is.

OK, I've found a way to make it work and I've found why it wasn't working before.
The line **ALIVE_autoGeneratedTasks = ["Assassination","SabotageBuilding"];** does not make the autogen system choose between those two missions every time it assigns. It selects one of those two options and will then assign that mission every time.
It will not work in multiplayer if set in the init.sqf. It will work if it is set in-game by a trigger.
To make it randomly select a mission every time you will need to repeatedly activate the trigger over and over again, causing it to reselect between the options everytime the trigger activates.
To do this I have set a full map trigger that detects BLUFOR and then runs a script with the missions I want to be chosen between, it's much easier with a script for reasons I'll detail in a moment.

First you need a script, I've put it in the mission folder and named it "tasks.sqf", it contains the following code:
**
waituntil {!isnil "ALIVE_autoGeneratedTasks"};
ALIVE_autoGeneratedTasks = ["Assassination","SabotageBuilding","DestroyVehicles","MilAssault","DestroyInfantry"];
Sleep 300;
triggervariable = false;
**

In the init.sqf I've added the following line:

**
triggervariable = true;
**

In the editor I've placed a trigger with 20k radius set for detect BLUFOR repeatedly, with the following additions:
CONDITION: this AND triggervariable
ON ACT: null = execVM "tasks.sqf";
ON DEA: triggervariable = true;
COUNTDOWN/TIMEOUT must be set to zero, if they have a value then the trigger will not reactivate without leaving the trigger area.

This method allows for the trigger to reactivate every 5mins while BLUFOR are present in it, meaning that every 5mins ALiVE will set the mission generation to one of the options listed in the script.
In practice this means that every time you get a mission it will be randomly selected from those options, you can set the sleep time to whatever you like, but if you complete the assigned mission within the sleep period you will receive the same type of mission again.
The reason for using a script for this is that it is easier to make a trigger that repeatedly activates when BLUFOR are present in it, otherwise you'd need to leave and re-enter the trigger area to make the mission reselect. This would be awkward as you've have to set it in an area that would be entered and vacated frequently.

To debug this system you can add the line **Hint "Triggered";** to the tasks.sqf before the sleep line, and add **hint "";** to the ON DEA line of the trigger. You will then see a hint saying "Triggered" lasting for 5mins, after which it will delete and refresh.
Set the sleep time to something very low for this if you wish to see the triggering intensify. You'll want to set it to 5s to be able to observe it working without having to stare at the screen all day.
Once you're happy it works set the sleep to 300 (or whatever you want) and delete the hints for normal use.

I hope this is of use to anybody who is having the issue that I was struggling with.

After further testing, it seems that the task options work fine in singleplayer, but in multiplayer they will ignore the setting and send any random task, including ones not added to the list.
So essentially the selection function does not work in MP.

@SpyderBlack723 : I might have to, the code you posted the other day is 100% not working, I just got one of the other disabled tasks as well, so it's not just CivAssault.