ROMM_IA

[Rommel 2]

<span style='color:blue'><span style='font-size:19pt;line-height:100%'>Rommels Improved AI</span></span>

Version 112 by Rommel

This new version of Rommels fMorale/Suppressive Fire Reactive Ai, or the new name: ROMM_IA (Rommel Improved AI). Despite the name changes, has had great improvement. With increased AI reactions, effective suppressive fire, designed for multiplayer and a huge increase in their apparent IQ. :P

Its initial aim was just to make AI's drop to the deck, but over the last few weeks my scripting knowledge has increased and so has this script. It has reached what i wanted to become, and I will only be working on bugs if any are found.

NO GLOBAL VARIABLES + SQF Optimized.

Preview Mission Included which as Surdus' Priest's nearExp resource included (love it.),otherwise feel free to edit, keep base credits if possible please, else its open source and go insane.

HowTo: Implement

A simple init line execution is suffice to include this into your missions.

nul = [group this] execVM "ROMM_IA.sqf";

However for multiple groups use:

<span style='color:orange'>SQF:</span> {[_x]execVM "ROMM_IA.sqf"; sleep 0.25} forEach [group1,group2,group3];

<span style='color:purple'>SQS:</span> {[_x]execVM "ROMM_IA.sqf"; ~0.25} forEach [group1,group2,group3]

HowTo: DAC v2

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _Events_Unit_S =

[

["[_group] call compile preProcessFile "ROMM_IA.sqf""],

[],

[],

[],

[],

[]

];

This will launch the script afterBuildUp in the Dynamic Ai Creator (v2), this area can be found in DAC config folder (config_events.sqf)

Download (v112.2):

http://pb.6thsense.eu/pb/89 (debug version (112))

http://www.ofpec.com/forum....ch=2619

[General Barron 0]

The very first time I ran the preview mission, I got an error which of course I didn't take a screenshot of. It said something about this line:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _gameLogic action ["useWeapon",_x,_x,1];

I believe the error was saying that something was an array, not object. Of course, I haven't been able to repro the error anymore .

----------

Aside from that, it looks pretty good. It might help to know exactly what improvements this script is supposed to have, so far I only really noticed that the AI will fire randomly into the terrain around them when they know you are somewhere, but can't see you. This feature is pretty nice, but I'm keen to know what other possibilities the script has.

Overall, very clean and nice script!

[Rommel 2]

Weird... I had that come up once, but that was a long time back and It hasn't come up since, doesn't seem to effect the script at all, but I have seen it.

In any case I fixed the "all dead" bug, when all the units in the group died it would bug due to a > instead of <.

The shooting around the area when they haven't sourced your fire is a fault of ArmA, regardless of how much I let them know, they seem to still delay a long time in recognizing you.

Anyway, once they realize where you are, you should notice they will fire in and around your position, and you should have the ability to pull back and appear some where else whilst they suppress your old position, but if they see you they'll shift their fire across.

They will also take cover appropiately (best checked in a mission for real changes). Tactically assault your position, and flank you. They also react and take cover in presence of helicopters and other mean machines so to say. (Tanks/Planes).

[lecholas 2]

Works form me. I don't have time to test it extinsively now but I have some first impressions.

Well, it's very nice. But to be honest it could use a lot of improvements. I was testing similar solutions for suppressive fire for about half a year so I have some thoughts. For example snipers shouldn't suppress (i think) - but that's a detail. Another thing - this time it'a a major one - is detecting when soldiers should use suppressive fire and when they should stop it. Now (using your script) I was able to stay in the open and fire at the enemy while they were only suppressing me and not firing directly at me for about half a minute. When they can shoot stright at a target they should stop suppressing and start firing directly at the target. If only we had a command to check a LOS from one unit to its target (there is such a function in VBS2). Another thing is that from my experience with 'action useWeapon' command loops using it prevent unit from effectively changing its target. I mean try to fast loop: #loop; _unit doTarget _target; _gamelog action ["useweapon", _unit, _unit, 0]; ~0.1; goto "loop"; where _target will be a moving target. You should find out that _unit will not follow the _target but he will be shooting at the first location he was pointing. Another thing is determining wether a unit should use suppressive fire depending on how much ammo he has. Suppressive fire drains a lot of ammo very fast. Another thing is better taking cover management (e.g. hiding behind a rock and popping out only to fire some shoots and hidding again). If you saw my clumsy SemiAutomatic defensive positions sqs script on OFPEC you know what I would try to aim for.

Can't wait to test it more.

[sickboy 13]

Hi,

Nice job as usual

Really amazing! Been playing it for a while now, and together with airange/accuracy modifications this is just the bomb! (DAC Included )

Few things after quickly skimming the scripts:

[*] Client\init.sqf:

This script will always remain running on the server, simply because you have waitUntil {!isNull player}, I would try to keep scriptHandles to a minimum and thus I would recommend using:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if (isServer && isNull player) exitWith {};

waitUntil {!(isNull player)};

[*] Shouldn't the DAC initialization be: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">["[_group] spawn compile preProcessFile 'ROMM_IA.sqf' "]? And also in the first event list (init) instead of the last one (buildup), as the script continues to run even when the group is not built-up, due to the fact that the groupLeader always runs around, even when the group is not built up. So after each build up, the script would actually be running multiple times on the same group?

[*] client\NearExp.sqf:

You use a global variable NearExp, while you can use local variable _NearExp

[*] Wouldn't it require less memory if you would preCompile the _functions in ROMM_IA.sqf, and call those, instead of having each script instance, compile the full script incl the same functions, over and over? (I only know that call compile preProcessFile doesnt recompile the file a second time etc, but execVM I think still does)

[*] Might be an idea to remove the dynamic _gameLogic creation, and use a general gameLogic acting for debug messages etc. In any case you could use createVehicleLocal which will not propagate the object over the network

[*] Seems there's an exitWith that exits the wrong scope, shouldnt: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if (_count < 1) exitWith {};

sleep 3;

};

be:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> sleep 3;

};

if (_count < 1) exitWith {};

?

[*] Might be an idea to use if (...) exitWith {};   instead of the huge if (..) then { .. } else { .. if (...) then { } else { } }; etc, example:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

     If (nearestObject [leader _group, "BulletBase"] distance leader _group < 30) then

     {

           _nObj = nearestObject [leader _group, "BulletBase"];

           _dir = getDir _nObj - 180;

           

           If ((_dir < _groupDir + 45 AND _dir > _groupDir - 45) OR (_dir > _groupDir + 45 AND _dir < _groupDir - 45)) then

           {

                 [_group,_dir] call _fCore;

                 sleep 11;

                 _checkPoint = _time + 90;

           };

     }

     else

     {

           If (nearestObject [leader _group, "GrenadeHand"] distance leader _group < 20) then

           {

                 {[_x, _inCover] spawn _fCover;} forEach units _group;

                 sleep 11;

           }

would then become:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">// bogus scope so that the exitWith exits this scope, and not the whole while scope

if (true) then

{

     If (nearestObject [leader _group, "BulletBase"] distance leader _group < 30) exitWith

     {

           _nObj = nearestObject [leader _group, "BulletBase"];

           _dir = getDir _nObj - 180;

           

           If ((_dir < _groupDir + 45 AND _dir > _groupDir - 45) OR (_dir > _groupDir + 45 AND _dir < _groupDir - 45)) then

           {

                 [_group,_dir] call _fCore;

                 sleep 11;

                 _checkPoint = _time + 90;

           };

     };

     If (nearestObject [leader _group, "GrenadeHand"] distance leader _group < 20) exitWith

     {

           {[_x, _inCover] spawn _fCover;} forEach units _group;

           sleep 11;

     };

};etc... To my opinion this gives a nicer overview of code, not sure if it would really matter in terms of performance.

[Sonsalt 0]

This is just some shot in the dark, but would it be possible that the players dispersion gets increased while suppressed too ?

[Guest]

New version frontpaged at the Armaholic.com homepage.

The Armaholic.com download page can be found here:

http://www.armaholic.com/page.php?id=3053

[nikita320106 0]

wow)

i'm really big fan of you job))

thanx alot)

[gunterlund 0]

In the DAC example I think you may have one extra set of "". It wouldnt work with them in for me.

[imutep 0]

Thx Rommel

Mirror from Assault Mission Studio

AI Suppressive Fire Reactive 1.10

Regards

Imutep

[Heatseeker 0]

The demo was fun, but i think the a.i. will run out of ammo quite fast, im going to see how its working with DAC, seems very promissing, thank you .

[xawery 0]

However for multiple groups use:

<span style='color:orange'>SQF:</span> {[_x]execVM "ROMM_IA.sqf"; sleep 0.25} forEach [group1,group2,group3];

<span style='color:purple'>SQS:</span> {[_x]execVM "ROMM_IA.sqf"; ~0.25} forEach [group1,group2,group3]

Forgive my noobishness but this should be added to init.sqf, right?

Let's say I want to execute this script for all groups in the mission. Would it be possible to replace the group1,group2... array with a list? In other words, if I put a huge trigger on the map which is activated by anybody and then use the list command:

Quote[/b] ]_tlist = list _triggerOne

...would the following work then?

Quote[/b] ]{[_x]execVM "ROMM_IA.sqf"; sleep 0.25} forEach _tlist;

[sickboy 13]

However for multiple groups use:

<span style='color:orange'>SQF:</span> {[_x]execVM "ROMM_IA.sqf"; sleep 0.25} forEach [group1,group2,group3];

<span style='color:purple'>SQS:</span> {[_x]execVM "ROMM_IA.sqf"; ~0.25} forEach [group1,group2,group3]

Forgive my noobishness but this should be added to init.sqf, right?

Let's say I want to execute this script for all groups in the mission. Would it be possible to replace the group1,group2... array with a list? In other words, if I put a huge trigger on the map which is activated by anybody and then use the list command:

Quote[/b] ]_tlist = list _triggerOne

...would the following work then?

Quote[/b] ]{[_x]execVM "ROMM_IA.sqf"; sleep 0.25} forEach _tlist;

No, because you supply unit objects instead of groups.

Basic solution:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

{ if (_x == leader _x) then { [group _x] execVM "ROMM_IA.sqf"; sleep 0.25 }} forEach (list _triggerOne);

[Rommel 2]

Sorry for the lackOf replies. Just been busy thats all, I've been monitoring the bug reports/suggestions made from various people across the threads.

Some ingenious fixes have come about and I may just update it once more, with credits going to: Sickboy, johnnyboy and I'll make some various bug fixes regarding a group check error once all dead and a few improvements, and if I'm really feeling generous for my new mission, I might chuck in a feature that may more suit the name of "improved ai".

We'll see. Keep up the posts lads, its quite helpful. Ten fresh eyes beats ten hours of used ones .

[CameronMcDonald 146]

A good script, Dan. It seems ArmA scripting is now WAYYYY beyond whatever little grasp I had on it in OFP, but I don't care, I'm too busy wrestling normal maps. Keep up the good work, and I would sincerely like to see this as a PBO someday for BIS missions. Kudos.

[xawery 0]

Cheers Sickboy, it works like a charm!

Great script Rommel! The game dynamics are completely different now:)

[sickboy 13]

Awesome news Rommel. Watching this like a hawk.

Already been thinking about a possible conversion to FSM.

Also been thinking about processing all groups in a big loop, and only spawn instances where necessary. It should allow better control over load, and in most situations, there will be a lot less scripts running :-) (Very important with script intensive mods / addons / mission scripts etc).

Or possibly process the units in each loop, and execute things based on their state. However this would probably work mostly identical to FSM

[johnnyboy 3741]

Hey Rommel,

I just had another idea. Instead of deleting and recreating the gamelogic target to refresh the knowsabout, temporarily setposing it 10 meters in front of the shooter might refresh the knowsabout (then setpos it back to the target unit).

If it works, it will remove my performance worries with constantly deleting/recreating.

Will try this tonight if time allows.

[xawery 0]

I'm consistently getting this error:

So, um... what am I doing wrong..?

[sickboy 13]

Rommel I have some more ideas about the IA Script. If you're interested in chatting about it, and if you have Skype, could you maybe PM me your Skype address?

(Mainly for text-chat)

[mattxr 9]

How about an addon version of this which starts for all Ai groups. So no mission modding.. ? like a Server Side Addon...

[sickboy 13]

How about an addon version of this which starts for all Ai groups. So no mission modding.. ? like a Server Side Addon...

I have such version on my hdd, incl taking player groups and groups with vehicles into account. If Rommel has no time, or otherwise wishes so, I could release it.

[johnnyboy 3741]

Sickboy: You might be interested in some possible enhancements to Rommel's cool script that I've uploaded to his other thread on this over at ofpec:

http://www.ofpec.com/forum/index.php?topic=31322.0

It deals with the following issues:

- Preventing wild shooting way off target.

- Preventing sniper rounds firing from rifles on sniper's backs.

- Preventing rifle rounds firing from AT tubes.

- Preventing grenadiers from firing up in the air.

[Rommel 2]

Sickboy, I don't currently have Skype installed, however I will within the hour .

My username: user_daniel92

Skypename: daniel

in other news.

VERSION 112 ARRIVING BY END OF TODAY.

Includes edits of JohnnyBoys ideas, Xeno's and Sickboys.

note: I like your idea of converting this to an FSM, however I will have to talk to you about implementing this, 112 has a lot of changes and I'm constantly learning.

EDIT:

@JohnnyBoy, your edits are great mate, however they cause my computer to crash a lot!?

I've re-structured/written the entire script (again) with a new set of things to look over.

[johnnyboy 3741]

Rommel:

I did most of my testing on a smaller mission with only a few units, but recent testing on the original test mission that I modified is crashing for me too (one out of five times). So I too recently discovered that running my modified script version on many units simultaneously is crashing.

Here is my current findings:

1. The crashing is coming from the code that deletes the target game logic and re-creates it. If this occurs every loop iteration, ARMA gets messed up (maybe runs out of memory?).

2. Unfortunately, combining the technique of deleting/recreating target game logics, with mando angles controlling when suppressors shoot, was giving the optimal desired result of consistent suppressing fire, that also never fired at a wild angle distant from the target. But crashing is unacceptable of course, so deleting/recreating gamelogics is no good.

3. Combining your script with Mando Angles alone prevents wild shooting, but also results in approximately 50% reduction of actual shooting. I commented out your "fired" globalchat to reduce chat messages, and added a count of times fired (when mando angles test true), and a count of times NOT fired (when mando angles test false), and displayed these counts after the loop. Often one unit would shoot 40 times and not shoot zero times. Another unit would NOT shoot all 40 times. Others were mixed. So with the mando angles technique alone, you get much less suppression fire on target (but get no crazy shooting 90 to 180 degrees off target). So its a trade-off.

Increasing acceptable angle deviation, will increase times fired.

For me, I would rather never see crazy AI doing something nonsensical, as it breaks immersion. Maybe increasing the number of units that are assigned as suppressors by one or two, would get more suppression fire going...

4. I believe the code removing/restoring ammo is having no noticeable negative effects on performance (so only positive effects of not seeing AI do weird things).

5. I tried a test of deleting/recreating target game logics on every 3rd or 4th iteration of the loop. This greatly reduces chance of crash, but also reduces rate that units will fire based on Mando Angles check. The longer the game logic exists, the hinkier the knowsabout location is, so the more off mark the shooter thinks the target is. This might work for me (limited applications of suppression scripts), but any chance of a crash means its not industrial strength, so the deleting/recreating gamelogics approach is out I guess.

6. The modified test mission with a line of cover objects and move waypoint for targets is a better test of these scripts, as it demonstrates how suppressors behave when there knowsabout gets more stale. In the original test mission, the 3 MGers are in plain view and usually don't move, so you're less likely to notice the problem of suppressors shooting off at wild angles. Moving target units are much more likely to result in inaccurate knowsabouts, resulting in suppressors shooting way off target.

7. Instead of deleting the target game logics, I tried temporarily setposing them in front of suppressor (in hopes of increasing suppressor's knowsabout value of game logic), then setposing gamelogic back to target position. It did not seem to help.

Other:

a. Suppressors kill friendly AI who pass in front of them without remorse (quite frequently actually). The same Mando Angles technique could be used to determine if any member of the suppressor's group was directly in front of suppressor, and have the suppressor skip shooting for that loop iteration (and shout "get out of my line of fire!"). Alternatively, since you have code that chooses some units to seek cover, and other units to suppress, perhaps if the cover chosen is to the left, then the right most units are chosen as suppressors (and vice versa), which would reduce the chance of ai straying in front of suppressors.

b. Player should be excluded from suppressor candidate list, else UseWeapon fires player's weapon for him.

Question for anyone: Is there another way to refresh the suppressor's knowsabout value of a target so we can have it all (consistent maximum suppressing fire that is also near target)???

This is a worthwhile effort, and I greatly look forward to your next release and whatever you and Sickboy come up with.