ASR AI 3

[evromalarkey 150]

Thanks for the answer, it's possible that it may be affected by hlc ak's which is ai using often or our ai setting on server.. or maybe agm ai is affecting something.

We are using asr ai3 from the very beginning and maybe I missed something, I will try to tweak it somehow.

[El Tyranos 1264]

I will try to tweak it somehow.

EvroMalarky, if you find some adjustments, I'm interested. I'm using ASR + AGM_ai.pbo (and HLC) at the moment. I've got pretty much the same experience as you.

What I've tested so far :

- VTS + ASR + MCC : AI was lost with + deadly + server's CPU was on fire

- ASR + MCC : AI was clever and too deadly

- ASR + AGM : AI seems a bit too stupid and too deadly

[Robalo 465]

Thanks for the answer, it's possible that it may be affected by hlc ak's which is ai using often or our ai setting on server.. or maybe agm ai is affecting something.

We are using asr ai3 from the very beginning and maybe I missed something, I will try to tweak it somehow.

AGM AI is definitely conflicting, do not use with ASR AI.

HLC AK has some strange AI settings too, but them alone would not justify what you described.

Maybe I should start releasing AI configs for weapon packs soon.

[seba1976 98]

AGM AI is definitely conflicting, do not use with ASR AI.

The thing is, we haven't been able to run latest versions of AGM without their AI module.

Maybe I should start releasing AI configs for weapon packs soon.

Great :).

[Robalo 465]

The thing is, we haven't been able to run latest versions of AGM without their AI module..

Why not ? Did a quick test, everything seemed fine except I could not stand the crazy tone from near shots for too long :)

Edited October 27, 2014 by Robalo

[seba1976 98]

Why not ? Did a quick test, everything seemed fine except I could not stand the crazy tone from near shots for too long :)

Disregard. I was referring to TMR.

[evromalarkey 150]

I deleted AGM AI and just wondering it's possible that VTS 4.0 is also somehow conflicting with asr ai?

[Wolfenswan 1]

I noticed that with the recent update AI likes to attack players very aggressively and leave their position if it seems advantageous. Which nice and awesome to watch. But unfortunately it also plays havoc with my function to garrison towns, which puts AI into building positions and keeps them in place with doStop (which used to work fine). As of recently I've watched whole towns be "evacuated" and the AI swarming out to overwhelm the players. Is there a way to disable this behavior on specific units, say by setting a variable?

[Robalo 465]

I noticed that with the recent update AI likes to attack players very aggressively and leave their position if it seems advantageous. Which nice and awesome to watch. But unfortunately it also plays havoc with my function to garrison towns, which puts AI into building positions and keeps them in place with doStop (which used to work fine). As of recently I've watched whole towns be "evacuated" and the AI swarming out to overwhelm the players. Is there a way to disable this behavior on specific units, say by setting a variable?

There were always checks in place for uncompleted waypoints and that hasn't changed. I'm guessing it might be another mod doing that. You can of course disable reactions in userconfig - set them to {0,0,0} to completely disable any code that might assign AI new waypoints. You may also try disabling moving into cover and see if that changes anything. Let me know if you figure out what's going on.

Edited October 28, 2014 by Robalo

[Wolfenswan 1]

There were always checks in place for uncompleted waypoints and that hasn't changed. I'm guessing it might be another mod doing that. You can of course disable reactions in userconfig - set them to {0,0,0} to completely disable any code that might assign AI new waypoints. You may also try disabling moving into cover and see if that changes anything. Let me know if you figure out what's going on.

We're not running any other AI Mods. My script creates the units directly on the position and doStops them. Does group-size have any influence on when AI considers to charge? For perfomance reasons my script places them all in one big group, using enableAttack false to allow them to engage individually. So depending on how our mission-makers set it up the groups might be very big.

I will try what you suggested and see if it helps. Thanks.

[Robalo 465]

You got a quick command at hand for how to check if unit is doStop'd ? I should add something for it.

Group size is not a factor, there's an evaluation of near friendly vs. near enemy strength which may only prevent attacking and supporting actions. Like, don't attack a superior enemy force, don't reinforce when friendlies are a superior force.

[Wolfenswan 1]

I assume stopped would apply to doStop as well, but might also fire when stop/doStop commands are used from the FSM?

Personally I'd be happy enough if I could set a variable on individual units or their group to exclude them from being affected by specific ASR_AI3 components.

Unrelated to the issue at hand:

Is there a good way to override a client's ASR_AI3 settings with those the dedicated server is using? This is mostly relevant for missions using ZEUS where the curator is (hopefully) using ASR_AI3 but might have different settings in place. Would collecting the ASR_AI-generated global variables on the server and making them public do the trick?

Edit:

I did some limited local tests and it seems that reactions[] is indeed the culprit. A setting of {0,0,0} does not cause the AI to leave their positions but enabling any single value does.

Edited October 28, 2014 by Wolfenswan

[Robalo 465]

I assume stopped would apply to doStop as well, but might also fire when stop/doStop commands are used from the FSM?

Thanks, I'll think about it.

Personally I'd be happy enough if I could set a variable on individual units or their group to exclude them from being affected by specific ASR_AI3 components.

You can set this but it will prevent all scripted features from running on _unit: _unit setVariable ["asr_ai_exclude",true];

Unrelated to the issue at hand:

Is there a good way to override a client's ASR_AI3 settings with those the dedicated server is using? This is mostly relevant for missions using ZEUS where the curator is (hopefully) using ASR_AI3 but might have different settings in place. Would collecting the ASR_AI-generated global variables on the server and making them public do the trick?

That should do it. You only need to worry about asr_ai3_sysdanger_{debug,radionet,radiorange,seekcover,throwsmoke,reactions,usebuildings} variables because everything from sysaiskill is server side.

Edit:

I did some limited local tests and it seems that reactions[] is indeed the culprit. A setting of {0,0,0} does not cause the AI to leave their positions but enabling any single value does.

Thanks for the confirmation.

[seba1976 98]

OK now I'm worried. I have a garrison script aswell, and I need the units to stay inside. I can't confirm if they are getting dragged outside, but I use the same method Wolfenswan is using, so I'm guessing they are going to leave their garrison too. That would be a show stopper for me. Could you implement some way to exclude some groups from whatever it is that is forcing garrison units to leave their positions?

[Toasterbr 12]

Robalo, do you believe excluding the AGM_AI would be enough to make the ASR work as intended? Do I need to make any more modifications?

Thanks!

[Wolfenswan 1]

That should do it. You only need to worry about asr_ai3_sysdanger_{debug,radionet,radiorange,seekc over,throwsmoke,reactions,usebuildings} variables because everything from sysaiskill is server side.

To clarify: Would units created by a ZEUS player use the client's sysdanger values but the server's sysaiskill values? In any case I'd like to suggest a new variable to enable the server overriding all client values at mission start as a feature.

OK now I'm worried. I have a garrison script aswell, and I need the units to stay inside. I can't confirm if they are getting dragged outside, but I use the same method Wolfenswan is using, so I'm guessing they are going to leave their garrison too. That would be a show stopper for me. Could you implement some way to exclude some groups from whatever it is that is forcing garrison units to leave their positions?

It's pretty easy to test locally, just garrison a town and place a few hostile AI with allowDamage false and FSM disabled in the center. This is enough to trigger the scripted attack response which seems to cause them to leave position. You can also try making everyone invulnerable and engage each other to see the same happening with the scripted defense response.

A straightforward workaround my group is employing curently is to have the host set asr_ai3_sysaiskill_reactions to [0,0,0] in missions reliant on garrisons using the debug console.

If you don't notice your garrison leaving despite reactions enabled I wouldn't mind if I could have a look at your code to see if I can implement it on my end.

[Aeriyn 10]

To clarify: Would units created by a ZEUS player use the client's sysdanger values but the server's sysaiskill values? In any case I'd like to suggest a new variable to enable the server overriding all client values at mission start as a feature.

Agreed. That would be extremely useful when rotating the zeus players. Please do consider it.

[seba1976 98]

@Wolfenswan Yeah, I will do some tests as soon as I can. I was going throgh a whole code revision and this news is the last thing I needed, but I'll make a pause and check this tonight if I can. Thanks for noticing and reporting though.

[seba1976 98]

After some tests, I notice only two differences from vanilla. 1) The group that's engaged directly, does ventures to go outside, but they are very careful when doing so (they don't rush outside at all), while some units stay inside. It's a very convincing behaviour, but they do go outside, and depending on the situation, that could be a problem And 2) after some time, and after inflicting heavy casualies to the garrisoned group, another group in another building activates. Sometimes they go outside like the first, and sometimes don't, but they start moving (which doesn't happens in vanilla). I am not sure though, if it was sys_danger kicking in, or just the radio system relaying my presence to the second group.

Conclusion, if you have one big group garrisoning different buildings, to save resources for example, probably all the units will engange and leave their positions eventually. If you have individual groups for individual buildings though, the experience is good and solid overall.

The last thing I tried, was to give every group a HOLD waypoint, trying to avoid sys_danger from using those groups. Unfortunately, further testing is required. I haven't seen a significant difference, but I only had time for one run. The group directly engaged showed no difference at all (as expected), but no other group became active.

[Robalo 465]

Already added a check and won't get groups to move if they have any stopped member. Will be in update soon after I test some other changes.

But reading notes from here it is normal that doStop'd units go out and engage.

[seba1976 98]

Have you confirmed that doStop'ed units return true when checked with stopped? The wiki only mentions units stopped by the stop command. And, I have some differences with some of the notes in the wiki regarding doStop. The most glaring one, units do not leave their positions when not engaged, despite what the wiki says:

doStop'ed units WILL return to formation if their leader's behaviour isn't set to "COMBAT".

Anyway, this type of things usually change all too often and without warning so...

[Robalo 465]

Have you confirmed that doStop'ed units return true when checked with stopped? The wiki only mentions units stopped by the stop command. And, I have some differences with some of the notes in the wiki regarding doStop. The most glaring one, units do not leave their positions when not engaged, despite what the wiki says: Anyway, this type of things usually change all too often and without warning so...

Right, actually stopped is not a good check but unitReady is. About the other thing, how I understand it works:

- at first AI are not in combat. You cat stop them in order to position them how you like.

- enter combat, they leave position as ordered by TL or by god of combat mode

- exit combat when clear, they return to formation

[seba1976 98]

Oh right, unitReady, I always forget it. Well then, waiting for the update.

What about the HOLD waypoint though? Will it suffice to avoid sys_danger to give order to those units?

[Robalo 465]

Oh right, unitReady, I always forget it. Well then, waiting for the update.

What about the HOLD waypoint though? Will it suffice to avoid sys_danger to give order to those units?

waypointType [_grp,_cwp] != "HOLD" ... check :)

[seba1976 98]

waypointType [_grp,_cwp] != "HOLD" ... check :)

Great.