Difficulties

Before I get to the body, I'm disapointed to say that I'm not going to get my swarm out this weekend. There are some serious difficulties with timing (mainly involving communication), so I'm starting over on most of it, doing my best to exclude communication between creatures as much as possible.

Again, I'm posting these comments to help other developers:

1) The lag-time between listens, says, etc. that amount to requests for information are not only variable, but they're non-trivial. As a result, there has to be serious error-catching to prevent synchronization problems. Unfortunately, this seems to unavoidably result in jerky, slow-responding creatures.

2) The only means of providing data to other creatures (i.e. scripted objects) are email, tells and your name. The name of a scripted object can be changed with llSetObjectName(), but this has a serious limitation: a name can only be 63 characters, and must be string. This is good for identification purposes: since name is detected by a sensor sweep, you can effectively pass a 63-char stream of information. Prior to my decision to rewrite, my critters were only using 31 chars, and had almost all my desired characteristics listed. That means that there's a large buffer zone for additional data. This means that it's viable to have creatures evaluate each other by downloading their subject's DNA from it's name in a sensor sweep (which is very quick), but it leaves us in an awkward position for replication.

3) Replication, i.e. the creation of the next generation, only gives us a few options for the child to receive it's DNA: the rez integer, a sensor sweep, or a llsay/lllisten sequence.

The Rez integer: when a script wants to rez an object from it's parent's inventory, the final parameter to llRezObject is an integer. This could be employed in a few ways: the first is that there could be 10 options for each of 10 characteristics, each selected by the number (0-9) in each digit; the second is more sophisticated but much more difficult, relying on the fact that many characteristics (such as gender) only need 1-3 possible states as opposed to 10. This solution then is to design a means to add together the various values indicating states, but it's beyond my math abilities.

A sensor sweep: newborns are always created within 10m of the parent, since the llRezObject() function is limited in that fashion. As such, and considering you can orient the rez'd object with that function, you can guarantee that the newborn will be able to see the parent. Recall that there can be 63 digits to a name, and that I was only using 31 digits for the DNA. That means you could literally fit two DNA strands in the name, so it's possible for a parent to temporarily append her child's DNA into her name. The newborn, created with a blank DNA (e.g. 00000....) would (as its first priority) scan around for the nearest creature with two visible DNA strands (which, it stands to reason, will almost invariably by the right mother, at least in the foreseeable situations so far), and then extract the second DNA strand as its own. The mother - eager to restore its name to a normal state - would keep looking at it's newborn, waiting for the newborn to display its proper DNA, at which point it would go about its business. This model is actually extensible for the creation of seperate gametes (e.g. the gametes would be the ones acquiring DNA, instead of the 'newborn', and the egg would eventually read DNA from a sperm in the same way, turning itself into a newborn and killing the sperm).

This might help:

object_rez(key id);

Triggered when object rezzes another object from its inventory via the llRezObject api. The id is the globally unique key for the object.

It saved me from using sensor sweeps as much in a cell duplicating object I created.

How are you using that to communicate info? Isn't the globally unique key determined by SecondLife, as opposed to being script-editable?

object_rez(key id) {}

id = the key of the object just rezzed by llRezObject();

You can use this key to send e-mail to the object you just rezzed. Or you can open a private listen channel that only listens to that object's key. THen you just start communicating your info to the object.

object_rez is an interupt event much like listen.

When your script rezzes an object an interupt is set up that looks for the newly rezzed object. Server load could slow down the rezzing considerably compaired to the running speed of the script so simple timers would never work.

Once the object has been rezzed and a key assigned by the server, the interupt is set and the object_rez event is called in the orriginating script. The key of the newly rezzed object being passed as a param.

My fish use this method to load their scripts. Fish object is rezzed by the parent. object_rez event is triggered, returning the key of the new fish. The key is then used in remoteupdatescript to pass all the scripts from parent to child. Yes I know the child could already have the scripts embeded, however this method allows me to update a few fish remotely which then pass on the new scripts to their offspring.