I love you pasik, bro. But I need your help:



1. I would assume monitor means something like watch or remember but it's not entirely obvious in the context of to_stab_while_peace. Is dot_range basically just radius to the enemy here?




2. Check seems pretty obvious except for supplies and team. I'm guessing check_cover_status is handy for when an AI's cover is removed, and cover_over_shootability tells the AI if it can fire from cover (pop-up)?




3. Not sure what with_muzzle means.




4. Is this for AI calling in artillery and such?




5. I'm guessing separation is the desired radius for AI to distance itself from other squad members (bunching up/spreading out). What exactly does leaving_cover mean? And boosted_fighting?




6. This one eludes me. :[
THIS must be the combat mode timer, huh? :]




7. Is in_trenches something special or just another way of saying in combat mode?
And THIS one eludes me. :[




8. What does run_limit mean?

_________________
██████████████████████████████████████████████████████████████

██████████████████████████████████████████████████████████████
~ * ~ * G R E Y * ~ * ~ * P R I D E * ~ * ~

monitor_enemies_to_stab_while_in_peace actually refers to a time interval used to check for nearby enemies to fight against in stab range when it's peaceful aka non alert.

monitor_enemies_max_dot_range is used to control the sector of sight. It's somewhat obscure what it is because of still hardcoded offsets and multipliers that are applied on it, e.g. night time works as an additional 0.75 factor on it. Let's just say that 2.0 would result in capability to see full 360 deg sector in day time against standing / running targets. 0.0 should be the other end, having no sector of sight I believe.



Supplies check isn't much used as the grenade fill boxes don't exist anymore. Team check is used to look for a more appropriate squad to join.

In addition to cover being removed, check_cover_status also checks if someone else is occupying the cover, which can make one of the bots pick another cover spot if such is available.

cover_over_shootability, yes.

Most of the interval based parameters aren't that useful, they exist to avoid having bots check everything every AI update cycle, improving performance and removing some decision pingponging. Making the times lower can improve their reaction times tho.


with_muzzle makes it possible to spot a shooting enemy from farther away than non-shooting enemies, works with enemies not using a suppressed weapon.


Yes. Before they were calls, they were mortar strikes. The value works as a minimum time of no calls, it's faction wide.


Yup, separation is exactly that.

Leaving cover separation just activates when a bot is leaving cover. Leaving cover happens after a bot has first actively taken cover and reached the target spot, then after a small random time the bot will leave the cover to take a new look to decide what to do next. Seems the random time range is not exposed yet, my bad.

A bot believes to be in a boosted fighting mode when the leader has issued a command boost. Only player leaders do that, by multiclicking squad command at a single spot. The leader typically says "quickly" when the boost (re)starts.


That is used as a minimum timer to stay in fighting state if a bot detects an enemy while the area is not alert. The intention of this is that the bot will open fire, and the fighting state must stay active at least for the fighting reaction time to pass for the first shot to be actually made.

Maybe that could be used as combat timer too, but I'm guessing it then works so only in a case when the bot detects an enemy non-alerted, it won't work as combat timer if it's the enemy who opens the fire.

The real combat timer is more likely to be "min_fire_open_time", but seems it's not among the exposed parameters. The current value is 8 seconds.


The bots change to a different set of following parameters when they believe to be "in trenches", basically it activates anytime there are walls in way of movement, and it rechecks it & attempts to deactivate after that given time.


Some parts of the AI logic make the bots change to running from walking if they are farther than a threshold value from a target, and vice versa. That value is run_limit + run_limit_margin to start running, and run_limit - run_limit_margin to start walking.

I'm wanting to make the AI more entrenched when it comes to fighting so they'll be a tougher nut to crack. By default, it seems like if an AI is taking cover behind an object it can't shoot over then it stops seeing the enemy (unless the enemy is firing), and then proceeds to leave cover. Is there a way to make the AI not so line-of-sight dependent on engaging enemies? Anything to increase effective use of cover when it matters rather than charging out and getting killed when it's still dangerous for them?

Also do AI changes have an effect on the simulated battles?

_________________
██████████████████████████████████████████████████████████████

██████████████████████████████████████████████████████████████
~ * ~ * G R E Y * ~ * ~ * P R I D E * ~ * ~

While taking cover, the AI has its weapon handling active, so they should be shooting against targets they have. I think I also added some logic that the AI would see through the cover providing element in front of him even if it's that high that he doesn't see over it, but not absolutely sure if I actually added it or if it works. Anyway, it would seem you'd at least want to control the time they spend in taking cover state, but of course that had to be one of the parameters that I missed exposing the last time.


No.

Consider using_cover_min_time, using_cover_max_time and fire_open_min_time added for next version.

Thanks. :]

I've got some other questions though and they don't all pertain to default.ai.

I found this description of simulation you made a year ago here:

1. Given the addition of the miniboss groups, has this changed at all? Would Rambo succeed against a platoon of browns in a simulated war zone?



It looks like there's some potential to have different 'personalities' or varying combat behavior and skill for the AI using groups with different .ai in the faction xml. I figure I could make a new group for each type of soldier but I wonder...



2. Would these work the same way randomly/specifically assigning a soldier model does? :|




The rest of these questions have to do with some ideas of mine, like having an AI bro that sticks around for the rest of the game.

3. I'm trying to find a way to have a designated AI group that will only join the player's squad. Does anything exist for that?



4. I'm also trying to make this special group extremely unlikely to die. It looks like the only way to convert death states to wounded states is via carry_items. However, they're removed upon wounded states. Anyway I could possibly disable this without making a script?



5. Is there a way to use the AI's old grenade refill for other weapon or item slots? Like using a vest crate to re-equip a vest?



6. Wounded soldiers still count toward sector occupation. Can I modify this in one of the scripts? Would it require me to change the script for each gamemode?



7. Anyway to spawn a specific group type? Like a miniboss call-in? Or Is this another job for scripting? :]



8. Finally, is there a way to disable items from dropping on the ground when a character is killed? So if I have a dude that spams grenades or cover, he doesn't leave a huge stack or a special only-for-AI weapon behind when he dies.

_________________
██████████████████████████████████████████████████████████████

██████████████████████████████████████████████████████████████
~ * ~ * G R E Y * ~ * ~ * P R I D E * ~ * ~

It hasn't changed, just soldier count affects how frequently they get firing chances in a simulated battle, and, combat vehicles give a boost. No chance for Rambo here.


No, they wouldn't; there's just one AI parameter set in a soldier group, so your method of achieving weapon specific personalities is by having lots of soldier groups.


I remember adding an XP offset value to control favoring a player leader over a bot, will need to check if it's in and exposed.


I'd think a vest always becomes consumed unless it has transform_on_consume="x" declared, it shouldn't be tied with wounding specifically, but I could be wrong too.


No.


Can't see a way to directly disable wounded soldiers being counted for capturing with a mod, but with some serious hacking you could do something to make a script kill the wounded soldiers e.g. when countdown starts running / reaches a specific threshold.

Quick matches can do scripts starting in 0.98. Your mod's overlay folder would have a script entry point for both quick match and campaign, injecting your piece of script in the framework provided by vanilla.


It's possible. The instance_key property in a call's round specification accepts soldier group names. Vanilla should already have paratrooper calls guarantee at least one medic through use of soldier groups.

Similarly other spawning mechanics, through use of a weapon (like deploying), through a projectile result (spawn instead of blast..) or spawning bound with any vehicle events should be able to do soldier group spawning. Also can be done via scripts.


Hmm no. That would be a handy feature for mods. I'll add some logic for it for some version.

Is this it?



Ok, I figured out what I was doing. Vests can indeed survive wounded states, but I was trying to make it loop and it can't transform to the same carry_item more than once. So this isn't a problem really as I can just make a really, really long list of transformations.

...I'm pretty good at that. :[

_________________
██████████████████████████████████████████████████████████████

██████████████████████████████████████████████████████████████
~ * ~ * G R E Y * ~ * ~ * P R I D E * ~ * ~

favor_joining_player_squad_value_increase, that would sound like the one I was after. That should make a player as leader more attractive than the player's XP would normally imply.


Hm, looking at the sources, can't see why a loop wouldn't work. I would expect even a single item transform loop to work, but if not, at least two should work. Maybe I'm just overlooking something.