LlRemoteLoadScriptPin weirdness

[Mikki Miles]

I try to set up an update script using llRemoteLoadScriptPin and it works fine so far. I tested it with an alt, and now it didn't work. By chance I tried later again when I've been online with both accounts, and all of the sudden it worked, while my main avatar was simply standing beside the alt. as soon as I logged out with the main account (creator), the loading failed again. I checked this repeatedly, evertime with the same result. the sheer presence of my main Ava, standing beside the box, made it work. how is this possible?
btw, I'm currently travelling and can't paste the code, but I couldn't get this out of my mind...

[Cerise Sorbet]

What is the land and object ownership situation like? Some operations that rely on group roles only work when that group member is present on the land.

[Mikki Miles]

thanks for the hint

I will check that as soon as I'm back home, but actually I don't think I used any of those functions...

[Qie Niangao]

I'm not so sure about the group permissions thing. This would make sense if the object being updated were group-deeded and the script doing the updating were owned by the main account (with appropriate group permissions) but otherwise it's not obvious to me how this could arise.

And that all raises the question of who owned what during the testing. I'm sort of guessing that the updater script is owned by the main account and the thing being updated is owned by the alt... is that correct?  And does the main have permissions to modify the alt's stuff? If so, I can make up a story that the sim only knows about that special permission when the main is an agent or child agent in the sim.

[Mikki Miles]

There's a script that triggers the updating process by saying the object's key to the updating maschine, this script belongs to the alt and is executed in the alt's object..

The updating machine houses the updating script using llRemoteLoadScriptPin and is owned by the main.

But actually it might really be a matter of the modifying permissions, anyway, now I have some more options to test, thanks!

[steph Arnott]

This may be a stab in the dark, but i have done this once before. I left a snippet in the code that effectivly kept me as the owner.

[Mikki Miles]

lol, I messed the whole thing up completely. I will start from the very beginning.

As you might have guessed, I'm not a very well organized scripter ;-)

[steph Arnott]

To be honist  do not worry about it to much. What you write now wont be the same as you do in a few weeks or months time. The only thing i would suggest is next time is putting what you wrote on the thread so others can scan it and see what there experience comes up with. If the script getting you upset, best go have fun and chill then look at it again.

[Mikki Miles]

I got it straight now. The thing is, that llRemoteLoadScript Pin won't load a script to an object that belongs to a different avatar.

I read the caveat from the wiki (If target is not owned by the same person, and name does not have transfer permissions, an error is shouted on DEBUG_CHANNEL.) more like if both of this conditions are given it will fail, but appearently it's like if one of both conditions is given....

[steph Arnott]

Thats script for you, does your head in, lol

[Innula Zenovka]

---

Mikki Miles wrote:

I got it straight now. The thing is, that llRemoteLoadScript Pin won't load a script to an object that belongs to a different avatar.

I read the caveat from the wiki (

If 

target

 is not owned by the same person, and 

name

 does not have transfer permissions, an error is shouted on 

DEBUG_CHANNEL

.) more like if both of this conditions are given it will fail, but appearently it's like if one of both conditions is given....

---

I can't get in to test right now, but I am pretty sure I remember (from my tests some time ago) that it just means "it the object to which you're transferring the script doesn't belong to you, you have to have transfer permissions on the script" (which makes sense).

The other thing, as Qie pointed out, is that if the item to which you're transferring the script doesn't belong to you, then you have to be able to modify the receiver item.

I never thought to test what happens if the owner of the target prim isn't on line, but I am pretty sure about those two qualifications.

 

[Qwalyphi Korpov]

---

Mikki Miles wrote:

I got it straight now. The thing is, that llRemoteLoadScript Pin won't load a script to an object that belongs to a different avatar.

I read the caveat from the wiki (

If 

target

 is not owned by the same person, and 

name

 does not have transfer permissions, an error is shouted on 

DEBUG_CHANNEL

.) more like if both of this conditions are given it will fail, but appearently it's like if one of both conditions is given....

---

A tiny clarification: Per the WIKI the llRemoteLoadScriptPin "Only works if the script owner can modify target."

target could be owned by a different avatar.  For example an object share with group & having a different owner was successfully updated in my test.   This worked with and without the script owner being present or logged in. Also worked with and without the target object owner present or logged in.

I confess I'm probably a bit unclear on what the original set of conditions were that involved the script owners presence being required to make things work.  I suppose a script could have sensor code that verified that the owner was nearby.  idky tho.