labels - naming convention?

[aubergine]

So, here's what I know so far about labels:

* They are defined by map makers in the map
* They can be objects of type: AREA, POSITION, DROID, FEATURE, STRUCTURE
* JS API now has an enumLabels() function that returns a list of all labels on the map
* JS API has a label() function that gets the object associated with a specific label

So...

From a script developer perspective, what do we do with these labels and the things they represent? Is some sort of naming convention required so that scripts know for certain things to look for and act upon? (I'm thinking from perspective of an AI script here).

[Per]

Labels were not created for use in AI scripts, but in campaign scripts, so I had not considered that option. I'm open to ideas. It would be easy, for instance, to add a type property to them...

[aubergine]

According to the docs there's already a type specified: http://buildbot.wz2100.net/files/javasc ... html#toc28

But it's unclear to anything other than the map maker (who likely also wrote the accompanying script) as to what the label means.

I was thinking that labels could have wider use beyond campaigns - for example, could they give AI (including in challenge scenarios) hints about where to build certain things, or places to avoid, or good rally points, etc?

Some examples... (X denotes a number, incremented as necessary if there are multiple of the same type of label)

VTOL_PATROL_X
AREA object where VTOLs should patrol if possible.

LAND_PATROL_X
Similar to above, but for land units.

SENSOR_X
AREA or POSITION object indicating strategic location for a sensor.

INDIRECT_X
AREA or POSITION object indicating good place to put artillery and other indirect ranged weapons.

WALL_X
AREA object indicating to build within the contained tiles.

CHOKE_X
AREA or POSITION object indicating a choke point.

RALLY_X
AREA or POSITION object indicating a good place to rally troops before attacking an enemy base. For example, this might be on some mountain path that otherwise the AI might completely ignore.

REPAIR_POINT
For use with the DORDER_RETREAT command.

[aubergine]

It might also be useful if the enumLabels() function could take an optional prefix parameter - if specified, then only labels with that text at the start of their key would be returned.

For example, I could do enumLabels("CHOKE_") to get a list of all choke points.

[raycast]

Yes, there should be a filtered enumLabels. I read that this is a best practise for AI, as very often the code is at that particular point only interested in one type of annotations.

The term "annotation" seems to be more common than labels, and ideally the annotations would have some properties; priority is an obvious candidate. But it could also be a building hint - say a point is labeled as DEFENSE with the extra information "hardpoint" or "bunker" or "AA". So that an AI that is less advanced will build any kind of defense, while a more advanced AI can choose a more appropriate building. There could be flags such as "upgrade" to hint to the AI that it should tear down an early hardpoint and replace it with a more advanced hardpoint if it has excess resources.

http://aigamedev.com/open/article/terrain-annotations/

Mentions that the annotations should be kept simple (i.e. largely "tags", not "scores") and there should be a filtered iterator available to the AI scripts.

[aubergine]

From what I understand, map makers can place labels on features / structures / droids that they place on the map. So they could place two trucks and label them truck1 and truck2 etc. I've never used labels myself, nor have I made any maps, so I don't know this for sure, so prolly worth checking what I have said.