fun with dynamic permission storage

The History:
~2.5 years back you could not pass a script of the same name to another prim via llGiveInventory... it would silently fail... in fact it silently failed for pretty much any identically named item...

The Present:
fast forward to sometime since then, and you now can, and the duplicate script gains a number after it identically to the behavior of dragging a duplicate script from inventory to a prim... no big deal you say; those scripts won't be running so what's the use....

The Trick:
you CAN take one of these newly numbered scripts and send it back, active, if you use remote load script pin.... which will replace a script of the same name... but since it's been newly numbered, it has a different name. if said script is used to store avatar permissions, like PERMISSION_TRIGGER_ANIMATION, you can now dynamically add those permission scripts without running out of room, running a bunch of idle scripts, preloading a ton of non-running copies, or usinging complicated systems to switch said preloads on and off, all while avoiding repetitive permissions dialogs on things like dance balls and huggers...

The Example:
two prim object, 3 scripts, A, B, C
Scripts B and C go in the root.
Script A goes in the child, along with a non running copy of B
(go ahead and name them this for the example to work

Script A

default{
    changed( integer vBitChg ){
        if (CHANGED_INVENTORY & vBitChg){
            llRemoteLoadScriptPin( llGetLinkKey( 1 ),
                                   llGetInventoryName( INVENTORY_SCRIPT, llGetInventoryNumber( INVENTORY_SCRIPT ) - 1 ),
                                   42,
                                   1,
                                   42 );
        }
    }
}

Script B

key gKeyAva;
string gStrCmd;

default{
    link_message( integer vIntLnk, integer vIntNum, string vStrCmd, key vKeyAva ){
        if (vIntNum){
            llGiveInventory( llGetLinkKey( 2 ), "v7-D Permission" );
            gKeyAva = vKeyAva;
            gStrCmd = vStrCmd;
            state sAvatarStored;
        }
    }
}

state sAvatarStored{
    state_entry(){
        llRequestPermissions( gKeyAva, PERMISSION_TRIGGER_ANIMATION );
    }
    
    run_time_permissions( integer vBitPrm ){
        if (PERMISSION_TRIGGER_ANIMATION & vBitPrm){
            llStartAnimation( gStrCmd );
            llSetTimerEvent( 3600.0 );
        }else{
            llRemoveInventory( llGetScriptName() );
        }
    }
    
    link_message( integer vIntLnk, integer vIntNum, string vStrCmd, key vKeyAva ){
        if (gKeyAva == vKeyAva){
            llSetTimerEvent( 3600.0 );
            if ("STOP" == vStrCmd){
                llStopAnimation( gStrCmd );
            }else{
                llStartAnimation( (gStrCmd = vStrCmd) );
            }
        }
    }
    
    timer(){
        llStopAnimation( gStrCmd );
        llRemoveInventory( llGetScriptName() );
    }
}

Script C

list gLstKwn;

default{
    state_entry(){
        llSetRemoteScriptAccessPin( 42 );
    }
    
    touch_start( integer total_number ){
        key vKeyAv = llDetectedKey( 0 );
        integer vBooNew = !~llListFindList( gLstKwn, (list)vKeyAv );
        if (vBooNew){
            gLstKwn += (list)vKeyAv;
        }
        llMessageLinked( LINK_THIS, vBooNew, "dance1", vKeyAv );
    }
}

I've already included the start of some safety protocols in there, timeouts and permission checks to remove denied or stale permissions (needs code to update the controller) the start of reset protection (perms script needs to check start parameter), but this should give you the general idea...

now someone tap Very Keynes and tell him his database script(s) can now dynamically load memory cell scripts

Interesting...

A few general observations:

1) The 3 second delay with llRemoteLoadScriptPin() might prove problematic for some uses, like a dance machine. Several people requesting dances in a relatively short time period might introduce long wait times for dancing to start for some of them.
2) Similarly, llGiveInventory() and llRemoteLoadScriptPin() may be problematic when the asset server is not operating optimally, so dynamic on-demand functionality might be a bit dicey.
3) The child prim helper script needs some housecleaning, otherwise non-working copies of the Slave scripts in it will pile up forever. In addition, I'd have to research it to be sure, but don't non-running scripts still consume resources (memory)? There will ostensibly be double the number of Slave scripts in the linkset while operating -- half running, half not running.

Ones related to your example application:

1) Probably should stop a previously-running animation before starting another, especially for a dance machine, where the animations are generally looped.
2) Should reset the timer every time an animation is stopped/started, I would think; otherwise, it will always quit after an hour.

------------

All that said, I can see a good use for it in my work -- mainly eliminating the need for the user to manually add multiple copies of a script to effect things like storage tables during a configuration process.

I'm thinking of addressing that with more than one ready copy, or a couple of loading scripts... haven't parsed it out completely yet.


it may not be an issue since IIRC the sim caches the objects loaded on it there's a possibility that they'll be ok on the sim but only show issues when they are moved off sim or to inventory... I'll have to play with that a bit more although having multiple ready scripts might solve some of that if it's an issue.


oh it definitely needs housecleaning, but since give inventory doesn't load a script to the VM at all the memory issue shouldn't come up, even if non-running scripts do take memory normally (I'm not sure 1 way or another). I suppose I'll test that in an empty sim later. I'm looking at giving the active scripts that die a death rattle that alerts the loader(script A) to remove its doppleganger from the loading pool... but then I'm going to have to track script numbers.... eh it's on the todo list =)

the above was just a quick proof of concept draft... I'm working on a more robust version as we speak


good point on the stop then start, but if you look, each new link command does get a timer reset although for consistency I should always fire that first


glad it helps... I was very sad to shelve the idea back then, so it's quite a fun little distraction now =)