Labels -- 1:1 relationship?

[aubergine]

I'm still getting confused over some elements of labels. Specifically, is there always a 1:1 relationship between a label and an object, that is to say a label can only refer to one object, and an object can only have one label associated with it?

The reason I ask is this:

5.7 addLabel(object, label)

Add a label to a game object. If there already is a label by that name, it is overwritten. This is a fast operation of O(log n) algorithmic complexity.

....

5.9 getLabel(object)

Get a label string belonging to a game object. If the object has multiple labels, only the first label found will be returned. If the object has no labels, null is returned. This is a relatively slow operation of O(n) algorithmic complexity.

From that it looks like a many-to-one relationship, where an object can have several labels, but a label can only have one object.

But there's no easy way to get a list of all labels associated with an object, because getLabel() only returns the first label it finds for the object.

IMHO it would be much simpler to force a 1:1 relationship between labels and objects. This way a .label could be added to applicable objects (droid, structure, feature, area, position). Alternatively, do it the other way round, so a label can refer to many objects, but an object can only have one label?

If prototypal inheritance was used, and the relationship was 1:1, the (super)classes could have a getter/setter property ".label" which when set would trigger addLabel(this,value) and when get would trigger getLabel(this). This would make it very easy to work with labels...

Code: Select all

var label = someDroid.label; // get current label

someDroid.label = "foo"; // add or change the label
// Note: If there's already a "foo" label, it will be updated to point to someDroid

[aubergine]

And, on the subject of label confusion, is my understanding about their "sharing" correct:

* Map-defined labels (eg. labels.ini) are accessible to all scripts on all network peers
* Labels created using addLabel() are accessible to all scripts on the peer that did the addLabel() (ie. not syncrhonised with other peers)?

For example, if I had two AIs, both running on the game host machine obviously, AI #1 could define "foo" label, and if AI #2 also defined a "foo" label there would be a conflict and whichever script defines "foo" last will win?

[Per]

Labels are many-to-one. This is a property of them living in a hash table, but it is also generally useful if you want to refer to the same object in different ways. Also note that a label can point to a group of objects, not just single objects.

The primary purpose of labels is to annotate things in maps from the map editor. They are therefore shared. The ability to modify the label list later with addLabel() and removeLabel() was retrofitted on to this concept. getLabel(object) is a reverse lookup, and therefore very slow. Adding a .label property to objects would be very slow for the same reason.

I think you want to do things with labels that they were not designed to do, and I'm not sure if that is a good idea, or if we should add another way to annotate objects instead that is more appropriate for this purpose.

[aubergine]

I want to use labels the way they are designed to be used, I just wasn't sure what that design was heh.

If labels re many-to-one, how can they point to a group of objects? Or do you mean a "group" as in a group of droids, and the label points at the group object? I assume the only way to label a group is via labels.ini? If I retrieved the object associated with a group, would I get an array of game objects?

Just to re-confirm, all labels (even those added at runtime, including any runtime-created POSITION/AREA objects) are synchronised across all scripts on all network peers?

[Per]

The documentation of group labels is missing, I see. I will fix that. If you request a GROUP type label, then you get an object containing 'id' and 'type', where 'type' is GROUP and 'id' is the ID for the group. You can then use this ID to request the group list with enumGroup(). You can create label groups at runtime by creating objects like this, but I see no particular use for this.

Labels created at runtime are not automatically synchronized. As usual, if you add a label in a scripts that is run on all peers, such as rules.js, then that will synchronize the label. However, if you add, change or remove a label in an AI script, then that change will not be present on a non-host peer's rules.js script, for instance.

I created labels for use in campaigns and single player mods, where such sharing would be useful. In multiplayer where you could mix and match mods and maps that could have different uses of the same labels, that design is not really appropriate.