7 replies to this topic

[troubadour]

In Dow AI code, I have noticed that there are many lines such as :

local infantry = Ability.Filters.CloseInfantryEnemy( squad_pos, 15, 1 )
local vehicle = Ability.Filters.CloseVehicleEnemy( squad_pos, 10, 1 )
local commander = Ability.Filters.CloseCommanderEnemy( squad_pos, 10, 1 )

They are used to retrieved a specific unit in range of squad_pos, but what is the difference with :

local oEnemyUnit = cpu_manager.cpu_player:FindFirstEnemy(vSquadPos, iScanRange, 1)
oEnemyUnit:GetStats():GetClass()
and then checking the GetClass() returned value

Because it seems to me the Ability.Filters thing is more "elegant" vs FindFirstEnemy(), is there a major performance cost when using Ability.Filters ?
Do these 2 piece of code do the same thing ?

[ArkhanTheBlack]

Because it seems to me the Ability.Filters thing is more "elegant" vs FindFirstEnemy(), is there a major performance cost when using Ability.Filters ?
Do these 2 piece of code do the same thing ?

The ability filter functions are just wrapper functions using the SCAR function cpu_manager.cpu_player:FindFirstEnemy(...). Some of them contain some security checks to avoid CTD's or other unpleasant things. The general guide line is to use an ability filter function if one is available. However in some cases it is necessary to use the basic cpu_manager.cpu_player:FindFirstEnemy(...) function directly.

If you use expressions like oEnemyUnit:GetStats():GetClass(), you have to make sure that oEnemyUnit is not NIL (=> Execution error) and the unit has stats which is only the case for the active player units (=> CTD)...

[troubadour]

ok will do as you said, thank you for your quick answer

i am also having a look at tactic and infantrytactic files, in infantrytactic:Update() function it may be a good thing to perform checkfordeath() before checkforbroken(), checkfordance() because as a rule of thumb retreat shall be done when the squad is low on health no matter if it is morale broken or dancing, what are you thoughts on this subject ?

[thudo]

I've been working with unit tactic files and I find its best to give each unit its own personal tactic file as it seems to make the AI more readily there to use it. Further, I've noticed the faction's own "function TSInfantryTactic:AddTargetAbilities()" is not inherited when a unit uses its own tactic file and wants to use an ability it has from that AddTargetAbilities() section. Not sure why so I have to also script the ability in the unit's own tactic then its fine.

But generally I find it units have their own tactic files like we did in v3.10 of the Advanced AI for SS then the AI more cleanly uses the unit's tactics.

[troubadour]

What is the difference between IsAttacking() and IsInCombat() ?
IsInCombat() returns true only when CC fight happens ? IsAttacking() returns true when units are firing at sthing ?

@Thudo
One file for each unit type would be a huge step toward a more oriented object conception and would allow to remove a lot of specific tests and would make the code easier to understand, and changing a derived method in one class would be less risky to break something in another class

One question in the InfantryTactic:Update() function there is a call to self:InitAbilites() but it is already done at the end of the Tactic:__init() so i think it can be removed form InfantryTactic:Update() function unless i am missing sthing

Edited by troubadour, 19 January 2009 - 03:49 PM.

[ArkhanTheBlack]

What is the difference between IsAttacking() and IsInCombat() ?
IsInCombat() returns true only when CC fight happens ? IsAttacking() returns true when units are firing at sthing ?

IsAttacking() returns true if the unit is shooting or attacking/fighting in CC. IsInCombat() is very general. It returns true if IsAttacking() returns true, but also if it is 'hit'. I think it also stays a few seconds true even if a combat situation is over. It's possible that it's also true if an enemy unit is close, however that's just a guess. Like I said, it's very general and can be interpreted as a combat situation of any kind.

One file for each unit type would be a huge step toward a more oriented object conception and would allow to remove a lot of specific tests and would make the code easier to understand, and changing a derived method in one class would be less risky to break something in another class

90% of all tactic files are for unique units. But units without special abilities usually don't have a unique tactic file because they can use a general tactic, and all unique tactic files are derived from a general tactic file. Therefore the concept IS clean, however as soon as you want to add some special behaviour stuff for a unit without a tactic file, you have to create a new one and add some management code to the loader files. If you don't do that every day it can lead to errors because you've accidently forgotten something. If every unit already has a unique tactic file even if doesn't need one, then you don't have to add the management code anymore which reduces the risk of making mistakes. However, this doesn't have anything to do with the object oriented concept.

One question in the InfantryTactic:Update() function there is a call to self:InitAbilites() but it is already done at the end of the Tactic:__init() so i think it can be removed form InfantryTactic:Update() function unless i am missing sthing

Just a hint: Remove it and then try to reload a saved game. You will get some 'interesting' results .

[troubadour]

Hi Arkhan, thank you very much for your detailed answer and hints, always welcome and usefull.

I have another question reg InfantryTactic:Reinforce() function, what is the use of the check self.m_bPowerCos when a lot of classes just make a check vs Tactic.Options.can_reinforce, i am not a genius and is quite difficult to make an educated guess.

[ArkhanTheBlack]

Ah, sorry for the late answer, I recently moved to another place and my internet connection isn't working yet, so I have to check the forums during work .

I don't have the code present, but if I remember right, then there's a tier check nearby which ensures that in T1, when saving power for T2, only units are reinforced which have no power cost.