raptoer

I decided to post it independent so it could get some feedback prior to going into the main ASR_AI. They're complicated and determining their full effects and subtleties can be difficult. After a month of not looking at the code I went back and found I barely understood any of it. Also please consider this: The changes we make to the AI have many subtle repercussions that are hard to predict due to the way that we are interacting with the engine. For the most part each change we make requires us to repack the mod, restart arma and reload the scenario. As you can imagine this can make changes a little slow. This is doubly so if you have locality issues to deal with (I managed to bypass dealing with those) because now you have to get 2 clients and a server. It took me probably 1 month to write my changes, then another two weeks here and there to re-write sections of it. There also haven't been many engine changes related to AI for a while, while they did introduce one new scripting command that could have been useful for me it ended up being useless for me.

I don't modify any behavior related to smoke grenades.

Nvg packing works for me, but the AI needs room in their pack for the NVG. Some of the default arma 3 loadouts do not have room for nvgs in neither their vest nor their uniform. I steered clear of most of ASR as it simply didn't interest me. I don't know anything about RHS and I don't use it. The mods are in github so feel free to fork it, change it, and make a pull request to get it back into one of our repositories.

The basis for this mod, ASR AI, handles all that.

Interesting idea, I'll take a look sometime in the next week.

In a 40v40 AI battle I lost 1 FPS (I think it was 26 to 25).

Indeed. It's a matter of where the AI is local to. AI are local to their leader. If their leader is also an AI then they are local to the server.

It's not impossible, but comes with so many caveats that it probably wouldn't work out well. The first is that the AI are very perceptive of danger, and thus will probably attempt to leave long before you expect. The second is how do we define "retreat". If you just want them to run 500m in the direct opposite direction of any armor, that's not too hard; but anything more complicated than that becomes unwieldy. The third is that if we issue a move waypoint then the default danger behavior will re-assert itself and the AI will attempt to take cover. If on the other hand we issue a scripted move then the AI will ignore most everything else going on around them to move. AI mods can only really handle the most general cases, everything else should be zeused, triggered or scripted.

Sadly it all goes together, doesn't really work in pieces. I will add a link to my documentation which should make it more understandable.

Ok Robalo, I've gone ahead and make the pull request to get my features integrated. Go ahead on take a look and make any comments in the pull request itself

I still need to resolve some problems, for example some pieces of cover are getting rejected incorrectly, and it's a pain to debug. Of course I only discover these problems after I tell the world about it.

I still have some more changes coming, but the basic concepts are in place.

Hey there Robalo, I'm pretty much finished with my mod of your mod, called Pooter's enhanced ASR AI. I did it as a fork of your git repository. I have only changed the behavior invoked by danger.fsm. Every file I added is prefixed with fnc_pt_ . I also changed danger.fsm and added some lines to XEH_preInit to set some default values. AIs now counterattack if attacked (and then left alone) Ais now find individual pieces of cover to hide behind (leader does the picking). Ais in buildings now maneuver in response to inbound fire. (they'll either go down a pos or move to a different part of the building, depending on visibility) This whole experience has left me rather tired of the limited capabilities that we have as modders. They gave us just enough to see what is possible, without actually letting us change any core components. I have found that most of the combat behavior attributed to AI mods is just caused by the mod poking the default AI to get it to behave. What I would really like to work on is the AI visibility calculations, but sadly those are somewhere in the engine and can't be easily changed without the source. I have a feeling that the visibility calculations are relatively simple, which makes them easy to debug and cheap to run, but causes the AI to have laser eyes (or at least not act even remotely human). Let me know if you want me to make a pull request, or have any questions.

I discovered this when in single player I alt-tabed when an AI was moving to cover. The AI stopped when I tabbed back in. The movement timeout had been triggered because it counted the time I was alt-tabbed out. If there was some other issue with the time command then it is most likely a bigger issue than this. In MP if a server is lagging badly enough to desynchronize diag_ticktime and time then it will be unplayable anyways.

I don't think we can really change how danger.fsm gets called, the engine handles that. I'm actually working on a modification of ASR AI, and I have looked through most of the code. I have noticed that you seem to use diag_ticktime, which I'm pretty sure is incorrect in these instances. diag_ticktime gives wall time, but if either the server lags or I alt-tab in single player, this will be desynchronized with game time, thus producing unexpected behavior. I intend to modify the way the AI react to danger, and leave everything else as is. Right now I have a design for what I want them to do, and a much fancier cover selection algorithm. It uses the models instead of asking the engine to find an empty position. I am worried that my cover selection algorithm might be too slow though, as it uses line intersections with objects, and will use on average about 10 per piece of cover evaluated, but it could be much more for certain pieces of cover. Fancier is not always better with these kinds of things. I would have never considered trying to make an AI mod without ASR AI to use as a base, and perhaps some of my ideas will end up being merged into it later. I've forked the project on github, but I don't know how fast my changes will come in, my time has been stretched rather thin lately.

Has anyone else notice a difference between how danger.fsm gets called between versions 1.47 and 1.48? When I was using 1.47 every single shot I fired even remotely near an AI would trigger it, but in 1.48 the first bullet triggers it, but after that the bullet must pass within ~1m of the AI and must pass by the AI, if the bullet hits the ground first then it will not trigger.

Hey there Robalo, I've been working on my own AI mod loosely based on ASR AI. I've hit a bit of a snag in the form of Danger.fsm, namely that it seems to be very inconsistent when it gets called. I have tested this by adding a bit of code at the beginning of Danger.fsm that prints to global chat for every item in the queue. DCEnemyDetected seems to work fine. DCFire seems to be called when they get shot at but aren't aware of the shooter. DCHit seems to work fine DCEnemyNear seems to work fine DCExplosion counts bullet landings sometimes, but not explosions from grenades DCDeadBodyGroup works fine. DCDeadBody works fine DCScream They react to their own screams rather than the screams of others DCCanFire I have never seen DCBulletClose works some of the time, but I can't find any sort of pattern for when it fires. At this point I'm considering throwing out DCFire, DCExplosion, DCScream, DCCanFire, and DCBulletClose. I could probably get a better result by just using event handlers and vector math to determine who should react instead of relying on the engine to call danger.fsm.