O2O Nerfed Horribly *Groan*

Let's talk about O2O nerfing

/invalid_link.html

"Sorry I can't give the finality you demand.

However I can tell you that this will be adjusted. You are right, only objects need to be blocked. Other possibilities to reduce the strictness of this rule are also to be investigated.

What was implemented was the sure fire way to stop a repeat of last Sunday on extremely short notice. Some of my favorite pieces of user content take advantage of self replication features, and for now those are limited to land you own. Hopefully this can be improved.

Other ideas on preventing grey goo attacks are welcome, you can email me directly at [email]kelly@lindenlab.com[/email] and I will forward suggestions to the rest of the development team."

Wonderful.

I can deal with the general problems that ensue after a major update - I have been through it many times - so let's not turn this thread into a discussion about that.

This is about a BAD nerf dropped into the update at the last minute because of the global attack.

This is not a viable solution. It screws over MANY scripters and sellers of products.

See the following link for just a few examples of what a damaging change this is:

/191/74/67694/1.html

I realize this is a "short notice" fix - and that they are asking for suggestions. So, my question is - do any of you coders have any viable solutions/suggestions?

Yeah, and it's not even fixed. All they did was break lots of cool functionality.

Fact is, all this change did was put in a very very minor roadblock to creating a global attack.

Anyone who thinks about it for a minute can easily workaround what they did.


I explain more here:
/invalid_link.html

I'm a little lost here. How does this prevent global attacks? Can't you just use llRezObject to rez an object that contains an object and a script to rez the object inside? etc?

Also, I'm feeling pretty dense, because I can't understand what vital function o2o inventory transfer serves that can't be accomplished by simply pre-loading inventory and calling llRezObject. Insights welcome.

`

I can't think of anything either, really.

Including doing a global attack. You can quickly preload 1 million plus objects under the new scheme and then attack rather than late loading during the attack. Unfortunately, whoever made the change completely missed this fact.

I presently have a Grey Goo-like project in the works.
It's not going to EVER be used... unless absolutely necessary.
Instead of Self-Replication, there would be spawning points (Barrels), scattered around the grid, expecially in high-traffic, low-cpu areas.

These barrels, when opened, would spew forth with swarming, VolumeDetecting, Physics enabled objects, that like to collide with eachother. (Monkehs).

There would be, in the end different types of Monkehs, some will spread out (Scout Monkeh) , some will explode on contact (Pyro Monkey), some will seek out new life and civilizations, boldy going where no monkeh has gone before (Kirk Monkeh), and some will be randomly spew particles and hand out objects to random people (JLo Monkeh).

These monkehs, nearing completion, will be part of standoff system in the even my plans should fail... or if I just need a distraction..... or if I just kick my feet up on my Evil Desk and hit the Big Red Button Of Doom. Either way, even if it doesn't royally screw the Space Server and such, it'll be a barrel fun

I posted a few suggestions, none of which were well received.

/invalid_link.html

Enabran, it's llGiveInventory() is a crucial operation to allow true self-replication. So while your suggestion can work for a finite number of generations, it can't work in a generalized case anymore.

I'm not happy about it, because there's no solution to allow existing work to continue to function, nor is there a work-around for things going forward.

As far as I can tell, this means, "Suck it up."

On second thought, disregard my above post.

heheh

I do have some experiments, but I try to keep the contained.
Just... if you see me in Island Sandbox, I'm not there for the view, ok?

Reposted from here for consolidation:

Why cant llRezObject be capped at the server level ? I mean, once the sim reaches N objects, it stops. And once M (< N) objects are physical, no more physical object can be rezzed and no more objects can turn physical.

Hmm. I'm certainly not that great at scripting or many of the technical aspects behind it, but that's never kept my big dumb mouth shut before!

0. Anything it takes but do NOT "dumb down" or break or water down the existing functionality, it's already dumbed down enough as is - as Eggy said, if SL made real-world guns they'd wait 20 seconds before firing a cork out the end. ;P

1. If I'm understanding it right, people are using O2O to "get around" the don't-let-self-replicating-objects-go-more-than-4-generations limit. If so, can they simply fix/improve the generation limit so people can't get around it like this?

2. Cap llRezObject to not keep rezzing if the parcel or SIM are full, or basically if it's going to crash the SIM, then don't do that and don't keep rezzin' the objects. I'm sure it's got to be more complex than this, tho, because this is a pretty obvious answer... I'm assuming it's more complicated and measures like this have already been tried... Even what Blaze mentions, taking statistical samplings and going off them to "cap" rezzing or object-to-object, as long as it doesn't break existing functionality.

3. Hold these people responsible. Financially responsible. LL already has a biiiig loooong TOS we sign into agreeing to many, many things - would there be any harm in also agreeing to, in the event that for whatever reason you bring down enough sims to crash the entire grid, that you will be held financially responsible for at least the LL time/manpower to fix the problem, if not additionally any recompensation for lost time/DOS for those who log into SL. Right now it looks to me like the person responsible is banned,but can go out and get another alt with a credit card and keep doing it...

And finally, B, C, and D : Anything it takes but please do NOT "dumb down" or break or water down any existing functionality.

There's a four generation limit?

This "nerfing" breaks:
- automatic gridwide update of vendors
- my trees and critters which rely on autoreplication
- some games, I'm sure
- Luc's (and certainly others') autoloading of spells into wands he sells
etc...

What it doesn't fix:
- sims still crash and burn if too many physical objects rez
- sims still allow rezzing enough physical objects to cause the above crashing and burning, AFAIK, it just takes a bit more time or more effort (like putting more autorezzer scripts in the prim, duh)

LL, you fail it. But then, I completely understand it's hard to rush in a correct fix to a security flaw right before rolling a major update.

i am pretty happy this doesnt break my vendor system (hopefully) however this water any chances for one of my project to even exist.

Please LL why do you have to act like idiots when under pressure?

Well, I'd agree, if this wasn't a security flaw highlighted to them and discussed since, it would appear, 2003. They've known about it for a very long time, and have waiting to do something reactive (not proactive) when it's happened. That's poor going in my book.

I would like to throw my voice behind this as well, saying "I now have broken scripts as well" . I'm sure this is just temporary.... right?

This is extremely annoying. Not only has it drastically harmed the usefulness of HUD attachments, but it's basically a major victory for the griefers: rather than disrupting the game for one night, they've destroyed a useful piece of functionality for good.

One possibility would be: whenever an object is llGiveObject()ed to another object, it gets flagged, and then can't be given to another object. This would leave replication stuck (so still no flamethrowers ) but at least allow communication by passed objects.

Now how does this work for group land? If you are part of a group, does the object now have to be set to the group? Will it only work with land directly in you name?

Any answers would be helpful. I fear that my project is now ruined

How about this solution instead?

I think people use llGiveInventory as a way for secure communication between objects, Kelly.

Scripts within objects can modify the name and description of the object they are in by using llSetObjectName() and llSetObjectDesc() respectively. After they have put whatever data they want into these data storage areas, they can then call llGiveInventory() to send the object over to another object where a script in the receiving object can read the data stored in the object name by calling llGetInventoryName(), and/or it can rez the object it just received and use some kind of local communication method (llSay(), llWhisper()) to talk to the script inside the received object to get the description data.

Wow that's hard to read. Does it make sense?