Talk:LlSetRemoteScriptAccessPin

The PIN is a characteristic of the primitive, right?

I have a few questions —

1. 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?
2. When making a copy of a prim which had its PIN set (but assume that its inventory is now empty), the PIN persists?
3. 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.
4. When another script does a LlRemoteLoadScriptPin, will it affect scripts in child prims as well, or only those on the root prims?
5. 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?

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.

— Gwyneth Llewelyn (talk) 23:38, 22 September 2024 (PDT)