llAttachToAvatarTemp Questions

[KeeperS Karu]

Heyla and well met!

I know that the following is possilbe:

1. An avatar touches the vending object

2. The vending object rezzes an item in its inventory

3. The inventory item, equipped with a script with the temporary attachment code in it, attaches itself to the avatar, if the avatar gives permission.

 

But I am thinking, "What if my shop, for whatever reason, happens to have its prim space maxed out, right then?" The inventory object won't be able to rez itself long enough to attach, right? So is there a way to produce this same effect by sending the inventory object directly to the avatar? I tried combing the SL Wiki and LSL Wiki for something that allows an object to directly attach its inventory to an avatar, but I haven't been able to find anything. I'm hoping I'm just not using the right search terms? Or am I out of luck, with that particular avenue?

If there is no way to temporarily attach an item sent directly to an avatar, I am thinking of a workaround where there would be a vending object and a placeholder object, and the sequence would go something like this:

1. the avatar touches the vending object

2. the vending object checks to see if there is enough space to rez its inventory

3. if there is not enough space, it deletes an in-world placeholder object.

4. With the placeholder object gone, the vending object rezzes the inventory object.

5. With the inventory object rezzed, it does the following:

     a. If the avatar touches the rezzed object, it offers to attach itself.

     b. If the object is not attached after a certain amount of time (say 60 seconds), it destroys itself.

6. Either way, after 60 seconds, the vending object checks to see if there is space on the property, again, and if there is, it rezzes the placeholder object.

Would something like that be possible? If so, what functions/etc. do I need to look up to try to make the script?

 

Thank you for your help!

KeeperS Karu (Keeper S. Karu)

[Dora Gustafson]

That is possible
You would build it around llGetParcelPrimCount() and some of the more general functions
Lets see if you can create the logic

:smileysurprised::smileyvery-happy:

add: I know of no way to make a temporary attach of a not rezzed object

[KeeperS Karu]

Ah! Thank you!

That helps! Been looking at sample codes for rezzing and derezzing objects, too.

[Stickman Ingmann]

I was dealing with a problem similar to this myself recently. One of my ideas was to set the rezzed object temporary before putting it into the vendor. This has its own problems, as temporary objects can be deleted unexpectedly. If I recall once every 90 seconds a "cleaning" cycle is executed which deletes all temporary objects, regardless of age. I've had brand new temporary objects get caught after a second or two and wiped.

If not temporary, you just need some communication between objects to coordinate all the rezzing and derezzing.

Keep in mind communication instant instant. It may take a frame or two (0.022-ish seconds) for a listen message to get to the object to tell it to delete. So using:

llRegionSayTo(gkPlaceholder,giChannel,"Delete thyself");llRezAtRoot(gsInventoryTempAttach,llGetPos(),ZERO_VECTOR,ZERO_ROTATION,0);

 one right after the other may still result in "not enough prims." Adding a short sleep, or having the placeholder object reply just before calling llDie(), are a couple ways to be sure the action has been taken.

[KeeperS Karu]

So when making something like this, I need to give the receiver object time to actually receive the message and delete itself. Okay. That makes sense.

I've been looking at a few ways to get the vending object and receiver object communicating with each other. I found some functions called llSetRemoteScriptAccessPin and llRemoteLoadScriptPin. What's the difference between using these functions and having the receiving object listen for a command from the vending object?

[Stickman Ingmann]

The pin scripts are used for actually transferring running scripts between objects. That's a bit more complex than what you're looking to do, I'm sure. Sending a spoken message with llSay(), llWhisper(), llShout(), llRegionSay(), or llRegionSayTo() would be much simpler.

I'm partial to llRegionSayTo(). In this case, you only need one object to hear what you're saying, so there's no reason to go broadcasting it into a radius. And when you llRezAtRoot() you get the object_rez() event, which tells you the key of what you just rezzed.

On object_rez(key id) you'll want to have a llGetOwnerKey(id) == llGetOwner() to verify that the object actually rezzed, as it can be used to check for rez failure if the key is invalid. The wiki page probably has more about that, though it may only be listed as a jira bug link.

[KeeperS Karu]

Hm... Yeah, I think the pin scripts might be more involved than I want it to be.

[Qie Niangao]

---

[...] One of my ideas was to set the rezzed object temporary before putting it into the vendor. This has its own problems, as temporary objects can be deleted unexpectedly. If I recall once every 90 seconds a "cleaning" cycle is executed which deletes all temporary objects, regardless of age. I've had brand new temporary objects get caught after a second or two and wiped. [...]

---

I don't doubt that this has happened in the past, but I don't think I've ever encountered it, and (almost) always use temp-on-rez objects with llAttachToAvatarTemp (mostlly because it's less work both for me and for the sim than making them go away with a script if permissions aren't granted in a timely manner).

So I'd be interested in whether this problem with temp-rezzed objects has been seen in the past year or so. There was a pretty major change in temp-rezzed object behavior a while back (notably, the clock now keeps ticking after crossing into a new sim), so maybe the old misbehavior got fixed along the way.

[KeeperS Karu]

---

Stickman Ingmann wrote:

The pin scripts are used for actually transferring running scripts between objects. That's a bit more complex than what you're looking to do, I'm sure. Sending a spoken message with llSay(), llWhisper(), llShout(), llRegionSay(), or llRegionSayTo() would be much simpler.

I'm partial to llRegionSayTo(). In this case, you only need one object to hear what you're saying, so there's no reason to go broadcasting it into a radius. And when you llRezAtRoot() you get the object_rez() event, which tells you the key of what you just rezzed.

On object_rez(key id) you'll want to have a llGetOwnerKey(id) == llGetOwner() to verify that the object actually rezzed, as it can be used to check for rez failure if the key is invalid. The wiki page probably has more about that, though it may only be listed as a jira bug link.

---

I played around with some possibilities, and I decided to actually try the one idea you had mentioned, where the object rezzed is a temp on rez object. I have it set so that, when the timer event counts down, if it isn't attached, it dies. If it is attached, it goes from temporary to a regular object, so the avatar can use the HUD for as long as needed. I'm actually a lot happier with this result, though I am keeping in mind what you said about regular sweeps to clear out temp items. I think I'll leave a warning that it may happen, and they'll need to rez the HUD, again. It just seemed like the easiest of all solutions.