Uh oh... Attached object, rezzing new object from contents...

[Domitan Redenblack]

Following on from my previous thread...

Now my object is attached to an avatar, and I want to rezz a new objects from its contents and link it in...

Is that possible? Looking at some wiki refs, seems not... Is there some way to do this?

 

For example, let's say the object is a hat, and I want to be able to rezz/delete feathers that fit into it...

 

ty

 

[Qie Niangao]

Yeah, a script can't change the linkset of an attached object (nor an object that's sat upon).

That's why many attachments include a bunch of alpha'd-out prims, with a script that swaps visibility of sets of prims.  One can be a little more sophisticated than that by changing all the prim parameters to transmogrify one configuration of prims into the next, calling llSetLinkPrimitiveParamsFast() for every prim that changes between configurations.

[Domitan Redenblack]

Ah yes.

Can you change the size of attached prims? e.g. make them tiny and transparent?

[Darkie Minotaur]

Yes

[Charlot Huet]

yes,look up.

llSetLinkPrimitiveParamsFast() in SL wiki.

very powerful function.

[Domitan Redenblack]

Seems like a nice way to hide attached prims: transparent 100% and shrunk down too... So in this case I would need to have new feathers "installed" while the hat is rezzed on the ground, yes?

[Qie Niangao]

The hat would need to be rezzed on the ground if you really wanted to add  feathers as new prims not part of the hat from the start.  The alternative being suggested here, however, is for the hat come pre-populated with as many prims as it could ever need, and new "feathers" be introduced in the form of data that the script uses to do "feather-making" calls to llSetLinkPrimitiveParamsFast() on those already-linked but dormant prims.

[Domitan Redenblack]

Okay, thanks all. Here is my (naive?) plan:

1. Hat owner rezzes it on ground. Hat hides/shrinks any existing feather shown.

2. Hat owner drags and drops new feather from their inventory onto the Hat, which accepts it and runs code.

3. Code rezzes and positions the new feather automatically on the hat, based on some parameters, and links it in.

4. Code also updates internal database, so that a menu of feathers is available to Hat owner.

5. Menu selection of a new feather causes current feather to shrink and go invisible, and selected feather to grow to normal size and become visible.

6. Avatar Clicks upon the current feather are seen by code in the Hat itself (single prim), and a user menu of options is displayed.

7. The Hat root prim runs code to rotate the feather around the band, or sends a message to the feather so it can rotate itself. (ref: Blue Steel etc)

 

Have I mucked anything up here, or is there a better way to do this?

ty

 

[Rufus Darkfold]

Easier way:

When you invoke a menu item to change number of feathers (or whatever), it requests attach and linkset permissions,  then tells you to drop it when you have rez permissions.

Then when it detects it has been dropped, it rezzes new feathers, or removes old ones, and reattaches automatically.

 

[Innula Zenovka]

For what it's worth, I'd certainly go with with Qie's second suggestion -- that is, make the hat with as many prims as you could possibly need, and then hide/show/resize/move/retexture/whatever them with llSetLinkPrimitiveParamsFast calls.

I do this sort of thing for customers with their jewelry and that's the simplest and safest way I know to do it.

I forget who it was who first  told me this, but certainly one of most useful things I think I've learned about scripting, along with "don't bother trying to understand the mathematics behind quaternions" and "don't use llSleep when you should be using a timer"  was "if the solution involves linking and unlinking by script, there's usually a simpler one."    

 

[Domitan Redenblack]

---

Rufus Darkfold wrote: ... When you invoke a menu item to change number of feathers (or whatever), it requests attach and linkset permissions,  then tells you to drop it when you have rez permissions.

Then when it detects it has been dropped, it rezzes new feathers, or removes old ones, and reattaches automatically.

 

---

Very interesting idea; I will need to play with this a bit, thanks!

All - there will be 3rd party "feathers" added to the hat as well, so pre-bundling all the feathers before delivery is not really practical, thanks.

 

 

[Rufus Darkfold]

I use this method in the Navigator Charttracker HUD (a mapping HUD that can use arbitrary maps).   It is free, full-permissions, and open-source, so you are welcome to use code from there.

I will be breaking that code out shortly, since I also want to use it for my hair.

I will give you a copy in-world if you like.

 

I'd love to see your finished product.

 

[Qie Niangao]

---

... there will be 3rd party "feathers" added to the hat as well, so pre-bundling all the feathers before delivery is not really practical, thanks.

---

Okay, but the prims that a script could use to form those feathers could be bundled into the hats in advance.  In such an approach, a third-party "feather" is really just data fed to the hat script about how to form the feather from those pre-existing prims.

The third party feather developers don't need to know all the magic of converting feathers to feather-forming data.  Instead, you could supply them with a script to embed in their feather that does all the llGetLinkPrimitiveParams() needed to read their feather  and all the communications of those read parameters from that feather to the hat's script.

The end-user, then, would just rez the third-party feather somewhere nearby while they're wearing the hat, and an identical feather sprouts from the hat as if by magic.

(Note: There are some limitations as to what properties of an attachment can be reliably modified while the thing is attached, and some of those depend on permissions, so this might bear some manual experimentation first.  But I don't know of any problem with changed prim appearance.)

 

[Domitan Redenblack]

Qie, thanks The "feathers" can be any object really, so "data to form them" might be a bit hard.

I really need to look at the cleanest/easiest ways to drag an object from inventory onto the "hat" rezzed on the ground, which then rezzes the "feather" from inventory and positions it, etc. So far I have this much working.

Question: The Wiki that Darkie referred to has an example that "asks permission to attach", yet I have seen no other objects I own "ask permission" first; they just do it. Is there a reason we must ask permission first? We can assume the person owns the "hat" and the "feather" with proper object perms.

 

ty

 

[Qie Niangao]

Attaching from Inventory doesn't require permissions, but anything rezzed in world that wants to attach to an avatar directly has to get permission first.  I don't know of exceptions to that, although an already-attached object is granted that permission without having to ask the user directly.  Once a script has a permission it can retain it, so I guess if somebody dropped such an attachment, it could be scripted to re-attach itself without needing to ask permission again.

[Darkie Minotaur]

Just to add the last option: Of course you don't need additional permission for attaching a rezzed object which you right click and attach by explicitly choosing this option.

[Domitan Redenblack]

Sorry, brain damage here. I should have said: Question: The Wiki that Darkie referred to has an example that "asks permission to LINK", yet I have seen no other objects I own "ask permission" first; they just do it. Is there a reason we must ask permission first? We can assume the person owns the "hat" and the "feather" with proper object perms.

[Innula Zenovka]

---

Domitan Redenblack wrote:

Sorry, brain damage here. I should have said: Question: The Wiki that Darkie referred to has an example that "asks permission to

LINK

", yet I have seen no other objects I own "ask permission" first; they just do it. Is there a reason we must ask permission first? We can assume the person owns the "hat" and the "feather" with proper object perms.

---

If you're linking stuff by script, then the object containing the script that calls llCreateLink  needs to have PERMISSION_CHANGE_LINKS for the call to work.   Once it's got the permissions, it keeps them for as long as the object is rezzed, unless you cancel it some way (a new permissions call or resetting the script) but I'm pretty certain you need to ask for it each time it's rezzed.