Remove llGiveInventory

I'm all in favor of this thread's death, and there is absolutely no reason to ever have to throttle 'llDie()'.

- Ace

I agree there is a problem (the potential for problems is a problem), but I disagree that the problem is replication specifically. Replication is a good thing if it can be controlled. Out of control replication leads to too many objects and contention of resources which leads to severe lag and crashing of servers. I think it is important to make that distinction so that we can preserve the ability to do replication.

In fact, other events can also lead to the same result of too many objects and contention of resources. For example, too many players converging on a single sim, and each player rezzing one object could have the same effect. It's just that replication makes it very easy to get out of control, and thus we tend to blame replication.

As a programming analogy, think of loops and recursion. Both can lead to infinte loops that consume all CPU time or fill up memory. But we would not want to ban loops and recursion. (Pure functional programmers want to ban loops just because they are inelegant and it is more difficult to prove they work compared to recursion. )



Yes, but other things can cause the same problems, only replication makes it very easy. Focusing on replication as the problem is what has caused most of the controversy in this thread, I think.



I'd like an example of a safe replicator, one that self-regulates such that there will never be more than, say, 100 per sim, whatever it takes to avoid causing problems. I think it would be great if there were simple ways to build in such self-regulation, so that more people could experiment with replcation in a safe way.




Constraints on crossing borders would constrain the problem to specific sims, but I don't think that is enough. I don't want any sims to become overloaded and crash for any reason.



Claiming that the problem is replication or the llGivenInventory command has caused many people, myself included, to react against overconstraints. But many people have not gotten beyond that. Many people won't accept that there can be a problem until they see or even experience the problem themselves. And THAT is a social engineering problem.

We should have a new thread on balancing resource consumption. I'll get around to doing that, unless someone else does first.

I tried to write something that could replicate in an intelligent and constrained way.

I could not for the life of me think of a way to do it that could deterministically ensure that replication would not proceed into exponential growth.

I sent you a copy of the program, let me know how you think it might be possible to improve it such that exponential growth could not occur.

The problem with replication, in my opinion, is that it becomes global in nature.

I have found pretty much every architecture problem to be solved by localization. Something LL should really really consider for SL in general so we don't have these global blackouts on the login server.

Small outages are fine. You can apologize to a small group of customers and try to arrange things so it doesn't happen again. Global outages are very very painful.

it's called a start param or an sparam or a rez param.

It is an interesting challenge, given the lack of built-in global constraints on resource consumption, such as what I was suggesting. (By global, I mean within a sim, but perhaps we need both sim-level and grid-level constraints.) The problem is how would each individual object know how many other individuals already exist? The only way to do it without global communication is somehow computing how long each individual should wait until it reproduces, and voluntarily dying at the right times.

Ah.. here is an idea: maybe do something like Conway's game of life where if an individual sees too many others nearby, it up and dies, and individuals without at least two neighbors would die (of loneliness or starvation, depending on how you think about it). So an individual in SL should only reproduce in an area that had some small number of other individuals.


Thanks. It might be OK if there is exponential growth for a while, as long as it can contain itself before it goes too far.


Well, to pick a nit, there is nothing inherent in replication by itself that means it must become geographically global. But objects can move around, obviously.


Certainly global outages should be a top priority. Occasional local outages are not so serious, but I would never say they are fine. As you say, arrange things so it doesn't happen again. And if local outages can be prevented altogether, then the global level takes care of itself. I am a firm believer in decentralized control as much as possible, to avoid single-point-of-failure problems and to increase scalability.

If you check the script I sent you, you'll see that it has the capability for that. Basically, I shout and if anyone hears, I die.

Unfortunately, I found that I died too quickly. And, unfortunately, the messaging in LL is not very deterministic. IE, you have no idea when it's going to fire and when it's going to be heard.

I could come up with a lot of soft rules which decrease the likelihood of replication going out of control, but as I put in more rules the more complex it became. At some point, I realised, I could just bug myself out and "goo the grid" as it were purely by accident.

One idea I had was to test in preview. At least if I took preview down, no one will get toooo mad at me

Might want to warn a linden, first, though

*sigh*
Treat it like how cells devide. Use the start paramater as a sort of telomere length

Some articles on Telomeres
http://en.wikipedia.org/wiki/Telomere
http://www.findarticles.com/p/articles/mi_qa3874/is_199809/ai_n8823970

That doesn't work if you expect to replicate widely because of the large amount of parcels which will not let you pass or rez.

You can tweek but at some point your 'telomere length' will be too much for the grid to handle.

The confusion here might be that I am interested global replication, which is the problem interesting to me.

Simply replicating in a constrained area doesn't seem particularly interesting.

I think another solution, which could work, is to contact a central server and see if there is "room" for another object. Basically, come up with the assumption that we can have no more than 20 replicants per sim and we don't replicate until we get an answer back.

The only problem with this, is that will be a lot of emails getting send out (20*500 sims) every second.

We could computationaly elect a prim per sim which tells everyone whether they can replicate or not. I get nervous though, because a) the code could have a bug (it only takes, one bug) and b) LL's messaging system isn't very reliable.

Yeah, this is probably my favorite.

pleased with yourself, are you?

Well, yes, how the current O2O solution that has been forced down our throats top down kinda amused me, yes.

Oh good.

I'm really fucking amused too. So is Surina. Oh, and Francis is, I'm sure. As are Strife and Xylor. And probably anyone else trying to be innovative and creative with this function. And anyone that ever bought their products. I'm sure we'll see LOTS more of them before the week is out and people have had a chance to do damage assessment.

But glad you're amused at least.

Hmmm, yeah. Well, re-read this thread. I think I deserve at least that much.

What? 8 pages of you ignoring peoples reasoned objections and arguments and then having them all keep pointed out you're doing so for you to ignore that too? What was your point? That somehow you won and pwned the lot of us?

You were right about one thing: your prediction that LL would sometime down the road make a fucking ridiculous knee jerk nerfing of the functionality and thereby fuck over a whole bunch of residents and content creators.

Well done.

I just realised that someone can fly around and rez objects by dragging them out of his/her inventory, and there is NO LIMIT to how much he can do this - this must be stopped at once. Think about the children! NNOOO, my knee! Rabble, rabble, rabble! RABBLE RABBLE RABBLE!!!

Guns don't kill people, people kill people. No wire hangers! Never EVER shake a baby! And never EVER enable physics on your baby and unlink it!

Seriously, before I get and more cynical I'll stop and just second what Jillian(and everyone else) has said 100 times over - NO. Don't break functionality to try to idiot-proof SL.

Too late. The idiots win.

Thought this was a forum, not a chat room

there's a difference?

Hey! I had a kinda dumb idea but...

What if, when an object crosses a sim border, it remembers that it did so.. and it automatically checks every few minutes to see if the sim ir originated from is still running. If the 'parent' sim crashes, then all scripts on the object shut off(or the items are returned to the creator) and the lindens are immediately informed, just in case?

I think if there were a way to make this work, and make it work for all objects rezzed by a 'wandering' object.. etc etc..

Already emailing it to Kelly Linden, but thought I would ask for some opinions..

*Edit* One last edit.. you can crash a sim without scripting, and if you've got the patience even without physics. I've done both unintentionally(both in empty or near empty sandboxes). No amount of putting rubber bands on peoples claws is going to stop malicious intent, and as long as SL lets people into their grid for free, so that they don't even have the tenous affection that a purchase makes, then these stupid spats of gridwide drama are going to keep getting more prolific.

I say we get our pitch forks and torches and give the messenger what he deserves

Ooh can we? Please? You promise?

LindenLab:FuckingUpContentCreators::We-Value-Your-Imput:X

X = you tell me...

Ok Kris, I'll bite, which reasoned objection were you referring to?

can't this thread just die? it's a year old. The only suggestion in it that was ever implemented was this theads name sake (and then unimplemented). Other suggestions in the thread to make it possible for sims to talk to each other about active infections and take automated responces have been... ignored. The situation is simple, LL doesn't want to invest the time and effort to write the software needed. When will they relize this is inevitable? It doesn't take a genious scripter to write grey goo.

The problem is simple, the solution is complex.