Problems with llGiveInventory?

Is anybody else having problems with using llGiveInventory to give to objects? I'm finding I can't give inventory from one object to another anymore; I get "blocked by perms" errors even on objects with full perms.

I've reported this as a bug, but while I wait for a fix, it's messing up my business pretty bad. Has anybody experienced this, or thought of a work-around? I've tried setting llAllowInventoryDrop(TRUE), even on the full perm items, but it did nothing at all...

Object to Object inventory giveouts are only allowed on the objects' owner's land now

I figure this is to stop potential abuse, but DUH it's ANNOYING for updating things people have bought and for creating simple replicating objects.

WHAT? I didn't see anything about this in the announcements.

I saw that reading the change log... It wasn't announced but added at the last moment because of the W-hat attack.

Forgive my ignorance, but where are these "change logs" of which you speak? Are they posted in the forums somewhere (as are the release notes)?

Personally, what appals me *most* about this llGiveInventory() restriction is the fact that it was so poorly publicized. This isn't the kind of change a scripter should have to learn about on page two of the scripting tips forum.

I'd have expected any such big change would have been included in release notes, or at the very least announced by a Linden in one or more of the Linden forums.

Thats not actualy true; it was added on the 21 the attack was on the 23.

Why they decided to "fix" this now is beyond me. Anyway there are various threads spread about the forums on the topic. One in the AI Group forum, one in the 1.7 feature feedback.

I have gotten an email back from Kelly, they will be reducing the restrictions.

EDIT:
It has been drawn to my attention i was wrong about the release dates (the release dates in the release notes are wrong). Formal Apology

The changelogs were included in the 1.7 announcement, though I think they called them release notes. In any case, I agree that the change should have been more widely and immediately publicized; I learned about it after spending a half-hour trying to diagnose the problem in my scripts; I thought it was an actual permissions issue at the time.

I've also spoken with Kelly Linden about the Lindens reapproching the issue. Our conversation was purely speculative, so I won't post it here, but hopefully this means they'll be taking a more reasonable stance on the issue. It doesn't look like they have any plans to restore llGiveInventory to full function - the ominous threat of grid-destroying grey goo still hovers over the Lindens - but perhaps they can be persuaded to reduce the particularly neutering restrictions.

If they must keep llGiveInventory restricted by land, I'd be able to cope with, for my purposes anyway, the following restriction models:

1) llGiveInventory restricted to originating plot, whatever that plot is. Of course, I've no idea if there's a way to do this, but it seems like there should be. Nix that; it sounds stupid. But I'm too lazy to delete it.

2) Restricting llGiveInventory (object to object, giving objects) to lands that either the creator or owner a) owns or b) has active or inactive office or membership in the group that owns. Most consumers would not notice this limitation - I've seen very few replication procedures meant to take place in the field instead of on one's own or group lands - but it would still constrain attempts at grey-goo level replication, as only 15 groups are available to members. I cannot conceive, then, of a scenario in which even the most determined user, or even group of users, could use this to any major adverse effect grid-wide. Sim wide, maybe, but not grid-wide. Other items, like sounds, textures, notecards, landmarks, etc, would hopefully not be restricted by this.

Of course, I'm not that bright, and I'm sure there are useful applications of O2O llGiveInventory that this would still thwart.

In any case, we need to keep vocal if we want this issue resolved quickly. The Lindens have, at the moment, much on their plate - I don't know about you, but SL seems to be operating at about 45 frames per MINUTE on my client - and this could easily get relegated to the backburner if left alone, much to the chagrin of scripters like myself.

Hi all.

I've only been on SL for less than two months. In truth: it was Scripting that got me hooked on SL. A world where code works! How nifty. And of the peril of self-replicating objects was obvious immediately.

And, truly, I thought one of the wonders of SL was that there'd been no effort to prevent it. I think that is, in fact, wonderful. But I've also thought a lot about ways to limit it. (Limit the number of generations for object-rezzing, assess a fee for object-rezzed objects and NOT user-rezzed objects, inhibit object-rezzing even more if the owner isn't nearby...).

OK. So can anyone describe the mechanism of the Big Grey Goo attack I've been reading about? Has someone posted a report of it? Thanks!

I can't answer your question directly (though I'd love to know myself), but if you haven't read the LSL wiki on self-rep, you ought to -- last time I checked it had a few links to forum threads describing real-world (erm, well, you know what I mean) examples of gray goo.

Ah, here we go:

http://secondlife.com/badgeo/wakka.php?wakka=SelfReplication

edit: and welcome, Davan, to Second Life!

While it is necessary to use llGiveInventory to create self replicating things that take over the sim, it is not the only requirement, so why pick on llGiveInventory? It is not possible to replicate very many levels without using llGiveInventory to give the object that you just rezzed a copy of the same object so that it can rez another copy from itself.

Anyone who builds a script in an object that closes that loop runs the risk of replicating uncontrollably. So clearly there is a risk in even having the ability to close the loop.

However, self-replication is not the problem, and self-replication can be a very powerful and useful feature if used carefully. The problem is when self-replication creates more than it should, more than the sims can support, more than is fair to other people in the sims. But note that there are other ways to create scripts that do those bad things.

My point is that the focus should be on where the real problem is, not on what technologies were used to cause the problems.

The real problem involves unfair over consumption of resources. And to me, the solution should involve making the consumption of resources fair again. Why should someone's objects be allowed to consume the resources of any sim if they are not providing any financial support for the sim? There is a limit on the number of permanent prims that is allowed in any sim by the owners of the land in the sim. So why should anyone from outside (who doesn't own any land in the sim) be allowed to come in and create any number of prims? That inequity just doesnt make sense to me.

Now it does seem fair and even useful to allow a limited number of prims to be created by anyone or moved into any sim, as long as the number is rather small and/or short lived (as in temp rezzing), and the total number of prims regardless of owner is still within some limit.

How can such a limit be implemented? It would seem to be rather easy to count the number of prims owned by anyone who owns anything in a sim. What's the problem? What's the downside?

Quoted for obvious truth.

Huns Valen suggested the use of statistical monitoring to distribute sim's resources. Something like a Weighted Fair Queue would certainly work IMO.

Arbus mentions: http://secondlife.com/badgeo/wakka.php?wakka=SelfReplication

Thanks Arbus, for the welcome and the wiki reference!

As with much of the Second Life "ethical culture" (if I may so call it), I'm impressed by the tone and practicality of that web page. It gives a very even-handed discussion of self-replication, and advice to practitioners with the assumption that we all of us want to be good citizens.

So! Does anyone have a first-hand account of the recent Gray Goo attack?

So, has anybody heard anything new about what I'm going to continue to think of as the llGiveInventory bug? After all, my entire business, and that of several others, is in a holding pattern until the folks at Linden Labs decide to get a cup of coffee and discuss the matter.

Anyone? Anything new?

It seems to me that this doesn't really prevent swarm problems... in fact it makes it easier to accidentally screw up.

Let's say you're doing an AL project. Instead of having a self-rep object, you need a three-level hierarchy of constructor objects, drone objects, and a hive. The hive creates constructors that spread out in a loose grid, so any drone's got at least one constructor in hearing range. When it wants to spawn another drone, it calls out its location and the nearest constructor rezzes a duplicate that bops over to join its peer and pick up the rest of its information from it.

This is MUCH more complex and thus MUCH easier to screw up than a regular self-rep.

* Because they are a friend of the sim/land owner who wants to let them.

* Because they are under contract to a sim/land owner

* Because creating content *is* providing financial support

- C

And don't forget landowners get dwell just for having people visit their sim.

Have a look at the AL forums or message me in-world.

I've implemented a mechanism that a lot of AL systems can use to get around this problem.

It won't help the vendors who need to build custom objects for people, and it won't immediately help AL systems that need to roam around the grid (though there's a workaround for that, too, if you don't need low latency replication).