Selling Procedural Objects

Have figured out most of the object manipulation scripting, but I am still a little weak on the interations with ownership and payment. For the moment ignore why I want to do the following, because it is a long story (at the bottom).

Can a script rez objects and then set them for sale? or pull them back into its inventory? or offer them to a specific user directly?

I have an object that dynamically creates other objects, depending on input from a user. These objects are manipulated (resized, textured, etc) after being rezed, so will be different from anything in the factory's inventory. I am trying to come up with a way that users will be able to preview the created objects (including their parameters) before paying for them. Thoughts?

<edit>The mechanism I think I have working is to sell pre-paid factories, which store a balance internally. When the balance runs out, you throw the factory away and get a new one. Unfortunately that means that there is no way to preview without draining the balance...</edit>

I don't imagine setting it for sale to a particular person would be an option through scripting, as it's not an option on the editing tab. This is a veru unique and interesting idea all around though and I'm interested in hearing from someone far more edjucated than myself on what could be done to achieve this...

I'm not completely sure I understand what you are going for, but this might work from what I gather.

have your system rez an object with no copy, full mod permissions with a script that has NO permissions.

in your main script, right before you rez the object, choose a random channel, turn a listener on using llListenControl() (open listeners = bad) and in the llRezObject() function send that channel as the start parameter.

in a no copy/mod script in the object being managed by the user, use any number of systems to tell when the user is done and have that object send it's prim parameters using llWhisper(CHANNEL, llList2CSV(llGetPrimitiveParams)) received by a script (sometihng like Customizer) in the main controller that saves this as a list and llDie() to delete the temp object

now rez the real object also with the channel as parameter that has a script that sends back it's key and and a randomly chose PIN (use llSetRemoteAccessScriptPin(PIN) to set this) to the main object's main script.

now, finally send that object to be customized the Customizer script using llRemoteLoadScriptPin() and then please shut off listener

the Customizer code should be set up like this:
it receives link message with the channel to listen on (the channel doesn't haev to be random if there is only one of these and therefore wouldn't need link message)

it uses llCSV2List to assign prim parameters to a list (customPrim) to be used in setup

in state entry it uses llSetPrimitiveParams(customPrim) and voila the prim takes on it's custom look.

Quite a workaround and there is probably a much easier way, but it's late and I'm writing this on the fly and it's a place to start.

Oh and of course if you are using multiple prim objects, each prim would send it's key/PIN and parameter lists would be sent to seperate scripts
Custom1, Custom2, etc.

eh, good luck

That part is easy, and done . My question is how to handle the in-world permissions so that someone could produce, say, a vendor that previews and sells procedural flowers.

My current priority is getting RL tools written to create object descriptors for interesting objects. Probably the first thing that will hit market is a drafting tool to easily fab custom houses...

*: Loading textures and scripts from a local library is pending me writing the code, but are fairly trivial. Creating them dynamically is AFAIK impossible with the current scripting API.

Perhaps use the lRemoteLoadScriptPin() method to load an auto-die script so that after a minute or so it derezzes.

Solved, sort of. Am moving on to the supporting tools in hopes that the scripting will be extended by the time I am finished. Was not aware that permissions on script-rezzed objects were maintained, though it does seem obvious now.

I set the prims out of which the object will be built (not the fabber though) for sale and added a script to self-destruct them on command from the fabber. The changed(12 event removes the prim-configuration and self-destruct scripts. The price and sale options of an object are set by its link root, so can be set easily: The fabber has a saleable object for each needed price and configuration of root, plus unsaleable objects for the link children. Could also produce freebie objects the same way.

Limitations: Each linked object needs to be purchased individually. There is no way to support automatically boxing the produced object(s) or giving them to a user upon a single payment. No way to dynamically create scripts/notecards/etc, they need to be installed in the fabricator manually to be copied to children.

### PLEASE DO NOT REPLY TO OR QUOTE BELOW THIS LINE ###

Have a few possibilities for how the deployment will work out. Feel free to think about it for later or PM me, I will probably start a thread elsewhere before making a final decision. Unless there are more scripting ideas, this thread should die...

API open or closed?
Implementation proprietary, GPL, BSD, public domain?
Owned by vendor or customer?
If vendor, activated automatically or manually?
If customer, bound to a single vendor or open to all vendors?
Run at shop or on customer's land? (high-prim houses!)
Billed per-fabber, per-object, by another mechanism
(e.g. service that sends instructions to the fabbers)

And yes, believe it or not, I am mulling a fair number of the combinations. The fabber is not horribly complicated to write, I rather hope a good coder could do it in a weekend. On the other hand there are a lot of lines involved, so I would like to see something back from it.

The really interesting (and complex) work is in the programs that feed the fabber instructions: everything from a drag-and-drop house designer to a full-blown model importer just has to send some e-mail to a fabber to get the objects in-world.