Idea on griefing/replicating objects...

I don't know if this would actually be possible but it sounds good in my head lol.

Ok.... Each parcell of land is already set with x amount of prims that can be rez'd at one time. Why not expand on that a bit, not the prim limit itself, but prim premissions for any givin person.

The limits/permissions stay the same for the person or group that actually own the land, but if a person does not own the land themselves or thro a group they can only rez x amount or prims, anything over that just wont rez period. Make it a standard grid wide with the exception of sandboxes.

Don't know if I'm making much sence here, but go ahead and post oppinions ^^...

I actually think that is a good idea Sahara XD

LL, listen to her, shes got a point.

This would really hurt building classes and show and tells. Either that or we'd have to hold them in sandboxes..

That's where the "groups" comes in. Or possibly a shut off opption under land prefs.

Any sort of per-resident limit designed to stop griefing will encounter the same problem as the Lindens face when trying to track down the objects.
The problem is that the objects give copies of themselves to pretty much everyone they meet , and every time a person rezzes one of these objects they replicate under that person's name. The result is that in a short space of time, MANY people 'own' the replicators.... and the effect is that per-person limits have their....limits.

Not saying it's a bad idea, just saying that if per-resident limits were put in place, it'd require code changes, sims to talk to each other.... and some way of preventing object transmission.

Personally, I would suggest a function that :
1) allows Lindens to get the unique key or checksum or some identifying trait of the script that is running in a replicator object.
3) allows Lindens to sent out a grid-wide notice to all simulators, instructing them to *delete* any object which contains a script identical to the one thus identified.

This could be defeated with self-modifying code. But, it might help with the non-evolving grey goo.

A Linden administrator could find some good, use holdlock to stop it moving, right click the goo script inside it, "copy unique checksum", or "copy unique script identifier", and then use god tools to send a grid-wide notice so that all simulators start deleting all objects in them which contain a script with that checksum.

Great against an endlessly self-replicating object that doesn't modify itself or its contents in any way. Even if there were multiple versions, it might help you speed up the process of zapping them all.

Why not just not allow objects to use the llGiveInventory function while not on group land?

This would cut down on at least some of it and to be entirely honest, if the object is not in the group that is linked to the land it shouldn't be giving inventory anyway. Vendors on others' land can just be given low-level access to the group. That's it.

I have noticed that in recent attacks, the griefers are able to Change the object creator name maybe even the group and owner so creator/owner related permission might not work anymore. You might even find a replicating bomb on your own yard created by nobody else then yourself!

This is getting ridiculous, not counting the asset server overload.

They tried that once before. It broke LOTS of content, and pissed off the whole artificial life community. They backed the change out within days.

Fair enough. Never thought of something like that. :)

Scripts can't modify themselves or others, null-issue.

This thread discusses a similar proposal that essentially embeds the ID of the person who wrote the script in the script an would allow using that to be used to disable scripts. The theory is if a person writes one griefing script, they probably wrote several. You don't want to kill one grid attack, just to have another start the next day.

Not *now* they can't... but it's possible that LL could alter LSL to allow this in future. Maybe not likely, granted, but better to be aware of potential problems even if they can't happen yet.

I don't think it'd ever happen. "Buffer Overflow" sounds like far to much fun.
"Whee! Lets make the code WRITE TO ITSELF and see what happens!"
(Assembler was a lot of fun, half the computers going *beep* as it wrote the non-printing character 0x07 to the screen--otherwise known as the System Beep).