Closed jzy-chitong56 closed 1 month ago
Not sure what you asking. there isn't any distortion possible as the counter unit changes with the strategy change logic.
GetUnitCountDone is correct otherwise it will be building too many dynamically if its started building the previous number. Its supposed to be only a few more units when strategy logic is complete, otherwise the constant incrementing will make its priority overpower all strategies as that increases based on quantity of units to build.
I'm not sure if using translation to express this question, I'll try stepping in
Step first, countermeasure type 1 Step two, countermeasure type 2 and so on
You can see that every time the calculation is completed, the same variable is used to capture the calculation result
There is no mutual locking between steps
That is to say, once I capture the result of the first step, with each subsequent step, the result may be replaced. This creates a situation where the subsequent steps remain in effect while the previous ones cannot
I afraid still no idea what you mean, the code is handled within the strategy so when it evaluates a counter unit its done at the end of the strategy not as counter units are being added.
o , then I need look look DynamicStrategySelector
I know
chosen_counter_unit
doesn't need to be reset, but for safety reasons, can I reset it inResetDynamicSystem
DynamicBuildUnit
There is no distinction between types of countermeasures hereIs there a situation where calculations are inputted sequentially without interlocking The system did not analyze which countermeasures to calculate based on the type of enemy or friendly units, but instead calculated them all at once , in order. So, even if some kind of countermeasure is needed, but, when the last countermeasure input is received,
chosen_counter_unit
will be overwritten, resulting in distortion now last isAddUnitToAntiheavyarmor
and why
BuildUnit
useGetUnitCountDone
, maybe shouldGetUnitCount