Unit Categories

[krogothe]

How do unit and badtarget categories work? Its an unsigned int, so i take it uses each bit in the byte to set a flag for each category, but which one is which???
eg im trying to find what units are purely Anti Air on absolute anni:

CORRL gives me 64
ARMFLAK gives me 8
ARMYORK gives me 256
ARMCIR gives me 1

not cool...

[Argh]

Why not just get the weapons that are assigned to a unit, and cross-reference it with the FBIs that are toaironly?

[krogothe]

because some units have that tag disabled but still are Anti air only, according to Caydr, since they are scripted in the cob file or something

[Kelson]

How do unit and badtarget categories work? Its an unsigned int, so i take it uses each bit in the byte to set a flag for each category, but which one is which???

I assume you mean the badTargetCategory and onlyTargetCategory variables in the CWeapon class (weapon.h)? Line 221 of CWeaponDefHandler::ParseTAWeapon says, "weaponDefs[id].onlyTargetCategory = CCategoryHandler::Instance()->GetCategories("VTOL"); // vtol = all aircraft for now. The next line says it is an air only weapon.

All the other hits I found either didn't change the value and/or assigned it based on the weapon def from above (ie - for each instanced weapon, that onlyTargetCategory is assigned in CUnitLoader::LoadWeapon as onlyTargetCategory = weapondef->onlyTargetCategory & udw->onlyTargetCat).

As far as the value of unsigned int GetCategories(string)...we don't know ahead of time. The code actually inserts new categories as they fail to be found - thus it will be consistent across program restarts, but not across mods and/or mod versions (for example, if Caydr changes up weapon ordering). You can call that static function to access the value to find out yourself, however.

Regarding the scripts only targetting air - you'll have to go check the scripts. You can check the C++ implementation of the CobParsing/Interpreter (CobThread.cpp), but I didn't see anything that pertains to flying objects. The best hint I can give for that is following the weapon data originating in CobFile.cpp (in the initializer function) around line 130. Alternatively, in CobThread.cpp (in the tick function), you might check out the SHOW case - it creates a flare effect for firing weapons.

Sorry I couldn't better pin down that script part - not likely to be a simple, or pretty, solution anyhow. Might be better to test each unit to see "can I hit x?" via the TryTarget function in Weapon.cpp (line 412).

ps) You were right about the one category / bit thing in an unsigned int - too bad the categories aren't hard-coded.

[FLOZi]

It's nothing to do with scripts, its the

OnlyTargetCategory<weapon_num>=<category>

in the FBI, or

toairweapon=1;

in the weapon TDF.

Bear in mind that the former can accept any category, not just VTOL. F.ex. smallarms in AATA will only target units with the 'infantry' string in their category line in their FBI.

[Kelson]

Flozi, everything I commented on was in the TASpring/rts source code - where the program itself decided to allow (or not allow) a weapon to fire at something. I don't imagine Krog'd like to write an FBI/TDF parser (though, I think, he could use the sunparser - still a pain) and, by accessing the program stores, he wouldn't have to.

TASpring is internally using the VTOL category as an 'air only' attack category.

Code: Select all

	weaponDefs[id].onlyTargetCategory=0xffffffff;
	if(atoi(sunparser->SGetValueDef("0", weaponname + "\\toairweapon").c_str())){
		weaponDefs[id].onlyTargetCategory=CCategoryHandler::Instance()->GetCategories("VTOL");	//fix if we sometime call aircrafts otherwise
//		info->AddLine("air only weapon %s %i",weaponname.c_str(),weaponDefs[id].onlyTargetCategory);
	}

As it so happens, you don't really need to care about that though - just check other categories. onlyTargetCategory is used in TryTarget to determine if a weapon can hit a specific unit (onlyTargetCategory & unit->category). Neither is a set in stone value in the engine, so if you know all aircraft are category X, then every antiair weapon will include X in their onlyTargetCategory.

[FLOZi]

I was merely pointing out that Cobs had no relevance whatsoever, and that category specific weapons are not restricted to VTOLs - i.e. what happens when KAI plays a mod where there are other restricted weapons; how does it know how to use them correctly?

[krogothe]

Ill try all that stuff out...
If the engine knows what units are AA only then the AI must be able too!

[Kelson]

If the engine knows what units are AA only then the AI must be able too!

That's the problem. I've shown how the engine knows which units are AA only, but which category do all air units fall into? If there are 6 different air categories, then there are, potentially, summation(6 choose x) where x ranges from 1 to 6 possible anti-air 'only' units. In AA, I would imagine all air units fall into the same 'airplane' or 'vtol' category, but this is a mod-specific issue since the engine didn't force categories (or their use/definition).

What might be a better 'general' solution for KAI is to not worry about "anti-air" specifically, but rather 'special purpose' weapons that have that onlyTargetCategory set. Create a system such that anti-air only weapons are handled as the norm, rather than the exception. Afterall, there are also anti-water type weapons as well. From what I've seen, there is nothing stopping us from having 'anti-ground' weapons either. Some mods even have smaller categorizations than that (the anti-infantry weapons).

[AF]

If there was more input on the moddability standards then we could finalise and start using it, at which poitn the moder would simply add an anti-air type purpose tag which KAI could read, and the problem is a modder problem nto an AI problem.

[cain]

(slightly OT)

what about a categorization based on role and function, using specific categorized categories?

example:

mobility:

land
air
water
amphibious
hovercraft
immobile

weapon specialization:

ground
air
water

special role (multiple)

radar
repair
invisible
(...)

advanced tactique (optional to use in formations, based on hp/damage dealt ratio or something)

first line - assault -> high hp
second line - support -> special weapons, or low hp high damage
lateral - infiltrator -> quick and nifty
third line - artillery -> long range

[Kelson]

If there was more input on the moddability standards then we could finalise and start using it, at which poitn the moder would simply add an anti-air type purpose tag which KAI could read, and the problem is a modder problem nto an AI problem.

What? I think that is a completely seperate issue than this. Even if the modders all agree that tag X signifies antiair or not-antiair-only, then we would be forced to write an fbi parser to find that information. Meanwhile, the engine would continue using the general solution (not caring about antiair specifically, that is).

My point was that the system exists independent independent of that one, particular, specialization (antiair) and it would be a better practice to follow suit in the AI area, rather than forcing some selectivity to a system that doesn't have the same (ie, filtering the available data un-necessarily). Afterall, it is still necessary for the AI to compensate for that turret which only hits hovercraft.

[AF]

Kelson, such an fbi parser is already being used in OTAI to get the start positions, I should knwo I copied the modified CSUNParser from it.

The class to aprse these files was in spring 0.4, and was modified for use with the AI callback interface by veylon, its called and sued in the same way it's currently used in Spring, (a new TDF parser based on the boost::spirit framework has been created by the linux people, and that'd be a good alternative, and would be just as easy to modify for AI use).

All the hard work on the AI side has been done, a few little extra bits to get the values on demand, and all that's left is for modders to add it, which they would be best doing anyways for better AI gameplay (even if the AI ahd a good way of getting such information without this method it'd still be a good idea to support the tags for other reasons).

[Kelson]

double posting ftw!

[Kelson]

Kelson, such an fbi parser is already being used in OTAI to get the start positions, I should knwo I copied the modified CSUNParser from it.

As I said, one could adapt the sunparser :) One would still be required to make the parser look for certain parts of each file and, as I also said, there isn't really any need for that.

All the hard work on the AI side has been done, a few little extra bits to get the values on demand, and all that's left is for modders to add it, which they would be best doing anyways for better AI gameplay (even if the AI ahd a good way of getting such information without this method it'd still be a good idea to support the tags for other reasons).

I'm a fan of the current system - it gives more freedom to the modders while forcing more general solutions to the 'specific target' weapons.

A bit off-topic: You trust modders far more than I do. If I wrote an AI, I'd want it to work on all maps and mods irregardless of how the mapper/modder wanted it to function on that map. Instead, I'd let my AI figure out the environment for itself and make decisions that way. For example, my MetalPlacerAI doesn't place metal extractors or mohos or any particular mod's metal extracting unit. It checks all the metal extracting units the group members can build, then it selects the most profitable after ~15 minutes. This coincides with building metal extractors early, because they're available, then changing metal extractors into mohos later (though, in XTA, there is actual analysis to be done before the change, since a moho might drain too much of the available energy to be viable [make more energy before placing mohos]).

[AF]

I'm not sayign I should rely on the modder tot ell ym AI what to do.

Instead I'm saying the AI should decide for itself, unless the modder has told it otherwise. Or ti should use what the modder put down as a 'recomendation'

One would still be required to make the parser look for certain parts of each file

Already done

[Veylon]

AF is dead on. The AI programmer should figure what by what criteria they want the AI to categorize units, whether roughly or finely. If the mod writer is willing to categorize them, that can help.

[AF]

huh? You've just posted a message in the thread proposing how a modder would do this that sounded more like the opposite? =s

[Veylon]

Did I?

I thought I was pretty consistent about wanting the AI's decisions on how to categorize a unit to be more about what that unit can DO rather than what it's FOR.

[AF]

Oh, then why didnt you just say that outright? Sorry, I was a little off my head yesterday.