Talk:LlSetRemoteScriptAccessPin
Revision as of 02:14, 7 October 2024 by Peter Stindberg (talk | contribs) (→The PIN is a characteristic of the primitive, right?)
The PIN is a characteristic of the primitive, right?
I have a few questions —
- The PIN is one of the many properties assigned to the prim where the script runs, is that correct? (like hover text set via llSetText) In other words, you can reset every script you wish inside the prim, or remove them, or give the prim away, restart the current region, whatever, so long as no script changes the PIN again (or sets it to zero), it will remain forever set to the original value?
- Yes, but it is instanced. It will not survive shift-drag, but will survive Take Copy, re-rezzing, transfer, etc. It appears to be the same rules as texture animations or particles as a prim property.
- When making a copy of a prim which had its PIN set (but assume that its inventory is now empty), the PIN persists?
- Taking a copy yes, shift-drag no.
- What if the original creator changes permissions and/or ownership (i.e., sells or transfers the original prim without retaining the right to copy it), will the PIN also persist? Again, I'm not considering the many levels of checks required for LlRemoteLoadScriptPin to actually work, just what happens with the PIN in those edge cases.
- The use-case of this function is updating scripts externally, after transfer to another. While I don't have underlying knowledge of the pin in no-modify situations, I do know because product updaters exist and work, that the pin survives transfer to another.
- When another script does a LlRemoteLoadScriptPin, will it affect scripts in child prims as well, or only those on the root prims?
- Pins are not inherited, a child prim needs its own pin set.
- What happens when two prims, each with their own PIN, are linked together? Will the PIN of the new root prim prevail, while the other prims will get their PINs reset? Or will each prim retain their individual PINs?
- Rearranging link orders has no effect on pins. Each link has its own settable pin. This includes when it becomes unlinked, and when it becomes the link/root of another linkset with different pins.
Well, there are more questions like these, and I have in mind several different scenarios, all of which have the same assumption: that the PIN is really a property of the prim, not something somehow written to the script's "memory" (or state, or whatever).
I suppose that one might be able to save the PIN in the KVP store, these days, and thus provide a way to guarantee that a prim has persistent PIN storage. A script expecting the PIN to be set might be able to check first if the PIN is not zero, but, if it is, attempt to load it from a well-known key/value pair on the KVP store, and set it using LlSetRemoteScriptAccessPin, if needed.
- It may be wiser to just set the pin after getting a handshake, must like a chat channel tends to be, if you fear the pin may have been reset.
— Gwyneth Llewelyn (talk) 23:38, 22 September 2024 (PDT)
- Added responses after testing these myself. I do wish they'd survive shift-drag, but for products I can avoid this by putting a no copy item in my copyable products so they cant shift-drag. -Paz
- Interweaving your answers with Gwyneth's the way you did is considered bad practice in a wiki environment.
- -- Peter Stindberg (talk) 03:14, 7 October 2024 (PDT)