[EMS] 0.3.1 Defents Edit

[ReDBaroN]

The error above was because of Minor SM2 mission.  DZMSAISpawn call didnt assign them to array.  I replaced line 57 of minor SM2 with

 

[[(_coords select 0) + 20, (_coords select 1) + 15,0],4,1,"DZMSUnitsMinor"] call DZMSAISpawn;

 

Now all is fine.

 

@Defent  I really appreciate all the effort you have put into this!!

Superb stuff ssthief. Well spotted.

 

Also, superb stuff Defent! Nice system!

 

Thanks to you both.

[MassBoobage]

We are having an issue and I wish I could say which mission is causing it, but randomly a mission kicks off and we get a 3wheeler.pbo error on the client and infistar goes crazy saying RESTART THE SERVER.  Anyone else getting this problem? There isn't much in the RPT that helps identify the mission causing it.

[mgm]

Thanks ssthief, that line you shared helped me fix my minor mission 2.

 

Sharing below a couple of things I've been working on

 

The code from cen on this forums helped me - now I can sell 2x BTRs from Major Mission #12

//We create the vehicles like normal
_vehicle = createVehicle ["BTR40_MG_TK_INS_EP1",[(_coords select 0) - 10, (_coords select 1) - 10,0],[], 0, "CAN_COLLIDE"];
_vehicle1 = createVehicle ["BTR40_TK_INS_EP1",[(_coords select 0) + 20, (_coords select 1) - 5,0],[], 0, "CAN_COLLIDE"];

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// cen's proposed fix to issue >> "unable to save vehicle to trader because EMS mission vehicles do not get ObjectUID assigned when they spawn"
// http://epochmod.com/forum/index.php?/topic/2611-ems-026-epoch-mission-system/?p=44816
_uniqueid = str(round(random 99999999999999999));
_vehicle setVariable ["ObjectID", _uniqueid, true];
_vehicle setVariable ["ObjectUID", _uniqueid, true];
_vehicle1 setVariable ["ObjectID", _uniqueid, true];
_vehicle1 setVariable ["ObjectUID", _uniqueid, true];
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 

If you're also using Single Currency & Banking system (with CfgTraders) then you'll need this one to make them listed at Hero & Bandit traders:

// add to BanditMilitaryArmed.hpp
// add to HeroMilitaryArmed.hpp

//////////////////////////////////////////////////////////////////
	class BTR40_MG_TK_INS_EP1 {
		type = "trade_any_vehicle";
		buy[] ={200000,"Coins"};
		sell[] ={100000,"Coins"};
	};
	class BTR40_TK_INS_EP1 {
		type = "trade_any_vehicle";
		buy[] ={100000,"Coins"};
		sell[] ={50000,"Coins"};
	};
//////////////////////////////////////////////////////////////////

 

If you want more AI units guarding the missions:

Don't do what I did before (increased number of AI units to 20). they lose their limited IQ capacity and become total idiots.

What seems to work is what ReDBaroN suggested earlier in this thread in post #107 - creating several smaller squads, like this below:

//DZMSAISpawn spawns AI to the mission.
//Usage: [_coords, count, skillLevel]
[[(_coords select 0) - 0.5635,(_coords select 1) + 0.3173,0],3,1,"DZMSUnitsMajor"] call DZMSAISpawn;
[[(_coords select 0) - 0.5635,(_coords select 1) + 0.3173,0],3,1,"DZMSUnitsMajor"] call DZMSAISpawn;
[[(_coords select 0) - 0.5635,(_coords select 1) + 0.3173,0],3,1,"DZMSUnitsMajor"] call DZMSAISpawn;
[[(_coords select 0) - 0.5635,(_coords select 1) + 0.3173,0],3,1,"DZMSUnitsMajor"] call DZMSAISpawn;
[[(_coords select 0) - 0.5635,(_coords select 1) + 0.3173,0],3,1,"DZMSUnitsMajor"] call DZMSAISpawn;
[[(_coords select 0) - 0.5635,(_coords select 1) + 0.3173,0],3,1,"DZMSUnitsMajor"] call DZMSAISpawn;
[[(_coords select 0) - 0.5635,(_coords select 1) + 0.3173,0],3,1,"DZMSUnitsMajor"] call DZMSAISpawn;
sleep 5;

//Wait until the player is within 30meters
[_coords,"DZMSUnitsMajor"] call DZMSWaitMissionComp;

Early testing phase so far, can't say they're very good now but 21 is better than 3. I might reduce it to 10-12 or so later on, I'm not convinced they all receive the proper attention (cpu?) from server as they seem to work in relaxed mode which means, when they are all dead, there will be more loot so at some level adding more enemy makes it easier for looters.

I still need to make them harder somehow if anyone has tips or code on this please share - thanks in advance.

[mgm]

You guys have been great. The missions are going to be awesome now. There wont be any more free loot and lazy AI.

Giving rocket launchers to one guy (last in unit), to all guys in each squad, setting higher skill levels, these are all things I need to try out but if you reached a nicely working combo why not copy & paste.

Do you mind sharing your EMS folder? (assuming you did other changes too), I'll load it onto my test server and see how it is. If you don't want to give away other stuff can you at least post your working spawn script please?

I would like to try out that rocket launcher script you got working nicely.

 

Thanks in advance!

 

I would love to know how to do that.

[Defent]

I'm working on upgrading their skills too btw. Currently they are weak as shit and don't really fire back, at least not on my live and test servers. I'll post here once I get some resulsts.

 

Edit:

 

Ok I managed to fix some of the AI skills, for exampel I did this:

Changed it to 1 instead of 1.00 or 1,00 (note the , & ,) at around DZMSAIConfig.sqf

DZMSSkills3 = [	
["aimingAccuracy",1],
["aimingShake",1],
["aimingSpeed",1],
["endurance",1],
["spotDistance",1],
["spotTime",1],
["courage",1],
["reloadSpeed",1],
["commanding",1],
["general",1]
];

I'll push this to the GitHub as soon as I get my version a bit more stable.
 

[mgm]

I'm working on upgrading their skills too btw. Currently they are weak as shit and don't really fire back, at least not on my live and test servers. I'll post here once I get some resulsts.

 

Edit:

 

Ok I managed to fix some of the AI skills, for exampel I did this:

Changed it to 1 instead of 1.00 or 1,00 (note the , & ,) at around DZMSAIConfig.sqf

DZMSSkills3 = [	
["aimingAccuracy",1],
["aimingShake",1],
["aimingSpeed",1],
["endurance",1],
["spotDistance",1],
["spotTime",1],
["courage",1],
["reloadSpeed",1],
["commanding",1],
["general",1]
];

I'll push this to the GitHub as soon as I get my version a bit more stable.

 

Always nice work Defent, keep it coming! :)

 

 

In follow up of my post #153, I remembered I had the SQL files somewhere to add both BTR mission vehicles to SQL database as trader item. Below it is if anyone needs it - obviously need to adjust your db name and price. This is for Chernarus 11.

-----------------------------------------------------------------------------------------------------------------------------
-- Modify_Trader_Data.AddItem.BTR40_MG_TK_INS_EP1.sql
-- Add custom items to traders
USE dayz_overpoch;
INSERT INTO `traders_data` (`item`,`qty`,`buy`,`sell`,`order`,`tid`,`afile`) VALUES
('["BTR40_MG_TK_INS_EP1",2]', 250, '[2,"ItemBriefcase100oz",1]', '[1,"ItemBriefcase100oz",1]', 0, 562, 'trade_any_vehicle'),
('["BTR40_MG_TK_INS_EP1",2]', 250, '[2,"ItemBriefcase100oz",1]', '[1,"ItemBriefcase100oz",1]', 0, 569, 'trade_any_vehicle');
-----------------------------------------------------------------------------------------------------------------------------



-----------------------------------------------------------------------------------------------------------------------------
-- Modify_Trader_Data.AddItem.BTR40_TK_INS_EP1.sql
-- Add custom items to traders
USE dayz_overpoch;
INSERT INTO `traders_data` (`item`,`qty`,`buy`,`sell`,`order`,`tid`,`afile`) VALUES
('["BTR40_TK_INS_EP1",2]', 250, '[1,"ItemBriefcase100oz",1]', '[5,"ItemGoldBar10oz",1]', 0, 491, 'trade_any_vehicle'),
('["BTR40_TK_INS_EP1",2]', 250, '[1,"ItemBriefcase100oz",1]', '[5,"ItemGoldBar10oz",1]', 0, 598, 'trade_any_vehicle'),
('["BTR40_TK_INS_EP1",2]', 250, '[1,"ItemBriefcase100oz",1]', '[5,"ItemGoldBar10oz",1]', 0, 599, 'trade_any_vehicle'),
('["BTR40_TK_INS_EP1",2]', 250, '[1,"ItemBriefcase100oz",1]', '[5,"ItemGoldBar10oz",1]', 0, 658, 'trade_any_vehicle');
-----------------------------------------------------------------------------------------------------------------------------

 

[ekroemer]

Hi Defent,

 

I'm a bit concerned about the logic you use for spawning crate content, as example the use of DEFMPistolrate:

// load pistols
_scount = count DZMSpistolList;
for "_x" from 0 to DEFMPistolRate do {
  _sSelect = floor(random _sCount);
  _item = DZMSpistolList select _sSelect;
  _crate addWeaponCargoGlobal [_item,DEFMPistolRate];
  _ammo = [] + getArray (configFile >> "cfgWeapons" >> _item >> "magazines");
  if (count _ammo > 0) then {
    _crate addMagazineCargoGlobal [(_ammo select 0),(round(random DEFMPistolAmmoRate))];
  };
};

You are using this (misnamed ;-) Rate

• as loop limit, thus choosing DEFMPistolrate+1 times from the array DZMSpistolList
• and as multiplier: in each iteration DEFMPistolrate pistols of the chosen kind are added.

I can see no reason why one should use the same variable at both places and many against it:

• the way it is, the amount of weapons in the crate will be (DEFMPistolrate+1)*DEFMPistolrate, roughly the square of the number one would expect
• changing Rate from e.g. 3 to 4 will increase weapon count from 12 to 20.

I would change the addWeaponCargoGlobal argument from Rate to 1, thus having exactly Rate+1 pistols in the crate or, more dynamic, do something like

_crate addWeaponCargoGlobal [_item,1+(round(random 1))];

resulting in 1 or 2 pistols per iteration, equivalent to an overall number between Rate+1 and 2*(Rate+1).

[Defent]

That makes sense. I'll look in to changing that. Thanks.

 

The reason why I have it as it is because the numbers set in the orignial settings for the loot (DZMS) uses the same numbers. I.E, where I placed DEFMPistolRate it would say 1 or 2 or what ever. I figured that I could change these with a variable. The point is, I did not really make the loot spawn function, it is migrated from DZMS, but I'll look in to it.

 

I know the current system is unreliable but I'll see what I can do.

 

 

The argument you posted did exist before, however, I removed it because I couldnt add a variable to it so that it could be set in DZMSConfig.sqf.(to my knowledge)

[ReDBaroN]

Hi Defent,

 

I'm a bit concerned about the logic you use for spawning crate content, as example the use of DEFMPistolrate:

// load pistols
_scount = count DZMSpistolList;
for "_x" from 0 to DEFMPistolRate do {
  _sSelect = floor(random _sCount);
  _item = DZMSpistolList select _sSelect;
  _crate addWeaponCargoGlobal [_item,DEFMPistolRate];
  _ammo = [] + getArray (configFile >> "cfgWeapons" >> _item >> "magazines");
  if (count _ammo > 0) then {
    _crate addMagazineCargoGlobal [(_ammo select 0),(round(random DEFMPistolAmmoRate))];
  };
};

You are using this (misnamed ;-) Rate

• as loop limit, thus choosing DEFMPistolrate+1 times from the array DZMSpistolList
• and as multiplier: in each iteration DEFMPistolrate pistols of the chosen kind are added.

I can see no reason why one should use the same variable at both places and many against it:

• the way it is, the amount of weapons in the crate will be (DEFMPistolrate+1)*DEFMPistolrate, roughly the square of the number one would expect
• changing Rate from e.g. 3 to 4 will increase weapon count from 12 to 20.

I would change the addWeaponCargoGlobal argument from Rate to 1, thus having exactly Rate+1 pistols in the crate or, more dynamic, do something like

_crate addWeaponCargoGlobal [_item,1+(round(random 2))];

resulting in 1 or 2 pistols per iteration, equivalent to an overall number between Rate+1 and 2*(Rate+1).

 

 

That makes sense. I'll look in to changing that. Thanks.

 

The reason why I have it as it is because the numbers set in the orignial settings for the loot (DZMS) uses the same numbers. I.E, where I placed DEFMPistolRate it would say 1 or 2 or what ever. I figured that I could change these with a variable. The point is, I did not really make the loot spawn function, it is migrated from DZMS, but I'll look in to it.

 

I know the current system is unreliable but I'll see what I can do.

 

 

The argument you posted did exist before, however, I removed it because I couldnt add a variable to it so that it could be set in DZMSConfig.sqf.(to my knowledge)

Ahh, this makes sense, I was wondering why for some categories I seemed to be getting double the max quantity I was hoping to get...

 

As I am trying to get a random number from 0-2, can you tell me what I change it too?

 

Based on your findings above ekroemer, would I have the DEFMPistolRate still set to 2 and replace that line with yours for each of the boxes?

 

Would that achieve 0-2 rather than the occasional 4 creeping in?

[ekroemer]

@Defent:

 

Yes, I thought as much about your reasoning; I guess you took your clue from the gshellList where both values (loop and count) are set to 2.

Looking at all the others, though, shows that the argument to addWeaponCargoGlobal is always 1, in line with my first suggestion.

Would be the least hassle to do so (for weapons) and still meet your configuration goals.

 

@ReDBaron:

 

What do you want to achieve?

 

Afaik, using

_crate addWeaponCargoGlobal [_item,(round(random 2))];

would give you 0-2 pieces of _item.

 

Ensuring that a crate holds at max 2 pieces of a specified pistol is tricky, because nothing prevents the for _x loop from choosing the same type of pistol in every iteration, so with a very low probability you'll end up with 2*DEFMPistolRate pistols of the same kind.

 

But I think, that's an academic argument, it would be much effort to prevent something only slightly annoying ;-)

The easiest thing to lower the probability of too many pistols of a kind would be to place more classnames in DZMSpistolList.

 

@all: in my original post I erroneously took the round for a floor, so instead of

_crate addWeaponCargoGlobal [_item,1+(round(random 2))];

one should use

_crate addWeaponCargoGlobal [_item,1+(round(random 1))];

to get results within [1, 2].

[ReDBaroN]

I'm working on upgrading their skills too btw. Currently they are weak as shit and don't really fire back, at least not on my live and test servers. I'll post here once I get some resulsts.

 

Edit:

 

Ok I managed to fix some of the AI skills, for exampel I did this:

Changed it to 1 instead of 1.00 or 1,00 (note the , & ,) at around DZMSAIConfig.sqf

DZMSSkills3 = [	
["aimingAccuracy",1],
["aimingShake",1],
["aimingSpeed",1],
["endurance",1],
["spotDistance",1],
["spotTime",1],
["courage",1],
["reloadSpeed",1],
["commanding",1],
["general",1]
];

I'll push this to the GitHub as soon as I get my version a bit more stable.

 

 

 

I seem to manage to get mine to be quite sharp at less than this and without changing to a rounded up number. For my medium / hard missions (Major) I have them set like this:

DZMSSkills0 = [
["aimingAccuracy",0.95],
["aimingShake",0.95],
["aimingSpeed",0.95],
["endurance",1.00],
["spotDistance",1.00],
["spotTime",1.00],
["courage",1.00],
["reloadSpeed",1.00],
["commanding",1.00],
["general",1.00]
];

And for my easier missions but still not totally nerfed (Minor) set like this:

DZMSSkills1 = [
["aimingAccuracy",0.85],
["aimingShake",0.85],
["aimingSpeed",0.85],
["endurance",1.00],
["spotDistance",1.00],
["spotTime",1.00],
["courage",1.00],
["reloadSpeed",1.00],
["commanding",1.00],
["general",1.00]
];

But, the most important factor for me to get their engines revving , which I have changed in both my mission systems, is to change this:

_unit setCombatMode "YELLOW";
_unit setBehaviour "COMBAT";

to this:

_unit setCombatMode "RED";
_unit setBehaviour "STEALTH";

Then, as long as you keep each squad to 4 and multiply the squad spawn lines rather than increasing the spawn number on one line and your server FPS isn't totally on the floor )which I've noticed can leave them jogging on the spot totally nerfed) you should see them behaving more realistically and being a lot sharper.....

[ekroemer]

Is 4 really the magic number, here? (I need to have a look into WAI at the numbers, there).

Does the degradation come with the step from 4 to 5 or gradually?

Is the issue a matter of Arma2 coding or a matter of resources (meaning: is Arma programmed to only handle a limited number of group members or does the communication between too many members bog down the CPU)?

 

Why I'm asking: if 6 or 8 would still be ok, one could keep a significant number of AI without sacrificing the cleanup:

A typical call to create a group would be

[[(_coords select 0),(_coords select 1),0],6,1,"DZMSUnitsMajor"] call DZMSAISpawn;

defining an array DZMSUnitsMajor that is used in DZMSMajTimer.sqf to get rid of the AI remaining at mission end:

{if (alive _x) then {_x call DZMSPurgeObject;};} forEach DZMSUnitsMajor;

When creating more than 1 group we'd need more arrays DZMSMajor or we have to change DZMSAISpawn to append to it (and DZMS*Timer to clear the array after purging).

 

 

Edit: looked into WAI and while mostly the squads consist of 4 members the Ikea convoy one has 5 and I remember it as pretty deadly, so I guess performance will degrade rather than break down at 4.

[ReDBaroN]

@Defent:

 

Yes, I thought as much about your reasoning; I guess you took your clue from the gshellList where both values (loop and count) are set to 2.

Looking at all the others, though, shows that the argument to addWeaponCargoGlobal is always 1, in line with my first suggestion.

Would be the least hassle to do so (for weapons) and still meet your configuration goals.

 

@ReDBaron:

 

What do you want to achieve?

 

Afaik, using

_crate addWeaponCargoGlobal [_item,(round(random 2))];

would give you 0-2 pieces of _item.

 

Ensuring that a crate holds at max 2 pieces of a specified pistol is tricky, because nothing prevents the for _x loop from choosing the same type of pistol in every iteration, so with a very low probability you'll end up with 2*DEFMPistolRate pistols of the same kind.

 

But I think, that's an academic argument, it would be much effort to prevent something only slightly annoying ;-)

The easiest thing to lower the probability of too many pistols of a kind would be to place more classnames in DZMSpistolList.

 

@all: in my original post I erroneously took the round for a floor, so instead of

_crate addWeaponCargoGlobal [_item,1+(round(random 2))];

one should use

_crate addWeaponCargoGlobal [_item,1+(round(random 1))];

to get results within [1, 2].

ekroemer, I have set my major missions to call box type "weapons" and my minor missions to call box type "weaps". I have then created another list in DZMSWeaponCrateList for MG's and Snipers  and just called them DZMSsniperListB & DZMSmgListB as weaps called the same list of guns, apart from primary, that weapons did before my change. After pointing them up properly, what this now means is that I only have .556 cal (or thereabouts) weapons in my minor mission crates and all the funky 7.62 stuff in my major mission crates. With the AI also configured to be a bit easier on minor missions and the guns they use also .556 and the AI on the major missions being tougher with 7.62's this really does result in having a medium/hard & easy split between the 2 mission type, major and minor. (I then use WAI for ultra hard with heli's and para drops and armed humvees)

 

The problem I'm having is that although I don't mind the fact that they use the same weapon loot rate in DZMSConfig which I could probably mess around with using the other rate types that are unused like DEFRifleRate, for some types like DEFSMGRate when set to 2, might actually put 4 in there and then also double up on the ammo as well.

 

For an easy mission, with anywhere from 4-8 AI, I think having a payout of 4 guns of one type and then some 2's and 1's as well for other types is too much. I would prefer to see 0-2 all the way down the list.

[ReDBaroN]

Is 4 really the magic number, here? (I need to have a look into WAI at the numbers, there).

Does the degradation come with the step from 4 to 5 or gradually?

Is the issue a matter of Arma2 coding or a matter of resources (meaning: is Arma programmed to only handle a limited number of group members or does the communication between too many members bog down the CPU)?

 

Why I'm asking: if 6 or 8 would still be ok, one could keep a significant number of AI without sacrificing the cleanup:

A typical call to create a group would be

[[(_coords select 0),(_coords select 1),0],6,1,"DZMSUnitsMajor"] call DZMSAISpawn;

defining an array DZMSUnitsMajor that is used in DZMSMajTimer.sqf to get rid of the AI remaining at mission end:

{if (alive _x) then {_x call DZMSPurgeObject;};} forEach DZMSUnitsMajor;

When creating more than 1 group we'd need more arrays DZMSMajor or we have to change DZMSAISpawn to append to it (and DZMS*Timer to clear the array after purging).

 

 

Edit: looked into WAI and while mostly the squads consist of 4 members the Ikea convoy one has 5 and I remember it as pretty deadly, so I guess performance will degrade rather than break down at 4.

No, please don't take that as read. I haven't tested them gradually. I just noticed when I first did one line with 12 in it they seemed by top of the idiot class and when I changed it to 3 lines of 4 or even 4 lines of 3 they improved massively. I worked this out with DZMS which I was using before..

 

This also adds another huge advantage if equipping them with RPG's to prevent your cheekier players that like to run them all over in a humvee just to grab the crate loot in that, one member of each squad is given an RPG. So, if you have 4 squads of 3, out of 12 AI, 4 of them will have RPG's.

 

I have done something similar with WAI which i use as my very hard kos AI missions running alongside EMS.

 

I didn't actually go through a step by step test to see when they turned into morons... :)

 

What do you mean about clear up then? I'm not aware of any problems. Should I be worried?

[ekroemer]

Answering separately:

 

The problem I'm having is that although I don't mind the fact that they use the same weapon loot rate in DZMSConfig which I could probably mess around with using the other rate types that are unused like DEFRifleRate, for some types like DEFSMGRate when set to 2, might actually put 4 in there and then also double up on the ammo as well.

 

For an easy mission, with anywhere from 4-8 AI, I think having a payout of 4 guns of one type and then some 2's and 1's as well for other types is too much. I would prefer to see 0-2 all the way down the list.

 

nice setup you're describing :-)

 

As I wrote, I do not see an easy way to enforce a limit of 2 to a _specified_ weapon. But you can, e.g.

• put all roughly equivalent weapons into a separate array (equivalent meaning that you don't care if the crate holds 1 of memberA and one of memberB or 2 of memberA)
• define the maximum count by the upper limit of the for_loop, just as the XXXRate does now
• give 0 or 1 weapon per iteration using _crate addWeaponCargoGlobal [_item,(round(random 1))];

This way while some passes through the loop may result in a weapon picked before, the overall count will be less than XXXRate.

[ekroemer]

No, please don't take that as read. I haven't tested them gradually. I just noticed when I first did one line with 12 in it they seemed by top of the idiot class and when I changed it to 3 lines of 4 or even 4 lines of 3 they improved massively. I worked this out with DZMS which I was using before..

[...]

What do you mean about clear up then? I'm not aware of any problems. Should I be worried?

 

OK, that's a relief :-) So 6 should work nearly as well as 4.

 

Worried? Depends: When you are spawning more than one group you'll overwrite the argument DZMSUnitsMajor. In this example

[[(_coords select 0),   (_coords select 1),0],4,1,"DZMSUnitsMajor"] call DZMSAISpawn;
[[(_coords select 0)+10,(_coords select 1),0],4,1,"DZMSUnitsMajor"] call DZMSAISpawn;

after the mission is cleared the surviving members of the first group won't be removed from the game but will continue to roam the vicinity, endanger innocent players ;-) and eat CPU resources.

 

Obviously there's no problem when all AI have been killed, but may be when players use stealthy tactics.

 

BTW: in some of the EMS missions the DZMSUnitsMajor|Minor argument to DZMSAISpawn is missing. That means that these missions are not cleaned up, properly.

[ReDBaroN]

OK, that's a relief :-) So 6 should work nearly as well as 4.

 

Worried? Depends: When you are spawning more than one group you'll overwrite the argument DZMSUnitsMajor. In this example

[[(_coords select 0),   (_coords select 1),0],4,1,"DZMSUnitsMajor"] call DZMSAISpawn;
[[(_coords select 0)+10,(_coords select 1),0],4,1,"DZMSUnitsMajor"] call DZMSAISpawn;

after the mission is cleared the surviving members of the first group won't be removed from the game but will continue to roam the vicinity, endanger innocent players ;-) and eat CPU resources.

 

Obviously there's no problem when all AI have been killed, but may be when players use stealthy tactics.

 

BTW: in some of the EMS missions the DZMSUnitsMajor|Minor argument to DZMSAISpawn is missing. That means that these missions are not cleaned up, properly.

Hmmm, OK. I think we're stepping beyond my knowledge barrier a bit.... :)

 

In your example above, I haven't even bothered to set them with +x or -x coords to the previous squad, I literally just pasted the line and they seem to be fine..

 

So, what can I add to make them clear up properly? Although I have it set to 75% of AI must be cleared to complete the mission, I'm still worried about a few roamers left floating about eating CPU resources....

 

Also, on your final comment, did you mean where Minor SM2 used to have DZMSUnitsMinor missing? Because that actually stopped minor from spawning altogether until it was added to the spawn line in the mission....

[ReDBaroN]

Answering separately:

 

 

nice setup you're describing :-)

 

As I wrote, I do not see an easy way to enforce a limit of 2 to a _specified_ weapon. But you can, e.g.

• put all roughly equivalent weapons into a separate array (equivalent meaning that you don't care if the crate holds 1 of memberA and one of memberB or 2 of memberA)
• define the maximum count by the upper limit of the for_loop, just as the XXXRate does now
• give 0 or 1 weapon per iteration using _crate addWeaponCargoGlobal [_item,(round(random 1))];

This way while some passes through the loop may result in a weapon picked before, the overall count will be less than XXXRate.

Top Stuff! Thanks for this!

 

Wrt the weapons, I have already done that. Make sure that there's no overlap between the arrays....I think that is what you meant?

 

So, if I have read this correctly, I just go through each of those blocks in DZMSBox and change:

_crate addWeaponCargoGlobal [_item,DEFSMGRate];

to:

_crate addWeaponCargoGlobal [_item,(round(random 1))];

Is that right?

 

Also what do I need to do for the ammo as this was doubling up too?:

_crate addMagazineCargoGlobal [(_ammo select 0),(round(random DEFSMGAmmoRate))];

[ekroemer]

Hmmm, OK. I think we're stepping beyond my knowledge barrier a bit.... :)

 

In your example above, I haven't even bothered to set them with +x or -x coords to the previous squad, I literally just pasted the line and they seem to be fine..

 

So, what can I add to make them clear up properly? Although I have it set to 75% of AI must be cleared to complete the mission, I'm still worried about a few roamers left floating about eating CPU resources....

 

Also, on your final comment, did you mean where Minor SM2 used to have DZMSUnitsMinor missing? Because that actually stopped minor from spawning altogether until it was added to the spawn line in the mission....

That's usually the only way to create new knowledge ;-)

 

Not offsetting the position should be fine...otherwise the whole squad would stand on each other's heads :-) Jus me being ocd...

 

Proper cleanup: Quick&Dirty would be to create a copy DZMSUnitsMajor2, use this in the creation of the second group and duplicate the cleanup in DZMSMajTimer.sqf, basically copying everything handling DZMSUnitsMajor.

Naturally one would have to expand this to DZMSUnitsMajor3 and so on if spawning more than 2 groups, that is where it gets less quick and more dirty ;-)

 

Really proper cleanup...I don't speak sqf, either. One would have to modify DZMSAISpawn.sqf where it creates the array _unitArrayName (lines 141).

 

Hmmm, looking at the cryptic

call compile format["
%1 = %1 + (units _unitGroup); 
_unitMissionCount = count %1;
",_unitArrayName];

I could imagine that the new group is already appended to the existing one. In this case my point would be moot :-)

But I'd like the opinion of Vampire or some other sqf-expert, here.

 

So, lets put this question on hold until someone make a well-founded comment.

 

Edit: Scratch  my concerns! Vampire's original DZMS missions do exactly that: spawning several groups of 4-6 AI, so indeed, cleanup is handled via appending. Sorry! I got mislead by assuming that DZMSUnitsMajor was an output variable to DZMSAISpawn, but sqf handles those thingies to the left of the function names as in/out...

[ekroemer]

 

So, if I have read this correctly, I just go through each of those blocks in DZMSBox and change:

_crate addWeaponCargoGlobal [_item,DEFSMGRate];

to:

_crate addWeaponCargoGlobal [_item,(round(random 1))];

Is that right?

 

Also what do I need to do for the ammo as this was doubling up too?:

_crate addMagazineCargoGlobal [(_ammo select 0),(round(random DEFSMGAmmoRate))];

Regarding the weapons, yes that would be the change to make (as far as my sqf-knowledge goes).

 

Regarding the ammo: whether the weapon was added or not (chance of 50%), ammo will always be added. But that's no problem because you can always fiddle with your ammo count DEFSMGAmmoRate.

 

If your goal is, that on average every weapon spawned will come with AVERAGEAMMO mags, then set DEFSMGAmmoRate to

AVERAGEAMMO, because:

• ammo count will always be between 0 and DEFSMGAmmoRate
• with a mean value 0.5*DEFSMGAmmoRate
• the probability of a weapon spawning is also 0.5.

Of cource that assumes that 2 different weapons share the same ammo....

 

If you want to spawn exactly DEFSMGAmmoRate mags per weapon spawned, then you'll have to put the result of (round(random 1)) into a local variable and refer to it, later, something like

private ["_dummy"];
_dummy =(round(random 1));
_crate addWeaponCargoGlobal [_item,_dummy];
if ( _dummy > 0 ) {
  _crate addMagazineCargoGlobal [(_ammo select 0), DEFSMGAmmoRate];
};

Note that I did not test this code.

[mgm]

No, please don't take that as read. I haven't tested them gradually. I just noticed when I first did one line with 12 in it they seemed by top of the idiot class and when I changed it to 3 lines of 4 or even 4 lines of 3 they improved massively. I worked this out with DZMS which I was using before..

 

This also adds another huge advantage if equipping them with RPG's to prevent your cheekier players that like to run them all over in a humvee just to grab the crate loot in that, one member of each squad is given an RPG. So, if you have 4 squads of 3, out of 12 AI, 4 of them will have RPG's.

 

I have done something similar with WAI which i use as my very hard kos AI missions running alongside EMS.

 

I didn't actually go through a step by step test to see when they turned into morons... :)

 

What do you mean about clear up then? I'm not aware of any problems. Should I be worried?

Sounds like that's a good setup you got there. Do you mind sharing your files?

[ReDBaroN]

Sounds like that's a good setup you got there. Do you mind sharing your files?

Hey MGM, not at all!

 

Please be prepared for untidiness though.....I'll pm you the link so as not to hijack version control in Defent's thread.

[Externized]

Can't wait to try this on my server!  :D

[pozzer18]

Hey MGM, not at all!

 

Please be prepared for untidiness though.....I'll pm you the link so as not to hijack version control in Defent's thread.

 

i too would be interested in this :)

[err0r]

Anyone have mission timeouts for EMS?