Running a script through a linkset

[ChinRey]

I'm not sure if this is possible but I'm trying to make a script that starts at the root of a linkset, performs a routine, then jumps to the next part of the linkset, performs the same routine and so on. The problem is that the script is deactivated when it's transferred to another prim. I can't use the regular llRemoteLoadScriptPin()/llSetRemoteScriptAccessPin() solution since the target prims can't be scripted.

Can anybody think of a workaround for this?

[Quistess Alpha]

if your routine is something that can be don in terms of llSetLinkPrimitiveParams(fast), or a "link" function, then you just have to loop through all prims in the linkset:

//integer index_prim = llGetObjectPrimCount(llGetKey()); // does not count sitting avatars.
integer index_prim = llGetNumberOfPrims(); // may count avatars sitting on the object.

// loop backwards:
do
{   llSetLinkPrimitiveParamsFast(index_prim,
    [...]);
}while(--index_prim);

There are very few things left in LSL that must be done by a script in the specific prim which needs to be modified. Sounds were the most glaring example, but link sound functions were added fairly recently.

[Fenix Eldritch]

Some more info/context would be helpful. What does the routine do to each prim in the linkset? Like Quistess says, there are few LSL functions left that don't have linked equivalents... Prim inventory queries and manipulation come to mind as actions that still require a dedicated script in the target prim.

Also, can you elaborate more on the script getting deactivated when transferred to another prim? How are you currently doing it when you observe this, manually dropping it in? Edit: ah, rereading the wiki page for llGiveInventory, I see that scripts intentionally arrive disabled when given to other objects.

Why can't the target prims be scripted despite being in the same linkset?

Edited July 26, 2023 by Fenix Eldritch

[ChinRey]

5 minutes ago, Fenix Eldritch said:

Some more info/context would be helpful. What does the routine do to each prim in the linkset?

It's supposed to create a list of the inventories across the linkset. The idea is to have an easy way to locate that texture that somehow got lost inside a 100+ size linkset - or that no copy notecard that messes up the perms for it. I suppose I'm not the only one who has run across such problems occasionally.

The inventory functions are among those few that still don't have any link equivalents and if I have to set the pin for each prim I might as well add the listing script itself to each or even just check all the inventories manually.

Edited July 26, 2023 by ChinRey

[Fenix Eldritch]

Hmm... I think you could run llGetObjectDetails with OBJECT_TOTAL_INVENTORY_COUNT, targeting each link the hard way (llGetLinkKey) in a loop. That might* tell you if any of the links have something in their inventories. Unfortunately you don't have the granularity to specifically count different inventory types, nor can you get their names. But I suppose it's a way to somewhat narrow things down.

*Not able to get inworld and verify, I'm unsure if that can actually be applied to individual links in this manner.

Edited July 26, 2023 by Fenix Eldritch

[Qie Niangao]

This seems to be a one-off thing, so… couldn't a script in root copy a (self-deleting) inventory-scanning script to every link all at once, where it will arrive deactivated, and then manually select the linkset and use Build / Scripts / Recompile Scripts (and possibly Build / Scripts / Set Scripts To Running) and won't they all run their state_entry in turn as the viewer steps through them? To manage the flood of output they might write it to LinksetData or they could wait for link_message commands from root to do their thing in turn, or…

Maybe I'm missing something.

[Love Zhaoying]

1 minute ago, Qie Niangao said:

couldn't a script in root copy a (self-deleting) inventory-scanning script to every link all at once

Did not know you could do that!  (Copy an inventory object to a specific link via script.)

[ChinRey]

1 hour ago, Love Zhaoying said:

Did not know you could do that!  (Copy an inventory object to a specific link via script.)

That's the easy part. Here's the test script I made:

default{

state_entry(){
    integer ThisLink=llGetLinkNumber();
    integer LinkSetSize=llGetNumberOfPrims();
    if(ThisLink>=LinkSetSize){
        llOwnerSay("That's all Folks!");
    }
    else{
        key NextLink=llGetLinkKey(ThisLink+1);
        llGiveInventory(NextLink,llGetScriptName());
        llRemoveInventory(llGetScriptName());
    }

}
}

This script only creates a copy of itself in the next prim in the linkset (before deleting itself) but it shuld be easy enough to figure out how to make it move other items and to other prims too.

 

1 hour ago, Qie Niangao said:

This seems to be a one-off thing, so… couldn't a script in root copy a (self-deleting) inventory-scanning script to every link all at once, where it will arrive deactivated, and then manually select the linkset and use Build / Scripts / Recompile Scripts (and possibly Build / Scripts / Set Scripts To Running)

Yes, that should actually work. Thanks a lot, Qie!

 

1 hour ago, Qie Niangao said:

To manage the flood of output they might write it to LinksetData or they could wait for link_message commands from root to do their thing in turn, or…

The problem is that the root script would have to perform completely different operations before and after the reset but I think I have a solution to that too: send a test message to link no. 2. If no response, copy script to all parts, if there is a response, trigger the listing routine for one part at a time.

That being said, this is beginning to look a bit too complicated for a script that really only is useful ocne in a blue moon. Maybe it's better to ask LL nicely to implement cross-linkset inventory functions?

[Love Zhaoying]

7 minutes ago, ChinRey said:

1 hour ago, Love Zhaoying said:

Did not know you could do that!  (Copy an inventory object to a specific link via script.)

That's the easy part.

Ahah! Thanks!

[Fenix Eldritch]

4 hours ago, ChinRey said:

Maybe it's better to ask LL nicely to implement cross-linkset inventory functions?

I was thinking about how this could be done... The straightforward approach is to request linked variants of the existing llGetInventory* functions. Buuut... we could also consolidate them into a single new function - which has the added advantage of being extendible in the future.

Function signature:

list llGetLinkInventoryInfo(integer link, list parms);

Input Params:

INVENTORY_ACQUIRE_TIME, string item
INVENTORY_CREATOR, string item
INVENTORY_KEY, string item
INVENTORY_NAME, integer type, integer number
INVENTORY_NUMBER, intger type
INVENTORY_PERM_MASK, string item, integer category
INVENTORY_TYPE, string name
INVENTORY_DESCRIPTION, string name (oh hey, a new suggestion )

I'll draft up a proper feature request when I am at my PC later this evening.

Edit: BUG-234184

Edited July 26, 2023 by Fenix Eldritch

[Fionalein]

Couldn't this be easier solved with a pair of scripts?

a Master script and a Slave script

drop both in root

Master distributes Slave copies

calls them one by one

Slaves do their job then self destruct

Master self destructs after response of last Slave

[Frionil Fang]

8 minutes ago, Fionalein said:

Couldn't this be easier solved with a pair of scripts?

Scripts are disabled when using llGiveInventory. llRemoteLoadScriptPin is for distributing running scripts, but that would require every prim to already have a script in them to set the PIN with llSetRemoteScriptAccessPin to allow the function to work, so it's moot for this purpose.

[Quistess Alpha]

2 hours ago, Frionil Fang said:

llSetRemoteScriptAccessPin

Since I've never used that function intensively, does the pin invalidate when the script calling that function is removed? if not. then as a theoretical impractical solution, maybe all the prims could set the pin with a temporary initialization script?

[ChinRey]

6 hours ago, Quistess Alpha said:

Since I've never used that function intensively, does the pin invalidate when the script calling that function is removed? if not. then as a theoretical impractical solution, maybe all the prims could set the pin with a temporary initialization script?

Pin is a prim property so once set it's permanent. That doesn't help in this case though since it'll have to be set before you can use a script to add a running script to the prim and llSetRemoteScriptAccessPin() is another of the functions that don't work across a linkset.

[Love Zhaoying]

2 hours ago, ChinRey said:

llSetRemoteScriptAccessPin() is another of the functions that don't work across a linkset.

Does this mean llSetRemoteScriptAccessPin() only works for the link the script is in that runs llSetRemoteScriptAccessPin()? The Wiki only mentions "prim" but nothing about "links". 

[ChinRey]

52 minutes ago, Love Zhaoying said:

Does this mean llSetRemoteScriptAccessPin() only works for the link the script is in that runs llSetRemoteScriptAccessPin()? The Wiki only mentions "prim" but nothing about "links". 

Whether the prim (or mesh or sculpt - that's exactly the same in this context) is linked or not doesn't matter. The very concept of linksets doesn't exists as far as lsl functions not specifically made for linksets are concerned. I may be wrong but I don't think the original SL server software was supposed to handle linksets at all, the feature was meant to be purely client side.

The way llSetRemoteScriptAccessPin() is that it assigns a pin, a code to the prim the script is in. This code can be any integer except 0. Once the code is set, it can only be changed by using the function again and it's maintained even in copies of the prim. To disable remote script access you use the function to set the pin to 0.

llRemoteLoadScriptPin() basically works the same way as llGiveInventory() but it has a few extra parameters including a pin integer. If, and only if, the pin matches the one assigned to the recieving prim, the script can be made to run on arrival.

[Love Zhaoying]

43 minutes ago, ChinRey said:

Whether the prim (or mesh or sculpt - that's exactly the same in this context) is linked or not doesn't matter. The very concept of linksets doesn't exists as far as lsl functions not specifically made for linksets are concerned. I may be wrong but I don't think the original SL server software was supposed to handle linksets at all, the feature was meant to be purely client side.

The way llSetRemoteScriptAccessPin() is that it assigns a pin, a code to the prim the script is in. This code can be any integer except 0. Once the code is set, it can only be changed by using the function again and it's maintained even in copies of the prim. To disable remote script access you use the function to set the pin to 0.

llRemoteLoadScriptPin() basically works the same way as llGiveInventory() but it has a few extra parameters including a pin integer. If, and only if, the pin matches the one assigned to the recieving prim, the script can be made to run on arrival.

So..do you mean that llRemoteLoadScriptPin() only runs for the specific, individual "prim" (whether an object comprised of a single prim, or a prim that is part of a linkset) the script is in? And not the entire "object" (linkset)?

Sorry to seem obtuse.

Thanks!

[Frionil Fang]

The only linkset property is linkset data as far as I can think.

Think of it as the difference between calling llSetColor in the root prim vs a child prim: they change the prim color property, so they affect what the script is in, not the whole linkset. The link versions of functions were added to avoid needing to have scripts in every child prim, and no such version exists for remoteload.

[ChinRey]

17 minutes ago, Love Zhaoying said:

So..do you mean that llRemoteLoadScriptPin() only runs for the specific, individual "prim" (whether an object comprised of a single prim, or a prim that is part of a linkset) the script is in? And not the entire "object" (linkset)?

That is correct.

[Love Zhaoying]

9 minutes ago, Frionil Fang said:

The only linkset property is linkset data as far as I can think.

Think of it as the difference between calling llSetColor in the root prim vs a child prim: they change the prim color property, so they affect what the script is in, not the whole linkset. The link versions of functions were added to avoid needing to have scripts in every child prim, and no such version exists for remoteload.

Very interesting! So basically, there's no such things as "links" insofar as prims in a linkset don't know about each other.  

(A given prim knows if it is "LINK_THIS", but that's really a reflective property..)

..and the Linkset itself knows about the relation of each prim to the other.  But the individual prims do not.

Does that sound correct at all?

Edited July 27, 2023 by Love Zhaoying

[ChinRey]

21 minutes ago, Love Zhaoying said:

..and the Linkset itself knows about the relation of each prim to the other.  But the individual prims do not.

Does that sound correct at all?

I haven't actually asked any prims but if they have the local position and rotation and not only the global (not sure if this is the case), they must at least be dimly aware of that Divine Root Prim they are all connected to in mysterious ways.