Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve anti-vehicle responses #369

Merged
merged 11 commits into from
Jul 7, 2024

Conversation

rekterakathom
Copy link
Contributor

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

  1. 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

Add new function to find units with vehicle-capable launchers
Only units with appropriate launchers should engage specific vehicles, e.g AA launchers aren't considered against ground vehicles

Also ensure that the target command is issued on the vehicle, not a crew member of the vehicle
Copy link
Contributor

@rautamiekka rautamiekka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some config lookup optimizations, will save up more the bigger the squad.

addons/main/functions/fnc_getLauncherUnits.sqf Outdated Show resolved Hide resolved
addons/main/functions/fnc_getLauncherUnits.sqf Outdated Show resolved Hide resolved
Forgot to change these back to arrays after experimenting a bit, oops
@nk3nny
Copy link
Owner

nk3nny commented Feb 18, 2024

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

@nk3nny nk3nny self-assigned this Feb 18, 2024
Copy link
Collaborator

@jokoho48 jokoho48 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

addons/main/functions/fnc_getLauncherUnits.sqf Outdated Show resolved Hide resolved
@rekterakathom
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Owner

nk3nny commented Feb 19, 2024

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
Copy link
Contributor Author

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.
20240219103002_1
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
Copy link
Collaborator

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 😄

@rekterakathom
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

@jokoho48 jokoho48 merged commit 75d2671 into nk3nny:master Jul 7, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fnc_tactisHide anti-armour routines don't check launcher type
4 participants