Permission problem?

Hello all,

This is my first post on the forums, although i've been reading it for a while.

I have the following problem:

I have 2 objects and pleople can change the image on prim 1 by touching prim 2 (they can choose an image from a menu).

Prim2 sends the key of the selected image via llResionSay to prim 1 and it displays it.
This works well when the object is mine, but if i give it to someone else, it stops working.

I tried making objects and images full perm and it works again, but i dont want other people to just copy the images.
Is there another way of doing this?

Thanks in advance.

It's not easy to answer without knowing your script, but I guess the new owner has to reset the script. Or you use the llResetScript function in the onrez event.

When a script is created, the owner is 'read' by the object, and this information is 'saved' by the object, and persists even if the object changes ownership. To force the object to examine who the owner is you need to call the llResetScript() function. Standard practice is to put this inside an on_rez() event, so that when the new owner rezzes the object in world, the script resets, and the current owner is resaved, therefore:

default
{

    on_rez(integer foo)
    {
         llResetScript();
    }

// the rest of your code...

}

will do the trick

So, if you use llGetOwner() anywhere in a script, you'll need to do this so that when transfered, the new owner is re-examined by the script.

Yes, it is.

llGetTexture and the like will work provided the owner has modify, copy and transfer permissions on the object itself. You may be able to get away with making the textures less permissive, or you may just hard-code their UUID's into your script.

ok.. here is the code, but it wont help much i think.

master object resets when rezzed. It scans its invetory and resets again when changes and makes a list with the keys of the images it finds with

imglist+=llGetInventoryKey(llGetInventoryName(INVENTORY_TEXTURE,x));


This keys are then passed to the slave object, that displays it with (slave object has 2 prims)

setLinkTexture(i,llList2Key(imglist,i),0);

no big deal, but it doesnt work if the object is owned by someone else.

Ah! Check it:


This might be seen as especially poor advice, but I wouldn't worry too hard about images being copied on the internet.

However, is there significant reason to populate the texture list when the inventory changes instead of hard-coding the UUID's into the script?

This is not entirely true, as far a I understand the wiki.

When you initiate a llListen() using llGetOwner, then it will still listen to the old owner when the object is transferred. This is because, the Listen was initiated when the object belonged to owner A. So all you have to do is kill the old listen and initiate a new one. You can do this in the on_rez()-event, or in the change-state (CHANGED_OWNER).
llResetScript isn't always a good idea as sometimes there are some parameters which need to persist, even when the object is transferred.

As for the OPs Problem: This is definitely an issue with texture-perms returning a NULL_KEY. Try to llOwnerSay the Keys in your list in the receiving Prim and you'll most likely see the NULL_KEYs.

ooops was not

Thank you all for your answers.

What difference would it make to hardcode de keys instead of passing them?

I will try to reset the listen as well and see what happens.


I'll let you know.

My code as written will always work, as far as parameter persistence, once can generally store the needed parameters in the object description, and read them back in in the state entry. Most of what I write and sell is owner only controlled, and I do an llResetScript() in an on_rez() event, and read persistent data in that I save in the object description. It works fine, and it will solve the OP's issue. Dont really understand why this is such a matter of disagreement. According to the wiki:

On script reset...

* The current event/function is exited without further execution or return.
* All global variables are set to their defaults
* The event queue is cleared.
* The default state is set as the active state
* If it has a state_entry event, then it is queued.

IMHO, resetting a script on every rez is akin to having to jump start your car every morning to get it running. It indicates there's something wrong in the workings.

There are ways to write a script to get the same functionality, but not require a reset. In my opinion, that is a bad programming practice.

There's nothing particularly wrong with using llResetScript() on rez for SOME (usually simple) applications. Stating that it is required however is bogus and misleading.

There is some debate over whether storing a limited amount of data in object name/description just so you can reset the script without losing all data is advisable. I usually argue against, as object name/description isn't primarily intended for script storage (in fact, LL has recently fixed up some issues with the character limits in these fields and even decreased the limits because they were being abused as persistent storage). I occasionally use object description as a sort of script configuration parameter when it also happens to make sense as an object description. For example, using the description field of a teleporter as a descriptive name for the destination makes sense. But as arbitrary data storage it isn't the best choice in the world in my opinion. Note that users will see that description in the object hover tip and such (for the root prim anyway). Notecards (read-only), data storage scripts, and external databases are the way to go for more permanent data storage IMO, at least for the moment.

Hi all


It seams that hard coding UUID's intead of passing the keys soved the problem.
But still is not a great solution

I guess LSL has serious limitations yet.

Thanks again for your answers

Nope no limitations regarding passing the keys in a list to another object and that object using them.
How exactly were you passing them? Cast list to string (won't work unless there is only one key in the list), llDumpList2String, llList2CSV?

Then you have to load the message back into a list in the reciveing script. Try breaking it down to two simple scripts, The first will only read the inventory, populate the list, convert the list to a string and then pass it. The second will recieve the msg and populate another list with it and then read it out to llOwnerSay, etc.

Post what you come up with and we can help get it working.

also check that the texture is full perm for the new owner or you will get back NULL KEY.

In answer to why use a dynamic list rather than hard coding it, purely because its dynamic! If its hard coded then every time you want to update it you have to edit and recompile. Far simpler to allow the script to work out that you have added new textures and process the list itself.