Ansible2
commented
1 year ago This refactor and testing has revealed that the group limit can be hit quite easily and likely has been during play when users have caused a number of AI groups to spawn rapidly (support calls and killing large numbers of AI at once for example).
It can take several seconds for these groups to actually be deleted by the engine. Manually calling deleteGroup on the group of a unit that has been killed will not alleviate the actual number of groups in the session (count allGroups). Units may have to be removed from the group in order to actually delete them.
One solution might be to create 50 (the current max queued enemies to be active) groups or so at the start of the session and use these in a recycling fashion. This maybe difficult to manage with the AI handler but not impossible. It also may lead to strange behavior of AI because of leader stuff (speculation).
Another solution may be having units join a cleanup group when they die and then deleting the old group they were a part of or reusing that group potentially.
It may also be worth investigating having units spawn in actual groups instead of by themselves, not that this will necessarily fix the issue, but it may be worth implementing if changes need to be made to minimize group numbers anyway. Might be far easier to handle with the group eventhandlers that now exist.
In any case, the stalker system should probably (and likely will need to) be rewritten to accommodate the further refactor.
Lots of functions during the course of a wave could be run in unscheduled but are just called from inside the wave logic functions which are primarily scheduled.
Can at least make use of
CBAP_fnc_direrctCallwhen something big does not need to be scheduled during these functions.