Offer a copy of an Object's rezzed self - not as inventory item.

[Frankie Rockett]

Hi Gang
I want to know if I can programatically get an object to offer itself, without having a copy of itself inside, so 'llGiveInventory' is not an option.

I have what might seem like a perverse requirement here so a few words of explanation before I get back to the question. I have what for shorthand I'll call a 'game' for solo players in which objects are rezzed around a central controlling prim (that I'll refer to as the CP). The CP listens for the UUID of the latest prim to be rezzed and immediately links to it. This leads to a large object building up by accretion as more objects are added. At the end of the game the user clicks a 'Clear' object that tells the CP that a Clear is requested. The CP sheds everything by a) declaring itself to be Temporary, b) unlinking all the child prims, and c) declaring itself to be not temporary. So 60 seconds later, the setup is clear and ready for the next game. Now, in testing, users have expressed the wish to have a copy of the object (prior to clearing it). The object contains a listen remember, so in theory I could send a 'Give' command to it for it offer a clone of itself to the player.

Or could I?

To the best of my rather incomplete knowledge, llGiveInventory is the only function that might do this, but since the object was dynamically created, there can be no copy of itself within itself that it could offer to give via llGiveInventory. So; is there a way to programatically have a script offer the object  - rather than an item in it's inventory?

I can't decide if there's a glaringly obvious way to do this, or it's actually impossible. Nothing in between those two extremes I bet.

Thoughts please?

Frankie

Edited December 11, 2019 by Frankie Rockett
Improving the title - maybe.

[animats]

3 minutes ago, Frankie Rockett said:

Hi Gang
I want to know if I can programatically get an object to offer itself, without having a copy of itself inside.

If the object is copyable by anyone, anyone can just do a "take copy" on it. You get a rez event and a change owner event in the copy, so you can tell this has happened and take whatever action is appropriate.

[Mollymews]

http://wiki.secondlife.com/wiki/LlAttachToAvatar

[Nova Convair]

With llAttachToAvatar you need to be the owner of the object.
Only llAttachToAvatarTemp allows to switch ownership - but you can not keep the object then and get no copy in inventory

Another way is to rebuild

The central controller prim stores the relative pos/rot/whatever of every single prim and contains a prim with a script that can execute pos/rot/reshape/whatever.
Once the structure is stored - you only need to take the controller prim.
The controller prim is able to rebuild the complete structure then - at the end linking and/or self deleting of the scripts can be performed.

[Frankie Rockett]

Hi

Two excellent approaches worth looking into. With Animats approach I could presumably have the script check it's ownership, then delete itself if it's not myself. I'll have to test that out and see what I think.

Nova's idea thrills me - it sounds like magic! How do I access this 'central controller prim'? Do you mean the root prim? Assuming so, how on earth do I get it to rebuild the state of itself when it was a multi-prim object?

Once I know that (which I'd love to at this point anyway), the base question still applies: how do I give the controller/or/root prim, complete with it's parameters and script for rebuilding, to the user?

Frankie.

[Qie Niangao]

Depending what you're trying to do here, Nova's approach might be sliced a little differently, where the controller prim outputs the specifications of how to rebuild this particular structure. And any other controller prim could rebuild it to those specifications.

An interchange language for controller prim 3D printers.

(Now ain't it a shame we can't construct Mesh models by UUID, the way we can sculpts?)

[Nova Convair]

Probably not quite simple 😀

In your build is a controller-prim that is able to gather all data of the finished build. That is the relative position and rotation, size, shape, additional shape parameters, colors, whatever is used. The data needs to be retrieved for every prim in the build.

Then your visitors can get a rebuild-prim. They can rez or wear it and this rebuild-prim will send a request to the controller-prim and the controller-prim will answer with the list of all the child prim data and it's own height over ground.

At home your visitors can rez the rebuild-prim.
The rebuild prim will move to the proper height over ground (so the model will fit - space to the sides I'd leave to the visitors - stupid placement will be punished)

The rebuild prim contains a single build-prim with a script - it rezzes that build-prim and sends it the stored prim data - for one prim - the relative position and rotation is re-calculated into absolute pos/rot before sent to the built prim. 

The build prim positions/rotates itself and performs additional operations for resize, reshape, recolor, retexture, whatever.

The rebuild prim will repeat the rezzing of build-prims and send each one one set of data from one prim of the original bild.

Once all prims are rezzed there will be a rebuild of the original.
Now the prims can all be linked by script and the scripts inside each prim can self delete.
The visitor now has a copy of the original build and can take it into inventory -
or use the build-prim again since that looks way cooler 😎

Some things to consider that can all be solved if it becomes a problem:

- size of the data-list in memory
- size of the messages when transfering data
- communication to the build prims - you can rez 10 per second but it will take a while until they respond and process their data - so you need to send every build-prim a different data package and will have to manage a stack of open requests/commands 😎 - or send one by one but that will take a long while until the rebuild is finished.

[Profaitchikenz Haiku]

2 hours ago, Nova Convair said:

- size of the data-list in memory
- size of the messages when transfering data

I have a similar system to your suggestion, in order to limit data size in the messages rotations are transmitted as Eulers containing degrees, and all vectors are passed through a string handler that limits them to 2 decimal places before transmission.

As an alternative, which I also use successfully, the description field of a child prim can hold 128 bytes which is ample for three vectors giving size, local position, and local rotation (in euler  degrees vector form), so that when an entire linkset has been rezzed the root prim works through all the child prims reading the description, and sizing, positioning and rotating the child.

 

The system I have finally adopted is for the root prim to be given four notecards for the children to be set from the root, which supply prim type with path cuts etc, prim name size local pos and rot, texture uuid and parameters, and finally if necessary a fourth notecard supplies features such as lighting or flexible path. Of all the systems this is the most reliable, and any of the stages can be re-run of needed to reinforce parameters if the linkset gets accidentally messed up by edits. It gets away from all problems with listen delays and message lengths.

The reason for dealing with all the parameters in three or four notecards rather than one was adopted due to the chance of exceeding the maximum notecard line length read by a script.

Edited December 14, 2019 by Profaitchikenz Haiku