making an object-rezzed object non-freebie?

Background: As many of you know, MLPV2 is a scripted menu system for putting poses in furniture (usually beds), and supports rezzing a 'prop' object per pose.

The problem is this: One MLPV2 product maker has a good business case for selling beds xfer/no-copy. However, the props have to be copiable so they can be rezzed by the bed (because it can't take it back into inventory and it needs to work repeatedly). In order for their bed to be xferrable and rezzable, the prop has to be copy/xfer. But she doesn't want the prop objects to become freebies.

Now, I know there are workarounds to selling things xfer. Still, it would be good to have a solution so that props can be made non-freebies, either not copiable or not xferrable by the customer. There's an LSL call to set object permissions, but it was never implemented because they were worried about security loopholes.

I have a partial solution involving llDie whenever the item is rezzed with nonzero rez arg, but that can be worked around. Does anyone know of a good solution that works for open source? And hopefully one that's not too terribly complicated (but now I know I'm dreaming...).

The only thing I can think of here is to make the on rez event call die if it isn't fed a specific start paramater.

I haven't poked around MLPv2 yet so I don't know if its that simple.

I ran into the same problem recently, with a "giver" object.

Permissions of "Device" [ +M +C -T ]

When rezzed, owner clicks device, is "given" a "handout" item. If anyone else passes by, they (Person X) clicks it, and they must ALSO be given the handout item.

To accomplish this, the permissions of "Handout" *MUST* be [+C +T]

Unfortunately, this creates a "freebie" item, out of "Handout".. while the M permission can be denied, it does allow "anyone" to take the "Handout" item, and reuse it in their projects. (for these situations, I will ususally try to keep my "Handouts" well labelled as coming from my shop, and no-mod. (it's basically a chance to hand out a business card).

What was suggested above really is an excellent suggestion. In your case, the "Handout" is a poseball, and it's rezzed. So you can make use of the on_rez event. In terms of llGiveInventory (my example) you don't have that luxury.

One thing you might consider, is NOT rezzing the items at all. Instead, have a set of unused prims linked into the linkset. Then, at the given time, use something like llSetLinkPrimitiveParams (or script each prim individually) and have them "reform and reshape and recolour" into the proper "prop" (dildo, whatever).. then when no longer needed, those prims return to "inside the bed". Or just having a prescripted "drone" prim inside the bed's inventory, and use rez and link, to actually progressively rez the prims when needed, link them into the bed, then do the "move and build and recolour" and when no longer needed, unlink the prims and let them die.

It is that simple, only that isn't sufficient because there's a way to thwart that given that MLPV2 is open source. The only workaround I can think of involves a crypto challenge/response handshake using the original maker's bed's key as a crypto key, and I really don't want to have to go that route, unless someone's solved it nicely in open-source.

Haravikk has recently devolped an AES implementation in lsl.(This isn't public key crypto though...its private key)

Almost, except that I mentioned that in my OP, and said that it isn't sufficient. (True, I said "nonzero rez arg" but regardless of the rez arg, if it's not a handshake, it's easily thwarted by any competent scripter.)



Those solutions are more compex than the challenge/response handshake -- essentially duplicating the skidz holo rezzer, if I understand that thing correctly. Currently, props are pretty easy for makers to configure: just drop my script in their object, put it in the bed, have the bed rez it, move it to where it goes, press a button, save the results to notecard, and done. I don't want to make it much more complicated for them than that, and I don't want to completely redesign how the prop function works either.

I guess challenge/response is the way to go, but perhaps I could use something less complicated then crypto methods, which would raise the bar enough for folks to keep from stealing a teddy bear. (Yes, in this case, it's a teddy bear! ... a cute one, I'll admit.)

Private key could work, though public key would simplify life because the public key could be copy/xfer without causing any grief. The private key could be in a no-mod/no-copy/xfer notecard in the bed and would essentially grant permission to use the public-keyed item.

gah, i really don't want to go down that road!

1) Make the props NO-MODIFY
2) Place a script which calls the llDie command when applicable in a CHILD-PRIM of the object. Placing it in a child-prim is very important, since child-prims cannot be opened and thus emptied, while at the same time, no script can be added to the root prim to affect it in any way either, because the object is no-modify.

Sell the props separately? With their own dedicated prop rezzer. Place simple code in the bed to say "hey rezzer, if you're out there, please rez item "dildo" at location "blah"

Child prims can be opened in no-mod objects. However, even in the root prim, you can't delete a script from a no-mod object. At least, my attempts to do so fail.

The real problem is the "when applicable" part, and making it too difficult to fake, with an open-source rezzer (the bed).

Winter, your suggestion begs the question. How would the rezzer rez the object without running into precisely the same problem?

Sorry I sound like such a pessimist here. It's not a simple problem!

In any case, BIG THANKS to all for the suggestions, and please keep them coming! Please don't hesitate to post, because ideas are always good. And I'll try not to be such a turd.

Don't make the rezzer transferrable to the next user.

Your entire situation here ASSUMES that all parts must be full COPY and TRANSFER for your idea to work. Well guess what? that makes it a freebie, and the moment you do that, the genie is out of the bottle.

If you want a solution for this, you need to start thinking outside the box. Have a "props rezzer" people can buy separately from you. offer a networked vendor that people can place in their shops, and buy the props rezzer directly from you.

The one thing you HAVEN'T told us.. is what this "good business case" is. Without that fairly critical piece of information, we're forced to throw out random suggestions only to have you shoot them down again and again.

As you've outlined it.. you're screwed, get used to freebie props, or get used to no-transfer furnishings. (and honestly, with the asset deletion problems over the last year, I don't LIKE "no copy" permission.. period)

Since she seems to think that her props have inherent value in themselves, has she considered selling the props separately and no-transfer, and then having people load them into the bed themselves? You could do that with a script (have the bed "request props" and then use llGiveInventory to send the props from the giver, to the bed.) That of course will make the bed no transfer, until those props are removed again.

Wouldn't be hard to script a button to delete all no-transfer items in inventory, should the person decide it's time to sell the bed... kind of like shareware that has an "unregister" button for when you want to give a copy to a friend.

This is pretty much EXACTLY the same idea as having a separate rezzer. With a separate rezzer, it wouldn't screw up the bed's permissions, and it wouldn't require as much customer support with customers complaining "I added the props, but now it's NO TRANSFER AND NO COPY!!!!"

The simplest business case is that the seller wants customers to be able to buy them for others. Yes, I know there are other business models to permit this, but life is simpler for the seller and buyer if the item is simply "xfer/no-copy". It's a sales model everyone understands, and we're just trying to provide that capability but with rezzable props. In the particular case where this came up, it's a maker of beds for children. The vast majority of customers are parents buying for their children, who want to be able to give it directly to them.

The prop rezzer runs into the same problem. It has to be copy/no-xfer to work, and that's not the desired sales model.

I suppose it would be possible to use a vending system where the bed requests the props from a distributor object when it gets fired up by the recipient, and the delivered objects could be copy/no-xfer. The purchaser would of course need to be warned not to start it up until the intended owner gets it, after which time it becomes essentially no-copy/no-xfer, and possibly with a 'delete no-xfer contents' as you suggested. I suspect that would be even more complicated than a challenge/response.

Looks like I'm going to have to look into crypto again. Haven't done that since the late 90's. It's cool stuff, no doubt about that.

Thanks again for your input!

The problem there comes in again.. people can just pass one bed around for days, and everyone gets the free props. This is a problem that plagues "automatic updaters" as well. Put simply, copyable items are 100 times easier to update, than transferrable.



I'll give you my answer in one word...

XStreetSL.

Have her sell the items as no-transfer.. and tell her to list the items on XStreetSL.com. "buy as a gift" is totally built into their site, and it works a helluva lot better than ANY other cheesy scripted workarounds.

In my shop, I use a "Gift Certificate" (from AubreTec).. I'll tell you, it's bone simple.. Buy the transferrable gift certificate, give it to the intended recipient of the gift, then the recipient rezzes the certificate and CLICKS it.

and yet.. 1 in 4 fails, not because the certificate is bad.. (it's NOT it's awesome).. but it fails because the recipient "OPENS" the certificate, and uses "copy to inventory" ripping the scripts out of the no-copy/no-mod certificate.

The BEST solution.. in 2+ years of trying to tackle the "buy as gift" problem... honestly.. is to use SLX (now XStreet) or just tell people to give their friend the money.

Everything else can be gamed, cheated, and broken.

It's so easy to create a "llLoadUrl" button for the SLX page that is relevant for each item in the shop.. and it allows you SO MUCH opportunity to explain the item, offer videos, buyer reviews, etc. A friend of mine actually integrated this idea into his vendor designs, and it works like a champ.

I did not read all of the previous discussion carefully but I don't think this idea was touched upon:

Owner A buys bed.

Bed owned by Owner A rezzes Object A.

Object A has a script hidden in a child prim that on rez changes states to state B.
State B has an on-rez event that will check for Owner the next time it is rezzed.

Owner A takes Object A into inventory, and gives a copy to Owner B.

Owner B rezzes Object A.

Object A, now in State B checks for new Owner. If Owner has changed Object A deletes itself.

ack, I hate doing this but, here goes.

With the exception of challenge-response, these solutions all fall prey to this cheat:
Customer does the following:

- rezzes bed and drags props into contents.
- writes script to rez prop passing same arg as MLPV2 would, and also sends keepalives as it would.
- drags prop into object with new script, creating a cheat-rezzer
- gives cheat-rezzer (with prop) to friend

Then,
- Friend sets out cheat-rezzer and causes it to rez the prop
- Friend moves prop to wherever they want

Admittedly, the customer can't ever take the object into inventory, but they can take their cheat-rezzer into inventory instead. They have to leave the rezzer there to send the keepalives. Perhaps this is enough safety. It does keep the item from being a freebie; instead the cheat-rezzer containing it is the freebie.

I'll probably delete this post, esp. if we can't find a better solution.

Arch, yours is easier to cheat: just drag object from bed into your inventory and give it to friend. The prop will think the friend is the customer. (Don't feel bad, I made the same mistake earlier!)

This may be totally silly, and I'm TOTALLY inexperienced with these things, but what about combining a few simple things?

If the bed is no mod, the prop could do a llSensor once filtered on the name of the bed when it rezzes, to see if the bed is there instead of a cheat rezzer? (And llDie if not of course, and maybe have a prim surrounding it that shrinks or goes alpha or something so no script areas don't defeat the llDie?)

The likelihood of someone making a cheat rezzer and realizing it needs to be named EXACTLY as the bed is absurdly tiny for anyone who hasn't read this thread, right? (Of course the bed would want to be no mod so customers couldn't rename it and "break it"... )

Combing that with "unbaked" perms?, so the prop is copy/trans in inventory, but automagically becomes no trans when it's rezzed?

So that way most won't even realize there are full-perm versions in the bed's inventory, and not even think to script a cheat rezzer (which probably won't work if they do without the right name)...

Actually making (no transfer) part of the teddy bear object name could further confuse the issue too?

/me giggles, can you tell I have more non-scripting solutions to this problem as compared to most of the responses? Of course, the easiest all around is using XSt (formerly SLX) as Winter pointed out, nearly everyone is familiar with it, it allows buying as a gift so resolves these issues entirely! It also allows it to be sold as a copy item, which guards against inventory loss. So many stores suggest, "Want to send as a gift? Please use XSt." as I do!

Thanks Crystal. Unfortunately ...

The bed needs to be mod so that the customer can change positions and save it in notecards. People who sell MLP/MLPV2 beds no-mod are doing a disservice to their customers. If scripts could modify notecards, this wouldn't be necessary.

MLPV2 source is available to all, so anyone who reads the scripts can figure out how to cheat, if we try to use obscurity as a security mechanism.

I tried the unbaked perm thing; great idea, but doesn't quite work. If the prop's perms are unbaked in the bed's inventory and the customer drags it out of the bed into their own inventory, they're still unbaked, and the customer can copy the prop to their heart's content before rezzing it.


So far, it looks like the only options are SLX, or crypto challenge/response. (And I think there's a problem with the challenge response, too ...)

Ah well.

Actuallies, the only reason the bed would want to be no mod with my sensor idea would be to minimize customer service IMs... So customers wouldn't keep IMing saying "the props don't exist anymore" after they rename the bed! (With the seller having to have in her profile, "if your props disappear, please rename your bed back to it's original name" which would kind of give it away...)

Even if her bed was named "Cuddly teddybear gift bed DO NOT RENAME" I wouldn't be surprised if people did?

And yes, unbaked perms wouldn't stop moving items from inventory to inventory of course, but they would die without the bed there...and would it be apparent people could even do that with the rezzed versions being no trans?

/me shrugs and still favors XSt herself

Oh! What if the bed renames itself back to it's original name when it rezzes a prop? That might prevent customer service issues without making it so obvious why?