Improve anti-vehicle responses

[rekterakathom]

When merged this pull request will: Add new function to find units with vehicle-capable launchers

1. Describe what this pull request will do Adds a new function that finds units that have vehicle-capable launchers (light AT, anti-air or heavy AT), and implements it into various anti-armor routines that previously only checked if units have secondary weapons. This is an important distinction, because various mods and CDLC's add secondary weapons that are not intended for AT usage. E.g, RHS's RshG-2 or the flare launchers in Prairie Fire.

The function can also account for submunitions, but this behaviour isn't used in this PR because I don't know if AI cares about the submunitions when deciding whether to engage. Disposable launchers from RHS for example are also completely ignored, but I don't consider this a huge flaw because in my testing AI refuses to use them anyway.

Also minor improvements in fnc_tacticsHide , such as making units target the vehicles themselves instead of crewmembers, and adding logic to ensure that AT units don't engage air vehicles and AA units don't engage ground vehicles.

Closes #362

2. Each change in a separate line
   • Add new function lambs_main_fnc_getLauncherUnits
   • Implement getLauncherUnits into fnc_tacticsAssess
   • Implement getLauncherUnits into fnc_tacticsHide
   • Differentiate between AT and AA launchers in fnc_tacticsHide
   • Implement getLauncherUnits into fnc_taskRush

[nk3nny]

Interesting stuff. We'll be looking more closer at this.

[rekterakathom]

the aiAmmoUsageFlags and caching are from my pov here the biggest issue we should reuse the system that I implemented in #365. i also expect that that is the reason why you don't get RHS Disposable lauchers to work because aiAmmoUsageFlags is not a string but a number

Not going to comment on the aiAmmoUsageFlags datatype, already mentioned in the conversation above.

The RHS disposable launchers might or might not work with this PR. What I meant in the original post was that RHS disposable launchers do not work with vanilla AI, they will not use them at all. Probably because they are technically empty until equipped, so the AI probably doesn't understand that it can be used.

I thought about making a cache for this, but config lookups here are so fast that it is a micro-optimization at best.

This takes ~0.0030ms, which goes down to ~0.0027ms if the variables are removed

// Execute while holding a loaded launcher
private _mainAmmo = getText (configFile >> "cfgMagazines" >> (currentMagazine player) >> "ammo");
private _mainAmmoFlags = getText (configFile >> "cfgAmmo" >> _mainAmmo >> "aiAmmoUsageFlags");
_mainAmmoFlags

Simply calling something with parameters already takes up ~0.0014ms

["asdf", 0] call {params ["_string", "_number"]}

It is possible that the config lookups are only fast due to some config caching built into the engine that makes it fast in a benchmark like this where the same config gets accessed rapidly, but I still believe that the config lookups are not what is slowing this function down.

I didn't look into your caching system while the PR was still open, but now I did and I believe that it is currently bugged.

Check the following input to your function:

["M_Vorona_HEAT", 2] call lambs_main_fnc_checkMagazineAiUsageFlags;
["M_Vorona_HEAT", 128] call lambs_main_fnc_checkMagazineAiUsageFlags

This will return false despite "M_Vorona_HEAT" having the 128 flag set. In addition to this, I don't believe that it would be much faster than the config lookups anyway, due to all the overhead that comes with calling it.

[jokoho48]

This is not a topic of Performance but one of working correctly where we need always first to make sure that it does work correctly. and because aiAmmoUsageFlags is not a always a string or maybe a differently defined string we should always go for correctness.

and for the report that lambs_main_fnc_checkMagazineAiUsageFlags does not work. it needs to magazine not the ammo and M_Vorona_HEAT is the Ammo and not the Magazine is using Vorona_HEAT returns the expected Value

[nk3nny]

I suspect you are talking around one-another. Nothing serious in the big picture-- though using the new function would put it more in line with the direction we are going now.

Regardless. I'm having some trouble getting lambs_main_fnc_getLauncherUnits to correctly identify the TitanAA weapon carried by the humble "B_soldier_AA_F" (NATO AA trooper). It is quite late here, and I did test with ACE3. Perhaps I'm doing something wrong?

[rekterakathom]

This is not a topic of Performance but one of working correctly where we need always first to make sure that it does work correctly. and because aiAmmoUsageFlags is not a always a string or maybe a differently defined string we should always go for correctness.

and for the report that lambs_main_fnc_checkMagazineAiUsageFlags does not work. it needs to magazine not the ammo and M_Vorona_HEAT is the Ammo and not the Magazine is using Vorona_HEAT returns the expected Value

I seem to have some problem with my installation of the current lambs dev release because lambs_main_fnc_checkMagazineAiUsageFlags is nil for me, hence why I've declared it in this screenshot, but I have not altered it in any way other than removing the macros. The first passed flag check is what gets cached, not the flags, hence the incorrect return in this screenshot.

I suspect you are talking around one-another. Nothing serious in the big picture-- though using the new function would put it more in line with the direction we are going now.

Regardless. I'm having some trouble getting lambs_main_fnc_getLauncherUnits to correctly identify the TitanAA weapon carried by the humble "B_soldier_AA_F" (NATO AA trooper). It is quite late here, and I did test with ACE3. Perhaps I'm doing something wrong?

Tested, and indeed, lambs_main_fnc_getLauncherUnits fails. This is actually caused by the ammo usage flags being a number for M_Titan_AA. lambs_main_fnc_checkMagazineAiUsageFlags would most likely fix this issue, once the cache is fixed.

The pull request for that function has already been merged though so I can't make suggestions on it anymore. I would highly recommend that the function gets looked at thoroughly and actually tested, especially if its reason for existing is to be a reliable and correct way of getting the flags. In the future, consider practicing the same level of scrutiny for author pull requests as you do for non-author pull requests.

[jokoho48]

Good catch https://github.com/nk3nny/LambsDanger/pull/382 should fix that. but the reason why you don't have the function in this PR is because you need to merge master 😄

[rekterakathom]

Good catch #382 should fix that. but the reason why you don't have the function in this PR is because you need to merge master 😄

I'll test that PR when I get done with school stuff for the day, but from a quick inspection it should work. I didn't test on this branch, just downloaded the dev version from steam and tested with that active, but steam had some trouble (as always) and apparently didn't update the mod so I was actually on 2.6.0 ...

And the change to lambs_main_fnc_checkMagazineAiUsageFlags on this branch coming soon™

[rekterakathom]

lambs_main_fnc_checkMagazineAiUsageFlags is now implemented, couldn't use it for the submunitions though. That would probably need yet another change to lambs_main_fnc_checkMagazineAiUsageFlags to make submunition checking possible through it, and I don't think that is required for 2.6.1 at least, it can be implemented later if the submunition checks are found to be of any use. So consider submunition stuff experimental and not-recommended for now.

This is currently mergeable with master branch but will be bugged until #382 is merged.

Verified that the Titan AA launcher is properly detected when this is used alongside #382.