18 months of work down the toilet

Taking aside the O2O debate, which is elsewhere in the forum, I just wanted to say to you Surina that I am a BIG fan of your work in SL, and was about to contact you to discuss your progress. I work in A.I. and A.L. and have done environmental simulations, including ant nests, fish and evolving plants. Some of my work was with colleagues who had worked at Cyberlife (creators of Creatures).

I am preparing for a conference on the 2nd November about the use of technology in education for special educational needs students, and would love to show some screen dumps of your creations. Do you have any on file? Are they working anywhere that I might see them?

As payback - assuming we get this stuff sorted - I'd love to collaborate on future generations of critters with you.

Doc

P.S. could you 'give' the fish to other land owners to allow them to work? I have added my voice to others asking Kelly et al to allow groups to work as well as owners.

Then why not fix the actual crashing of sims instead ? As I said earlier, if there is a particular condition in which sims just give up and pick up their toys, they shouldn't be able to get there, they should stop at the border.

BTW if I read the threads mentioning the attack correctly, the griefspheres were duplicating as fast as they could. What impact on this would the new scheduler introduced in 1.7 impact this ? Would it slow down to a screeching halt such replication as the sim cannot allocate execution time to all the replicatees, while slowing down physical calculations in a similar way to hard-limit the processing time spent on resolving all the collisions and movements, effectively capping the replication rate while leaving the sim sufficiently responsive to let staff take corrective action (go to land menu, return all objects of the person) ?

May I ask why nothing was done about this in the preceeding 2 years, when it has been brought up on many occassions? From where I'm sitting, that's more "seriously flawed" than a rushed fix now.

A while ago in welsh? I belive it was the sim was overun with phsical ants, much like this recent incident. Why not just add a self replicating generation counter and limits like LL said they did after the ants.

All the "overruns" with self replicating objects up untill the attack on Sunday were accidental and were quickly and easily sorted out. I even had a runnaway problem with the fish predators which nearly brought down my 3 sims... I was able to mass delete them though and have since built in a safeguard that will kill all fish instantly.


The problem with having a generation counter built into the llGiveInventry() call is that once the maximum generation number is reached it will stop. (Which is the whole point of a max generation count). This is no good for ALife projects that are supposed to run indefinately. Spieces evolution relies on the older generation dieing off and the new generations reproducing. Whatever random generation limit you may impose, the ALife creatures would eventually hit it and the whole experiment would grind to a halt.


I'll say again, the ONLY way to fix this problem is to fix the server code so that they are not crashed by the amount of prims that LL say we can legitimately use.

The important thing to remember is that all sims are limited to 15,000 prims regardless of the prim creation method. Either sims can support that number or they can't. That is not a problem with llGiveInventry(), it's a sim stability problem.

Here's a two-stage approach.

1. limit llGiveInventory() to a single sim. Don't let it cross a sim boundary, and don't let an object llGiveInventory() if it's not in its home sim (the sim it was rezzed in). That solves the first problem... swarms won't be able to spread beyond a single sim and take the grid down.

2. limit the number of prims that can be rezzed by a single object owner in a single sim, by any path. You can be pretty wide in the limits on this one, and it's cheap to implement a simple up/down counter on a UUID in MySQL. If you set the limits to (say) 1024 plus a function of the amount of land you own in the sim it shouldn't limit landowners or people in combat sims, or building in sandboxes (the most I've ever rezzed in a sandbox was a 70 story tower with 7 prims per story, less than half that), but it'd still leave a griefer short of taking down a sim by a factor of 10.

This would also prevent people from using fairly obvious non-self-rep attacks on a sim.

[EDIT: I mean the total number of CONCURRENT prims, when your fish die, they will still be able to be replaced]

[EDIT: actually, I did rez *two* copies of that tower once, but only 40 stories each, grand total of 560 prims]

The fish need to have a high enough energy level before they can breed, right?

And they get energy from food, right?

OK, put all the fish scripts in the food pellets, but make them inactive. When the fish eats a pellet that puts it over the limit the pellet doesn't llDie(), instead it redecorates its prims to look like another fish, and the fish scripts turn on and the pellet scripts turn off. Zap, the pellet's now the child fish.

If your predators need to breed, they can do the same thing to the fish they eat.

[EDIT: I don't mean the scripts are "not running", I mean they're in "state food" not "state fish"]

Typical! The lindens broke my fireworks.