Tuesday, March 23, 2010

Evolution Simulation IV: Mutating critters at last!

As noted in my last post I was finding all sorts of problems with my region. Turns out that these were due to two things. First to control my critters I was killing them off bu broadcasting a commmand that triggers the llDie() function. But too many prims dying at once was messing up the asset server.

Also I was duplicating the critters en mass and that I led the server to treat my critters as the dreaded grey goo. Grey goo is a term for excessive rapid self replicating prims. See this discussion of the origin of the term from nanotechnology. When Second Life, and apparently OpenSim as well, detects too rapid prim replication this is treated as grey goo and a defense against this called the grey goo fence is activated.

Open Sim apparently doesn't warn you about this and I only discovered the problem when experimenting with my critters in Second Life. Second Life does warn you about grey goo and I got the warning rezzing even a small number of critters at once. Apparently the limit is about 240 rezzings in 6 seconds. Beyond that the ability to rez those prims is restricted. My inadvertant experiments suggest that in SL the limit may be more stringent than 240 rezzings in 6 seconds.

See http://lslwiki.net/lslwiki/wakka.php?wakka=GreyGooFence for a discussion of Grey Goo and the Grey Goo Fence.

This last week I worked out how to input and represent the critters genetics and the mutation routines. In my earlier systems I had the critters read their initial genetics from a note card. Instead I use the object description field to enter and store the genetics as a string of integers.

Right now the description field has 4 digits

position 1 = "1" or "2" "1" = haploid "2" = diploid. Right now the critters are strictly haploid so this position is ignored for now.

Position 2, 3, 4 are three loci each with 9 possible alleles represented by single character "0" through "9". For the haploid critters, this means there are 1,000 possible genotypes.

Since I mean my evolution simulation to be visual the genotypes in the three loci are used to make a vector that can be used with the llSetColor function.

So in the object description field the legitimate genetic description would be
"1045" . When a new critter is rezzed, the description can be passed to the offspring through the parameter in the llRezObject function.

I also wrote a mutation function:

string mutation(string start, float mforward, float mback)

Where the string is the genetic description, mforward and mback are forward and back mutation rates going forward to the next allele and mback the back mutation rate to the previous allele. So I assume if the allele is "7" then forward mutation would lead to a change to "8", and back would change from "7" to "6".

In addition another function setcolor(string thedata) takes the genetic string, isolated the loci and uses them to set the color of the critter and display the genetic description as using llSetText. I did this because just as in real populations most of the genetic variation leads to subtle variation in the population phenotypes over the short run.

The image shows the results. The critters started out with the color <.9, 0 .9> which sort of a light bluish green. After 4 generations of mutations if you look at the image you can see subtle differences resulting from successive mutations.

The critters still don't really interact with each other and wander around randomly, but not leaving my region. I did some work streamlining this routine so it was much more efficient.

Next up....adding simple natural selection to the mix.

Monday, March 8, 2010

Evolution Simulation III Devastation in Science Sim!

Well not quite. But I was testing my critters to see how big a population my parcel in Science Sim could hold. Everything was fine until I went to delete them using a listen event with llDie triggered by a chatted command. Guess what, 600 prims dying all at once causes the asset server to have a fit: a bit disconcerting but Mic Bowman got things fixed....

And immediately after Mic's fix:

Thigs were still loading at this point. What Mic recommended is that I use a random number to determine when a particular critter is going to die so that when I issue the command to die the critters don't all die at once.

In SL this bit of code gives a quite realistic movement for my critters:

vector newpos = newcoodinates(llGetPos() ,3.0);




But in OpenSim the critters don't seem to turn toward the target in response to llLookAt as they do in SL.