llRemoteLoadScriptPin documentation...

Who can tell me something about llRemoteLoadScriptPin and llSetRemoteScriptAccessPin.

I found only sintax, no exemples.

TY

So I would love to know how this works too, even the other wiki which usually has nice examples or explanations or says how something works has no info on it, and it doesn't come up searching the forums either to try to figure out how it works from examples there!

Maybe nobody actually knows how it works? LOL

you're overcomplicating the usage, but perhaps this will help

llSetRemoteScriptAccessPin( some-number-to-be-a-password-to-add-scripts )
treat it like the guy that checks ID's at the bar.... ID must = password

llRemoteLoadScriptPin( target-prim-uuid, script2give, password, run-the-script-when-it-gets-there, optional-number-to-feed-the-script-if-you-run-it )
treat it like give inventory, except it only gives to other objects, it only gives scripts, and it can set them to run, unlike give inventory, and it has a place to put the password to allow it all.

Oooo, ty Void!

So I think I get it...

In my "product" goes: llSetRemoteScriptAccessPin(1234) in state entry

In my updater have a sensor with llRemoteLoadScriptPin(llDetectedKey(0),"scriptname",1234,TRUE,0)

So the next question would be how to handle different products since mod ones could be renamed to anything? I guess have a dialog if the script can't recognize the name, so users could manually choose? And a different 1234 for each product?

The name doesn't really matter -- except for detecting the uuid of the prim to receive the scripts, of course -- unless you're trying to replace a script inside the prim (in which case you just make that script non-mod). The "name" argument in llRemoteLoadScriptPin is there so the updater prim knows what to script to send to the target.

If you're worried about people renaming the object -- so the updater can't find the object to update -- what I normally do is have a dialogue option on the target prim's menu to ask to be updated.

The owner rezzes the object and the updater near each other and clicks "update" on a menu offered by the target object. This makes the target say "update me!" on channel -12345. The updater is listening for messages on this channel, grabs the uuid when it receives one, and uses that to fill in the target prim's uuid in llRemoteLoadScriptPin.

You don't really need different access codes, though it can't hurt. What the access code is checking, though, is the new script is coming from a recognised source, not that it's going to the right place.

It's a bit like the 4-digit PIN number on my cash card; my bank's certainly got more than 9999 customers, so presumably I share a PIN number with lots of other people. That doesn't matter -- what's important is that I'm the only person who knows that my particular PIN number is needed to access a particular account.

Folks may find that Dari Caldwell's scripts, collectively called "Localized Update System utilizing llRemoteLoadScriptPin (Object Update System)" at /15/8e/172797/1.html are of considerable assistance here.

just one caveat... both objects must be owned by the same person, so you have to give your updater to the customer before it'll work.

some method of communication and checking will probably help, the product can advertize it wants an up.date, and the updater can check the creator, perhaps autheticate a code (methods vary, there are authentication methods on the forum) and in fact the object doesn't have to set a password/pin untill it's ready to be updated

*stupid 403 error on the word update followed by a comma