llSetForSale()

I hear that this function will not end up in 1.6 due to possible exploitation of this command.

In that case, instead of removing it entirely, how about enforcing some limitations? Some possibilities come to mine:

- llSetPrice() - instead of enable/disable the sale flag, lets say that you could only set the object's price, without affecting the sale flag itself.

- PERMISSION_SET_SALE - Only allow llSetForSale to work if this flag is set to true

- Another option: Linking several prims with different costs, will merge their price into a single larger cost. FOr example: A prim that costs 40, and a prim that costs 60: Combining both prims will result in a 100L$ worth prim-set for sale.

These are just 3 methods that I can think of to allow price changing while limiting abuse potential. What do you think?

Maybe also have the llSetForSale remotely set the price of an object, and cannot target itself. Kind of like how llSensor works, it can see everything but itself.

I agree with the original post's suggested revisions.

Would this be like particles, sit targets, etc, in that it would be a property of the object and not the script, once it was set?

Isnt it allready?

We will continue trying to develop methods to set items for sale through scripts. However, because of the high number of potential exploits possible, we will not be releasing this type of functionality until we are confident we have covered every possible avenue for exploit.

In that case, how about the third option I suggested?

Linking several prims that are set as "for sale" with different costs specified for each prim, will combine their costs into a single unified cost as the linked set.

It only sounds logical. How about that?

Stamp

CrystalShard:

Linking and getting the price right is one thing.. but think of the following:

I put up an object for sale. I put a script into it that sets it for sale again after a secret command is voiced. I walk around the world and collect the items I just sold, leaving the buyers with.. nothing.

So, the buyer must be asked before the object can be put up for sale. GetPermissions PERMISSION_SALE_CHANGE from the owner or something would be useful, but it would limit the use of the function to a degree where the command would be obsolete, since for every price change the owner has to be present.. and so he/she could cange the price manually as well, rendering the function useless.

So, I am sorry, but I do not see an option on how to make the command work without rendering it useless at the same time. Happy to be proven wrong on that, tho, heh.

Take care,
Leopard Loveless

Then again, how do you know if that vendor yuo've recently purchased doesnt have a secret back door for "give free copy to user"?

You cant, really. There's planny enough loopholes allready.

I am still all for linking prims to get the proper price. It sounds like the most reasonable.

Another option would be llSetForSaleTo(key avatar);

Similiary to land, allow only a specific user to buy the object, and no one else. If you want "security" you can also make sure that invoking the function will not enable the "Set Sale" flag. Just set the destination for-sale.

Frankly I have no idea why we do not have this function for non-land items yet.

I think the intention was for PERMISSION_SALE_CHANGE to would work much like PERMISSION_DEBIT and PERMISSION_CHANGE_LINKS. Where the owner would grant the permission and the script would have it from there on out (until the owner changed, script reset, or script requested permissions from another av).

I suggest three permissions. This way there could be no confusion about what is being granted.
PERMISSION_SALE_COPY
PERMISSION_SALE_ORIGINAL
PERMISSION_SALE_CONTENTS
Each would let you set the according type of sale for the object and the price.

Two solutions for linking prims that are set for sale:
1. Don't allow prims that are set for sale to be linked.
2. Combine the prices if they match the sale type matches other wise do not allow the prims to be linked (a prim that is not for sale could be linked to anything).

<ramble>
Let me create a senario for you: Say I make a vender much like Hiro's or Gigas Vender. Except I added an extra feature, that would give me at request the contents of the vender. I do not see how this is really any different. Or as a content creator I could put a die script in my products. You have to trust your scripter. If you don't, you should be using one you do.

Realisticly content in SL is not secure. Like all things in computers there is no such thing as security. The only things that comes close to security are obscurity and data hording (and systems that do security at the hardware level*). The client is the security hole. The client has to render the world and there is nothing that doesn't need rendering. The renderer can be reverse engineered, then the data hacked allowing for a faximile of the content to be plundered; a faximile so good that it would pass for the original (because it would render the same).

*computer security at the hardware level has been on the horizon for 10 years. The computer industry giants have been planning to release this on the general public. An example of the first generation of these systems is the Xbox. I would say we have probably another 10 years before significant saturation of these machines.

IMO SL is the Titanic, we know there are icebergs but will they sink the unsinkable ship?
</ramble>