Vcom AI V2.0 - AI Overhaul

[piggypotpie 15]

15 hours ago, afevis said:

No? lol

Suppression set to false, most of the AI values are changed too.

 

http://c2n.me/3GBXOhy.png

 

Left is default / how it comes, right are my values from the pastebin.

I can't read the highlighted portion

[afevis 26]

20 hours ago, bairanbokkeri said:

Ive seen that "lets say hi to the enemy and not shoot him" behavior before on dev branch with and without vcom. Its especially prominent with huge battles, seems that the thread which dictates what different units should do seems to hang, seen some cases where all nato units just stood in place when a few hundred zombies just ran at them.

So i dont think its an issue with vcom, more to do with the engine.

Oh right, what are the settings when ai squads drop out of combat stance? Tested rearming today in that virtual arena, placed down some vehicles, ammo boxes, stuff like that me being a civilian observer.

Then stripped all three soldiers that i spawned from all their ammo except one mag and spawned some enemies that i frozed in place. After they killed them, i was expecting those nato blokes to rearm themselves but instead they stayed in combat mode and started to run in random directions occasionally going prone.

It might be me being in the dev build due to 64bit but i thought that i might aswell say it anyway if it indeed is an issue.

Strange. Just to note, I'm using the profiling build for server, HC, & client.

 

 

10 hours ago, piggypotpie said:

I can't read the highlighted portion

Didn't actually mean for you to read it off the image, was trying to show you that it was in fact different from the userconfig you include with the mod lol

 

http://c2n.me/3GDZxQ9.png

Here it is in a bit more readable color though if you want though. Again, left is what you include with the mod, right is mine.

[piggypotpie 15]

2 hours ago, afevis said:

Strange. Just to note, I'm using the profiling build for server, HC, & client.

 

 

Didn't actually mean for you to read it off the image, was trying to show you that it was in fact different from the userconfig you include with the mod lol

 

http://c2n.me/3GDZxQ9.png

Here it is in a bit more readable color though if you want though. Again, left is what you include with the mod, right is mine.

Thanks, man. I'll try it tonight. 

[patpowercat 7]

On 1/16/2017 at 11:53 AM, genesis92x said:

 

[
	{
		{
			If (!isNull (driver _x) ) then {
				{
					if !(_x getVariable ["NOAI",false];) then
					{
						_x setVariable ["NOAI", true, false];
					};
				} foreach (units group (driver _x));

			};
		} Foreach (vehicles select {_x isKindOf "Helicopter"});
	},
	10,
	[]
] call CBA_fnc_addPerFrameHandler

 

I've placed this in my init.sqf for an alive mission, but I keep getting errors. This is from my RPT:

 

[
{
{
If (!isNull (driver _x) ) then {
{>
20:35:57   Error position: <[
{
{
If (!isNull (driver _x) ) then {
{>
20:35:57   Error Generic error in expression

 

Genesis you able to shed any light on this?

[M. Buchanan 21]

He had a minor error.  Try this.

 

[
  {
    {
      If (!isNull (driver _x) ) then {
        {
          if !(_x getVariable ["NOAI",false]) then
          {
            _x setVariable ["NOAI", true, false];
          };
        } foreach (units group (driver _x));

      };
    } Foreach (vehicles select {_x isKindOf "Helicopter"});
  },
  10,
  []
] call CBA_fnc_addPerFrameHandler;

 

[patpowercat 7]

Thanks! Pesky semicolons. 

[M. Buchanan 21]

@patpowercat this works fine for units created later via zeus, etc. However if you want the easiest solution for CAS, Transport and Artillery, use this in the code boxes available in each respective module.
 

{_x setvariable ["NOAI",true];_x setvariable ["VCOM_NOPATHING_Unit",true];} foreach (Crew this);

 

@HeroesandvillainsOS @spyderblack723 @tupolov note: I am assuming this code goes in the units init, right?  If that is the case, something is up with respawn, because they revert to VCOM AI behavior after the first time they die.  This is particularly noticeable when a 155 gun you thought was static starts shooting 10 feet away from you at 3am.  Also, there was something else but I can't remember.  Will post it on ALiVE forums.  

 

@genesis92x.. If you are going for adoption by larger CoOP groups (mine uses ACE, ALiVE, TFAR, and RHS, among others), may I humbly suggest a few things that would be fairly easy to add to your enviously sized FSM?  
 

1. Have Artillery check a location radius for civilians (and friendly units, including IND if aligned) before firing (inAreaArray is your friend).  Could be an optional parameter.  I watched in horror last night as a battery of m109's gleefully destroyed the largest town on Clafghan. They were laughing, it was sick.
2. This one ain't so easy. I like your rank based system for applying skill levels, but there's a major flaw with dynamic mods like ALiVE, or anyone who uses zeus.  Almost all units pop in as privates.. and thus are total losers.  Consider a way to define classes and the skills they would get?  Or maybe it would be easier to just assign them rank using the same method.  Another option... and the hardest one... Go the ACE 3 route and use 3den modules for everything.  Set skills in module, apply those skills to units based on class, or rank, or module sync.
3. You want to speed things up?? Move what logic you can over to the CBA state machine.  It's intensely fast, and lets you define all of your states and transitions in a seemingly easier .hpp class structure than the one in vanilla.  @baermitumlaut wrote it.  He loves people, and loves to answer anyone's questions at any time, day or night.  Right buddy?  

[genesis92x 810]

5 hours ago, SN M. Buchanan said:

@patpowercat this works fine for units created later via zeus, etc. However if you want the easiest solution for CAS, Transport and Artillery, use this in the code boxes available in each respective module.
 

{_x setvariable ["NOAI",true];_x setvariable ["VCOM_NOPATHING_Unit",true];} foreach (Crew this);

 

@HeroesandvillainsOS @spyderblack723 @tupolov note: I am assuming this code goes in the units init, right?  If that is the case, something is up with respawn, because they revert to VCOM AI behavior after the first time they die.  This is particularly noticeable when a 155 gun you thought was static starts shooting 10 feet away from you at 3am.  Also, there was something else but I can't remember.  Will post it on ALiVE forums.  

 

@genesis92x.. If you are going for adoption by larger CoOP groups (mine uses ACE, ALiVE, TFAR, and RHS, among others), may I humbly suggest a few things that would be fairly easy to add to your enviously sized FSM?  
 

1. Have Artillery check a location radius for civilians (and friendly units, including IND if aligned) before firing (inAreaArray is your friend).  Could be an optional parameter.  I watched in horror last night as a battery of m109's gleefully destroyed the largest town on Clafghan. They were laughing, it was sick.
2. This one ain't so easy. I like your rank based system for applying skill levels, but there's a major flaw with dynamic mods like ALiVE, or anyone who uses zeus.  Almost all units pop in as privates.. and thus are total losers.  Consider a way to define classes and the skills they would get?  Or maybe it would be easier to just assign them rank using the same method.  Another option... and the hardest one... Go the ACE 3 route and use 3den modules for everything.  Set skills in module, apply those skills to units based on class, or rank, or module sync.
3. You want to speed things up?? Move what logic you can over to the CBA state machine.  It's intensely fast, and lets you define all of your states and transitions in a seemingly easier .hpp class structure than the one in vanilla.  @baermitumlaut wrote it.  He loves people, and loves to answer anyone's questions at any time, day or night.  Right buddy?  

 

These are all good suggestions :) I will also be adding in automatic disabling of  any units tagged with "ALIVE_CombatSupport" so that people will not have headaches with support vehicles and Vcom as well.

 

1) That is a good idea, I will add it to the TODO

 

2) This is a difficult one for me to justify spending time on at the moment. I will add it to the TODO list so I can look at it with fresh eyes at a later date.

 

3) I did not know CBA was so fast, that is good information. The only reason I have not adopted CBA for this is because I love keeping things simple for myself and others. Being able to plug-in-play means a lot to me, as well as challenging myself to optimize functions. For my future projects I will be looking into using CBA more frequently as it has great benefits (like you mentioned). My second concern would be the level of difficulty converting Vcom over to utilize CBA. Say, I Wanted to support a non-CBA version and a CBA version, how difficult would that be?

[M. Buchanan 21]

15 hours ago, genesis92x said:

Say, I Wanted to support a non-CBA version and a CBA version, how difficult would that be?

 The state machines only share the name state machine and... that's about it.  All of CBA's stuff is unscheduled, which means there's no impact on frames.  Check out ACE 3 Medical AI  under addons/medical_AI on github for a look. The guy who wrote the state machine also wrote this AI, and you literally don't even notice it's running.

As far as moving a lot of what you're doing over to CBA, then trying to migrate back... Not so easy for two reasons.  One, your lizard brain will tell you you'd be making a huge mistake!  Two, the code is very dissimilar and using CBA takes a bit more syntactical know how than vanilla SQF functions.  You'd be doing a full rewrite, if you used CBA everywhere you could.  If you want to learn to work with CBA, jump on the ACE 3 slack.  They're mostly the CBA guys as well as ACE guys, and they're amazing coders.

I can't speak for the whole community, and maybe I just got lucky and fell into it... But I don't know anyone who DOES play with an AI mod and doesn't play with CBA.  My two cents on that.

[jetset22a 7]

On 1/22/2017 at 10:41 AM, SN M. Buchanan said:

...

You want to speed things up?? Move what logic you can over to the CBA state machine.  It's intensely fast, and lets you define all of your states and transitions in a seemingly easier .hpp class structure than the one in vanilla.  @baermitumlaut wrote it.  He loves people, and loves to answer anyone's questions at any time, day or night.  Right buddy?  

 

Would this also mean faster spawning of units with VCOM? I'm currently trying to implement VCOM into a DUWS mission I've been working on, but during startup, the generation of the zones slows to the point that it's unplayable. It only really works with 6-7 zones at most, and even then the generation of the zones slow to the point where I'm not sure if they'll initialize or not. If this can help with that, then +1 to this idea! I only tried VCOM a few times in my mission since it limits the zones I can spawn, but since playing with it I feel like I'm missing out on the best gameplay I could possibly have when I take it out!

[bairanbokkeri 2]

8 minutes ago, jetset22a said:

 

Would this also mean faster spawning of units with VCOM? I'm currently trying to implement VCOM into a DUWS mission I've been working on, but during startup, the generation of the zones slows to the point that it's unplayable. It only really works with 6-7 zones at most, and even then the generation of the zones slow to the point where I'm not sure if they'll initialize or not. If this can help with that, then +1 to this idea! I only tried VCOM a few times in my mission since it limits the zones I can spawn, but since playing with it I feel like I'm missing out on the best gameplay I could possibly have when I take it out!

And the most horrible since now you can never know if those lil devils have mined roads or where theyre coming from, they really do like their flanks :D

[jetset22a 7]

I have a question about how the VCOM script version works. Like I said in a previous post, I want to use VCOM in a DUWS mission I'm working on but have trouble generating more than 6-7 zones for a mission when VCOM is initialized. My question is does VCOM only affect AI that is spawned after VCOM is initialized? My work around that I'm considering is having the VCOM script executed AFTER the zones are generated, which means after the units are already spawned.  Would this work?

[Nicolai Lorenzen 17]

Is there any way to check if vCom is actually enabled? I'm having a hard time to see if they do something different ingame (right now they are just laming around as per usual). 

Or could you add a "vCom enabled" status msg when server starts up or such?

[genesis92x 810]

15 hours ago, jetset22a said:

I have a question about how the VCOM script version works. Like I said in a previous post, I want to use VCOM in a DUWS mission I'm working on but have trouble generating more than 6-7 zones for a mission when VCOM is initialized. My question is does VCOM only affect AI that is spawned after VCOM is initialized? My work around that I'm considering is having the VCOM script executed AFTER the zones are generated, which means after the units are already spawned.  Would this work?

This. I would have Vcom execute AFTER the units are spawned. Vcom puts units in a queue so it won't activate all the AI at once. This should help FPS/script lag

 

10 hours ago, Nicolai Lorenzen said:

Is there any way to check if vCom is actually enabled? I'm having a hard time to see if they do something different ingame (right now they are just laming around as per usual). 

Or could you add a "vCom enabled" status msg when server starts up or such?

The best way to see if Vcom is even running is to create a trigger activated by radio with this in its activation field: hint format ["Where is Vcom: %1",VCOM_AIConfig]; If this comes back NULL or NIL then Vcom is NOT running. Another way to tell is to put a squad inside a town, give them 15 seconds or so, and if they don't change formations then VCOM is not running.

 

 

On 1/23/2017 at 6:51 AM, SN M. Buchanan said:

 The state machines only share the name state machine and... that's about it.  All of CBA's stuff is unscheduled, which means there's no impact on frames.  Check out ACE 3 Medical AI  under addons/medical_AI on github for a look. The guy who wrote the state machine also wrote this AI, and you literally don't even notice it's running.

As far as moving a lot of what you're doing over to CBA, then trying to migrate back... Not so easy for two reasons.  One, your lizard brain will tell you you'd be making a huge mistake!  Two, the code is very dissimilar and using CBA takes a bit more syntactical know how than vanilla SQF functions.  You'd be doing a full rewrite, if you used CBA everywhere you could.  If you want to learn to work with CBA, jump on the ACE 3 slack.  They're mostly the CBA guys as well as ACE guys, and they're amazing coders.

I can't speak for the whole community, and maybe I just got lucky and fell into it... But I don't know anyone who DOES play with an AI mod and doesn't play with CBA.  My two cents on that.

So. This is what I am thinking. In late February or March I will sit down and take a look at converting Vcom to use CBA. It feels like converting Vcom to CBA will not be speedy and more difficult than starting a project from scratch, but what a fantastic way to learn how to use CBA. You have convinced me to try it.

[bairanbokkeri 2]

One thing though which could be a good addition with the flanking action would be for the ai to utilize guerrilla attacks, especially when encountering bigger enemy groups.

Like see the enemy, take a few shots, retreat, regroup and attack again from a different point. Rinse and repeat. Also mine the roads near known enemy positions if they spot any vehicles with them.

Dont know if its possible but it would make them even more unpredictable (and annoying :D)

[Mashroom 6]

5 hours ago, bairanbokkeri said:

One thing though which could be a good addition with the flanking action would be for the ai to utilize guerrilla attacks, especially when encountering bigger enemy groups.

Like see the enemy, take a few shots, retreat, regroup and attack again from a different point. Rinse and repeat. Also mine the roads near known enemy positions if they spot any vehicles with them.

Dont know if its possible but it would make them even more unpredictable (and annoying :D)

 

The day I see Arma AI retreating will be a glorious one.

[das attorney 858]

On 1/23/2017 at 1:51 PM, SN M. Buchanan said:

All of CBA's stuff is unscheduled, which means there's no impact on frames.

 

That's not true.

 

You can lock up Arma like nobody's business using unscheduled code.  If anything, it's dependent on frames, so the moar you add, the slower the game runs.  I was having a similar conversation recently, and there's no way around overhead when scripting.  Yes, running everything off FSM's/unscheduled code, will unclog the scheduler, but then you're actually fucking the engines ability to run normally as you're demanding all of your code be executed immediately, irrespective of the content of the code.

 

I'm not saying it's a terrible thing to do, but it really should be more used for time-critical things, and stuff you don't give a shit about should be ran in the scheduler; so if it is delayed, then who cares?  Saying that unscheduled or State Machines have no perf impact is wrong, as there is only so much the game engine can process per unit of time before fps starts to tail off.  As always, be sensible about what you are trying to achieve in your code, but by using high-priority things like FSM/EH, you're kicking something else down the queue.  That's ok to a point, but then if your code is too much, with the expectation of no perf impact, then it could very well be chug-city for the player.

 

As an example, you can run this sample unscheduled code to check for yourself.  Pop it in the debug console or run from a trigger and it will lock your game up for a number of seconds.  Don't be fooled by the spawn, it's just a wrapper for the unscheduled code from isNil.  Obv, it's a very extreme example, but it's to illustrate that unscheduled code can fuck Arma just the same as scheduled.  It's more important what your code contains imo and not thinking that things like FSM/EH/unscheduled is automatically a magic bullet.

 

0 = 0 spawn {
    uiSleep 3;
    hintSilent "starting";
    uiSleep 1;
    isNil {
        for "_unscheduledLockup" from 1 to 999999 do {
            selectBestPlaces [
                position player,
                10000,
                "(2 * (waterDepth interpolate [1,16,0,1]) * ((0.1+houses factor [0.1,0.8]) * (randomGen 1 + houses)))",
                0.1,
                500
            ]
        }
    }
};

 

[jetset22a 7]

8 hours ago, genesis92x said:

This. I would have Vcom execute AFTER the units are spawned. Vcom puts units in a queue so it won't activate all the AI at once. This should help FPS/script lag

Ok, so I tried this and it definitely worked in allowing me to generate all the zones I wanted. However, I found that I now have problems with other scripts running properly once VCOM is executed. Is this because I'm waiting for VCOM to be applied to all the units in the queue like you said, or because it's just that the VCOM is very script heavy so my game is just going to have all other scripts run super slow as well? Basically when VCOM is initialized, all other scripts act super slow, which as you can imagine can create big problems. A small example of what I'm talking about; if I try to do certain actions, such as opening a requests menu in the action menu, the requests menu will open several seconds after the action is done. This basically happens to all scripts the mission utilizes to the point of being unplayeable again :(. Do I just have to wait for VCOM to initialize for all units that are generated before it's back to normal or is it just how the script runs and there's nothing I can do?

 

TL;DR Everything that is supposed to happen via scripts happens several seconds (anywhere from 10-30 seconds) after it's supposed to. In some cases with more complicated scripts, such as parajumping via VQI LEAP mod can take minutes or seemingly never.

 

Edit: After some testing, it doesn't seem like the game ever goes back to normal, or at least not within a reasonable amount of time, so I will have to go back to no VCOM AI . Still, thank you for your response. I appreciate the communication and the knowledge that you're still working on this mod and trying to make it better gives me hope. I look forward to seeing what comes out of making it CBA compatible.

[genesis92x 810]

3 hours ago, das attorney said:

 

That's not true.

 

You can lock up Arma like nobody's business using unscheduled code.  If anything, it's dependent on frames, so the moar you add, the slower the game runs.  I was having a similar conversation recently, and there's no way around overhead when scripting.  Yes, running everything off FSM's/unscheduled code, will unclog the scheduler, but then you're actually fucking the engines ability to run normally as you're demanding all of your code be executed immediately, irrespective of the content of the code.

 

I'm not saying it's a terrible thing to do, but it really should be more used for time-critical things, and stuff you don't give a shit about should be ran in the scheduler; so if it is delayed, then who cares?  Saying that unscheduled or State Machines have no perf impact is wrong, as there is only so much the game engine can process per unit of time before fps starts to tail off.  As always, be sensible about what you are trying to achieve in your code, but by using high-priority things like FSM/EH, you're kicking something else down the queue.  That's ok to a point, but then if your code is too much, with the expectation of no perf impact, then it could very well be chug-city for the player.

 

As an example, you can run this sample unscheduled code to check for yourself.  Pop it in the debug console or run from a trigger and it will lock your game up for a number of seconds.  Don't be fooled by the spawn, it's just a wrapper for the unscheduled code from isNil.  Obv, it's a very extreme example, but it's to illustrate that unscheduled code can fuck Arma just the same as scheduled.  It's more important what your code contains imo and not thinking that things like FSM/EH/unscheduled is automatically a magic bullet.

 

0 = 0 spawn {
    uiSleep 3;
    hintSilent "starting";
    uiSleep 1;
    isNil {
        for "_unscheduledLockup" from 1 to 999999 do {
            selectBestPlaces [
                position player,
                10000,
                "(2 * (waterDepth interpolate [1,16,0,1]) * ((0.1+houses factor [0.1,0.8]) * (randomGen 1 + houses)))",
                0.1,
                500
            ]
        }
    }
};

 

Yeah. I learned this valuable lesson in optimizing Vcom. There needs to be a fine balance. A very fine balance.

3 hours ago, jetset22a said:

Ok, so I tried this and it definitely worked in allowing me to generate all the zones I wanted. However, I found that I now have problems with other scripts running properly once VCOM is executed. Is this because I'm waiting for VCOM to be applied to all the units in the queue like you said, or because it's just that the VCOM is very script heavy so my game is just going to have all other scripts run super slow as well? Basically when VCOM is initialized, all other scripts act super slow, which as you can imagine can create big problems. A small example of what I'm talking about; if I try to do certain actions, such as opening a requests menu in the action menu, the requests menu will open several seconds after the action is done. This basically happens to all scripts the mission utilizes to the point of being unplayeable again :(. Do I just have to wait for VCOM to initialize for all units that are generated before it's back to normal or is it just how the script runs and there's nothing I can do?

 

TL;DR Everything that is supposed to happen via scripts happens several seconds (anywhere from 10-30 seconds) after it's supposed to. In some cases with more complicated scripts, such as parajumping via VQI LEAP mod can take minutes or seemingly never.

 

Edit: After some testing, it doesn't seem like the game ever goes back to normal, or at least not within a reasonable amount of time, so I will have to go back to no VCOM AI . Still, thank you for your response. I appreciate the communication and the knowledge that you're still working on this mod and trying to make it better gives me hope. I look forward to seeing what comes out of making it CBA compatible.

No problem! Unfortunately, advanced AI comes at a cost. If you are generating a mission with 250+ AI you are going to have a bad time. Keep in mind with ArmA (And especially Vcom AI) a lot of units with FEWER groups is better than a lot of units with MORE groups. Group leader AI is more demanding and will cause more scheduler lag. So if possible have your mission operate with bigger squads and fewer groups.

 

I am curious...if you have time...can you do a simple hint format ["%1 --- %2",count allunits, count allgroups]; and tell me the numbers? I know all machines are different but I was able to get ~200 AI, in groups of 8, all in combat to have an FPS drop of ~10 and scheduler lag of about .5 seconds. I am just curious about other missions and etc and one of the biggest things I am finding is that missions with MORE groups (Even if they have less AI) perform far worse than missions with MORE AI but LESS groups. 

[bairanbokkeri 2]

One thing to try out if people are having issues with big hordes of units is caching, tried this one a few times and it seems to help a lot;
 

Just throwing it out there. :)

[Nicholas.Bell 11]

While testing a mission directly from the editor I get this error message repeating.  Don't see it when playing outside the editor, but thought it might be of use.  Thanks for your work, Genesis.

 

VCOM_Curren>
22:28:52   Error position: <VCOM_CurrentlyMovingLimit};

VCOM_Curren>
22:28:52   Error Undefined variable in expression: vcom_currentlymovinglimit
22:28:52 File VCOMAI\VCOMAI\Functions\VCOMAI_MoveToCover.sqf, line 5
22:28:52 Error in expression <t 0;

waitUntil {VCOM_CurrentlyMoving < VCOM_CurrentlyMovingLimit};

VCOM_Curren>
22:28:52   Error position: <VCOM_CurrentlyMovingLimit};

VCOM_Curren>
22:28:52   Error Undefined variable in expression: vcom_currentlymovinglimit
22:28:52 File VCOMAI\VCOMAI\Functions\VCOMAI_MoveToCover.sqf, line 5
22:28:52 Error in expression <t 0;

waitUntil {VCOM_CurrentlyMoving < VCOM_CurrentlyMovingLimit};

VCOM_Curren>
22:28:52   Error position: <VCOM_CurrentlyMovingLimit};

[M. Buchanan 21]

5 hours ago, das attorney said:

 

That's not true.

 

You can lock up Arma like nobody's business using unscheduled code.  If anything, it's dependent on frames, so the moar you add, the slower the game runs.  I was having a similar conversation recently, and there's no way around overhead when scripting.  Yes, running everything off FSM's/unscheduled code, will unclog the scheduler, but then you're actually fucking the engines ability to run normally as you're demanding all of your code be executed immediately, irrespective of the content of the code.

 

I'm not saying it's a terrible thing to do, but it really should be more used for time-critical things, and stuff you don't give a shit about should be ran in the scheduler; so if it is delayed, then who cares?  Saying that unscheduled or State Machines have no perf impact is wrong, as there is only so much the game engine can process per unit of time before fps starts to tail off.  As always, be sensible about what you are trying to achieve in your code, but by using high-priority things like FSM/EH, you're kicking something else down the queue.  That's ok to a point, but then if your code is too much, with the expectation of no perf impact, then it could very well be chug-city for the player.

 

As an example, you can run this sample unscheduled code to check for yourself.  Pop it in the debug console or run from a trigger and it will lock your game up for a number of seconds.  Don't be fooled by the spawn, it's just a wrapper for the unscheduled code from isNil.  Obv, it's a very extreme example, but it's to illustrate that unscheduled code can fuck Arma just the same as scheduled.  It's more important what your code contains imo and not thinking that things like FSM/EH/unscheduled is automatically a magic bullet.

 

0 = 0 spawn {
    uiSleep 3;
    hintSilent "starting";
    uiSleep 1;
    isNil {
        for "_unscheduledLockup" from 1 to 999999 do {
            selectBestPlaces [
                position player,
                10000,
                "(2 * (waterDepth interpolate [1,16,0,1]) * ((0.1+houses factor [0.1,0.8]) * (randomGen 1 + houses)))",
                0.1,
                500
            ]
        }
    }
};

 

 

Not at all, and you are correct @das attorney.  I misspoke.  You can definitely still mess up when trying to go unscheduled, and it is by no means a silver bullet.  It IS part of good coding practices though, and CBA helps immensely with allowing you to stick to those good practices.  That there ^^ is not truly what I meant.  That's vanilla code that doesn't make use of the smartly done unscheduled stuff that CBA makes easy for you.

 

To your second point, I disagree. Of course what's in your logic matters, but how you split that logic up into functions, how you encapsulate it with smart running unscheduled loops, how you initiate it with lightweight event handlers or FSM (or FSM event transitions)... That stuff all matters a great deal.  That stuff is how you make monster code like the example above actually possible.

 

Back to the point... next time you need to run something 100,000 times like that, don't use that.  Use a CBA per frame handler.  Next time you need to wait for 3 seconds, don't sleep the UI in a spawned thread.  Use cba_fnc_waitUntilAndExecute.  Next time you need to run a simple bit of math, and not 100,000 times hopefully, use a direct call.  Plus a few other little things in that single block of code that could be moved to CBA when appropriate.  Just.. if you're not on the coolaid, take a look at the stuff.

 

and @genesis92x super glad to hear you're giving it a go.  If you ever need more people just put the word out.

 

edit.. it would be waitAndExexute, not waitUntilAndExecute.  But you get the idea.

[Nicolai Lorenzen 17]

15 hours ago, genesis92x said:

On 24/1/2017 at 10:39 AM, Nicolai Lorenzen said:

Is there any way to check if vCom is actually enabled? I'm having a hard time to see if they do something different ingame (right now they are just laming around as per usual). 

Or could you add a "vCom enabled" status msg when server starts up or such?

The best way to see if Vcom is even running is to create a trigger activated by radio with this in its activation field: hint format ["Where is Vcom: %1",VCOM_AIConfig]; If this comes back NULL or NIL then Vcom is NOT running. Another way to tell is to put a squad inside a town, give them 15 seconds or so, and if they don't change formations then VCOM is not running.

 

Cool thanks - testing asap.

 

On a side note - how does Vcom interact with ryans zombies? If they do - should I somehow stop that?

 

Note 2: can i test directly from editor, or do i have to export to MP set up a server (locally) and logon : test? // GOT IT TO WORK! 

 

EDIT: It worked - I can test directly from editor - they form up a 360 formation and react quite differently from vanilla - I'm so relieved. Now to play. 

[autigergrad 2034]

7 hours ago, genesis92x said:

Yeah. I learned this valuable lesson in optimizing Vcom. There needs to be a fine balance. A very fine balance.

No problem! Unfortunately, advanced AI comes at a cost. If you are generating a mission with 250+ AI you are going to have a bad time. Keep in mind with ArmA (And especially Vcom AI) a lot of units with FEWER groups is better than a lot of units with MORE groups. Group leader AI is more demanding and will cause more scheduler lag. So if possible have your mission operate with bigger squads and fewer groups.

 

I am curious...if you have time...can you do a simple hint format ["%1 --- %2",count allunits, count allgroups]; and tell me the numbers? I know all machines are different but I was able to get ~200 AI, in groups of 8, all in combat to have an FPS drop of ~10 and scheduler lag of about .5 seconds. I am just curious about other missions and etc and one of the biggest things I am finding is that missions with MORE groups (Even if they have less AI) perform far worse than missions with MORE AI but LESS groups. 

 

This is another reason why systems like ALiVE are so invaluable.  By virtualizing profiles/groups that are well outside the player's current area...you save gobs and gobs of FPS.  Trying to run a mission with 100-200 fully realized and active AI is going to cause a slideshow no matter how powerful your rig is.  So even though you technically may have 100s of foot troops and dozens of vehicles all over the map...at any one time you only have a small zone that actually has "real" troops spawned in.

 

We are running a campaign on our dedi with VCOM and ALiVE.  Had several engagements last night with 50-60 Taliban, vehicles, and 20-30 civs in an area and most of our group's FPS stayed above 50 FPS the entire session.  It's all about optimization of the mission and making sure you have a nice balance of how many profiles/units are "in the real world" at a time. 

 

Genesis's latest version of VCOM really improved the delay and FPS drop from the previous version of VCOM.  Works outstanding and is by far the best AI mod we've used.

[piggypotpie 15]

On 1/22/2017 at 4:52 PM, genesis92x said:

 

These are all good suggestions :) I will also be adding in automatic disabling of  any units tagged with "ALIVE_CombatSupport" so that people will not have headaches with support vehicles and Vcom as well.

 

1) That is a good idea, I will add it to the TODO

 

2) This is a difficult one for me to justify spending time on at the moment. I will add it to the TODO list so I can look at it with fresh eyes at a later date.

 

3) I did not know CBA was so fast, that is good information. The only reason I have not adopted CBA for this is because I love keeping things simple for myself and others. Being able to plug-in-play means a lot to me, as well as challenging myself to optimize functions. For my future projects I will be looking into using CBA more frequently as it has great benefits (like you mentioned). My second concern would be the level of difficulty converting Vcom over to utilize CBA. Say, I Wanted to support a non-CBA version and a CBA version, how difficult would that be?

 

I want to have your baby! Thanks, for this