Identifying characteristics of sensed objects

This may be a silly question, but I'm missing the answer:

Once your scripted object (object A) has sensed another object through a sensor, is there a way to find information other than the name/key/owner of that sensed object (object B)? Specifically, is there a way to just identify the color (or other texture-properties) of it?

Basically, I want A to sense B, see what color B is, and react accordingly. I'm afraid I'm going to have to either encode certain data in the name (resulting in long and highly polymorphous names) or resort to using email or chat every time one object sees another.

It will be hard to encode stuff into the name, because I don't think you can change the name.

I think you'll have to resort to llSay.

Maybe something like:

query//123123-2313-21312-31-2312313

and that object would send you back

color//123,123,123//height//5//age//10

This is something I desperately want from LSL as well but it just isn't there.

The returns from sensor include name, position, velocity vector, but nothing that will give you specific identitying info.

Yes, I know name is normally pretty specific, but because it is the only identifier all my fish have the same name due to the main limitation of the llSensor call itself, No wildcards...

returning object description would be a start... I already use that to pass data between scripts without having to use linkmessages.

Oh you can change the name easily. llSetObjectName(string NAME) does that (according to the Wiki; I haven't tried it in game yet). The main difficulty though is that it complicates the sensor sweep (since you basically have to do a sensor sweep for ANY object, and only then tokenize the names and look to see if you're looking at a critter or whatever).

Hmmm. The first solution that comes to my head, then, is to move most of this calculation off into a "Watcher" scripted object. The watcher would keep track of every member of the swarm, handle all it's data, etc.

There are some obvious benefits: it's impossible to have the swarm get out of control (the grey goo phenomenon writ large), it's trivial to exchange info like this, it's trivial to get access to the info for the entire swarm, etc.

There are also some obvious difficulties: that one object is going to be performing a tremendous amount of calculations, even though each individual critter would do everything but exchange this info.

Hmmm.

(In case I'm not being clear, this is what I mean:
Each critter would query the Watcher for the characteristics of any swarm-related-object it saw (based on location, since the Watcher would have this easily). The Watcher would provide it with name, characteristics, etc. The critter would then make all the other calculations (motivations, etc.) and update the Watcher with it's new information. I'm about to eat, but I'll post more info later since it looks like this is how I'm going to have to handle it.)

I had this problem, and yes, LSL is lacking here. In my case, the obejcts were fixed and immobile. I needed to tell one type from another. So I built the objects such that each type was at a special orientation. Not exact matches, because some could be further rotated, but from the llDetectedRot() I could tell which type I was sensing. It was just enough for my task, and the cleanest method I could come up with.

That's a clever solution, but it's not available to me and other ALifers, since it's hard to imagine their orientation not changing.

I gave a basic introduction to my solution, but having accomplished it now (the code will be released when I have a first full working version of my watcher/swarmer scripts, hopefully this weekend), I thought I'd explain exactly what I did in case it helps others:

Basically, in order to be part of a swarm, a Swarmer informs (via llSay, right now, but that may change) the Watcher of it's name, location and DNA. The Watcher creates a database (a trio of Lists) for all this info. Each Swarmer, during it's behavioral cycle, first reports its location to the Watcher, and then does a sensor sweep of it's area. The sensor event provides the name and location of the objects it sees. One option (the one I DIDN'T take) is to have all Swarmers share a single name (e.g. "Swarmer", and differentiate by their locations. Another option (the one I DID take, for reasons relating to a feature I haven't revealed yet) is to have the name of each Swarmer be unique. The Watcher then performs a llListFindList call to find the index of that name in the List of names, and then applies that index to the Lists for locations and DNA, and provides that data (the location and DNA) of the sensed object.

Now, this will be updated in the future because I intend eventually not to have direct DNA exchange, but rather literal sperm/egg exchange (for maximal possible variation in evolved swarms), but the concept will basically still be the same (i'll just have three classes of objects - swarmer, sperm, ovum - instead of one).

I was working on the watcher script, and something just occured to me:

It's no more efficient (with regards to this aspect of the script, anyway) to have the swarmer 'tell' an info request to the Watcher (and have the watcher reply) as opposed to having swarmers simply tell each other those requests. Think about it like this:

You've got two swarmers (amidst a larger crowd of swarmers), each with a unique location (and, actually, a unique name). One of them (swarmer A) senses the other (swarmer B). The sensor command allows A to detect B's name and location, but nothing else descriptive (ignore the physical stuff, like velocity). A can simply llSay on a dedicated channel (which all swarmers are hard-coded to use) then broadcasts basically something like "I'm looking at the swarmer located at <X,Y,Z> named <name>, can he call me back with his characteristics?" Then, of course, each swarmer that hears this quickly checks to see if it is the swarmer in question. In our example, B would realize this, and quickly respond to A with the requested info.

First obstacle: the movements of these swarmers is independent (i.e. they dont wait for each other to finish their thought-cycles), so it's possible for A to sense B at location X, but for B to have moved away from X by the time B hears the info-request. First solution: just identify each other by name. Your name doesn't change over time, so this could work.

Second obstacle: by eliminating the Watcher, it's difficult to figure out how to keep track of all the swarmers, and thus by extension its difficult to have a KillSwitch to contain any out-of-control swarms (and thus to avoid a banning). Moreover, it makes it just as difficult to keep any statistics/other info on the swarm.

I'm keeping the Watcher paradigm, because of the 2nd obstacle. I posted this whole thought process, however, to help anyone else involved in this sort of development (why reinvent the wheel).

You can get by problem 2 by programming eachswarmer to have a limited lifespan. The script I use does this, and I believe Surina's fish do this as well.

You're glossing problem 2 a bit. It's not only that you have to have each individual handle it's own death, but that it's difficult to keep track of them (which I want to do), e.g. statistics, etc. We'll see how this evolves: the watcher, which is a very low-computation script, right now just handles this info exchange. It may become redundant in a future version (i.e. the swarmers may be independently exchanging data, with the Watcher just literally watching and providing me with an easy means of accessing the whole swarm), but I'm not sure.