How to delete many prims without using many listens?

[Frankie Rockett]

Hi!
I have an application working at the moment that I'd like to rewrite in a much more friendly way and I wonder if you guys and girls can help?
I have a game that rezs many prims. It's up to the player but there might be a hundred or more. The region's the limit, theoretically. When the game is over, all the prims (which are all very close by and very close together) need deleting. Currently they all have a 'listen' in them, listening on a particular channel for the 'Clear' command, whereupon they 'die'. I would love to not be creating scores or even hundreds of listens! So I am wondering how else to do it?

I was musing that perhaps there is a way to link two or more prims that are and remain separate from the prim that created them? Is that do-able? So to be clear, prim A contains the script and the means of spawning prim B, C, D and so on. Prim A creates B initially, but B is unique as the first one spawned, it's set to contain the only 'listen' needed. As each new prim is spawned, it links to prim B (or any of the others except A).  When the game is over, a 'clear' command causes prim B to delete, taking everything attached to it with it. Ok, that's my uninformed guess! Might that work? What are the key functions that I might need to get it going?

And of course, are there any other exotic techniques I might employ to achieve the same functionality?

Thank you for your thoughts!

Edited December 6, 2019 by Frankie Rockett
Increased clarity - I hope.

[Fenix Eldritch]

As you have surmised, each separate object would need its own listen in order to react to chat commands. You could indeed cut down on the number of listens (and even scripts) by linking more parts together and having the linkset use one central script. (This is in fact highly encouraged as fewer scripts in general puts less load on the servers)

llCreateLink can be used to programmatically link one object to another, and specify which one will be the root in the resulting linkset. In your example, prim B would have in its script the routine for issuing the llCreateLink function, with the target UUIDs of prims C, D, etc being supplied to it by prim A (A would automatically know their UUIDs since it's rezzing them in the first place).

All prims to be linked would need to have the same owner, reside on the same region, be within link distance, and be modifiable (trivial if you are the creator). Additionally the script in Prim B would need to request PERMISSION_CHANGE_LINKS before it could do anything. This last part may be problematic... I'm unsure if the script of prim B instances would be reset when rezzed from A's inventory - if so, they would lose any saved permissions and need to re-request, which would make the whole thing not work unless you are around to satisfy that request.

Another approach you may want to consider is to build your game pieces already linked, with a surplus of linked parts to accommodate future players/capacity. Keep them dormant/invisible and only reveal them as needed. This would avoid needing to rez/link parts at the cost of permanent LI consumption.

Edited December 6, 2019 by Fenix Eldritch
typos, & additional clarification

[Profaitchikenz Haiku]

An alternate approach might be to rezz not a prim at a time, but a ready-linked set of prims, all of which bar one are set to transparent and a tiny size. A counter is initialised to 2. Each time a new prim is required, the root prim resizes the child prim and turns off transparency for the linkset member indicated by the counter, and increments the counter. When the counter reaches the maximum, another link set must be rezzed and it takes over. Each link set root listens for the clear command and implements the die accordingly. Using this method at least reduces the number of running scripts.

I'm not sure how you would go about staggering the positions of the child prims but that will be dictated by the game, I expect.

Fenix beat me to it by a second

Edited December 6, 2019 by Profaitchikenz Haiku

[Rolig Loon]

If they are all on land that you own, try llReturnObjectsByID.   Just maintain a list of the rezzed object UUIDs (provided in an object_rez event as the object is created), and then walk through the list, returning one after another until they are all gone.

[Frankie Rockett]

Hi Fenix, and Hi Profaitchikenz too.
(I greeted you a second later Profaitchikenz, just to keep it straight!)

Thank you both for your suggestions. Fenix, one question. You say the rezing prim (my prim A) would " automatically know" the UUID of the prims it's rezzing. How? Or more exactly, how would I access that value please? I love your suggestion overall, except for the ugly caveat concerning PERMISSION_CHANGE_LINKS. So I have an idea/question about how to get around that. Supposing my 'prim B' were a permanent, invisible part of the game, and once the game is ready for others, I give it the permission once that it wants. Then later, with lots of child prims attached, and hearing my 'Clear' command, could it contain a script that effectively says 'delete all child prims'? - excepting itself. Then, on future runs of the game, could it be told to link to a new series of prims as they are rezzed, by their UUID's, without needing PERMISSION_CHANGE_LINKS  again? Or is that permission required on a prim by prim basis?

Thank you for your idea Profaitchikenz but I see problems with it, like waiting an age for some potential maximum number of prims to rez and link, even if the subsequent player only used a fraction of what was invisibly prepared.

Cheers!

Edited December 6, 2019 by Frankie Rockett
Typo

[Frankie Rockett]

Hi Rolig!
Thank you for your idea. The game won't always be on my land, which as you understand would scuttle that approach. If it was on my land, wouldn't the memory requirements be beyond an lsl script? Saving a little 'array' of - let's say worst case - 250 UUID's?

Cheers

[Mollymews]

7 minutes ago, Rolig Loon said:

If they are all on land that you own, try llReturnObjectsByID.   Just maintain a list of the rezzed object UUIDs (provided in an object_rez event as the object is created), and then walk through the list, returning one after another until they are all gone.

thinking about the two different approaches, I would go with what Rolig has suggested here

It would be the simplest way to modify your app with the least amount of change to how the app works now

altho as you Frankie, have mentioned it will only work on parcels where the script does have return objects capability

Edited December 6, 2019 by Mollymews

[Rolig Loon]

Just now, Frankie Rockett said:

If it was on my land, wouldn't the memory requirements be beyond an lsl script? Saving a little 'array' of - let's say worst case - 250 UUID's?

Nah.  That's a piece of cake. 

Presumably, you at least have rez rights where these things are being created. That's really all that counts, and it's actually best if you do not own the land yourself, but a group or some other person (your alt?) does. You then get the land owner or group to approve PERMISSION_RETURN_OBJECTS, and your script will work.  Here's the detailed description:

If the script is owned by an estate owner or manager, this function works for objects located on any parcel in the region. Otherwise, the script can return objects located over land owned by the owner of the script.

As a security measure, parcel owner, estate owner, and estate managers can not have their objects returned by this method, except when the object returns itself.

[Frankie Rockett]

Hi Rolig + Hi Mollymews!
Thank you for those remarks. I think I want to try Rolig's idea, especially as Mollymews points out, it involves least modification to what I have now. Although I do need to speak to the land owner. Can I take it then Rolig that he or she could create a parcel for me, and not fear that my PERMISSION_RETURN_OBJECTS could affect anything he owns outside 'my' parcel? And just for completeness, how (in what menu/dialogue) would he grant me such a permission?

Cheers.

[Fenix Eldritch]

37 minutes ago, Frankie Rockett said:

You cay the rezing prim (my prim A) would " automatically know" the UUID of the prims it's rezzing. How? Or more exactly, how would I access that value please?

When a script rezzes an object from its own inventory, it queues up an object_rez event. In that event (assuming you include it in your script) you can access the UUID for the object that was just rezzed.

37 minutes ago, Frankie Rockett said:

Supposing my 'prim B' were a permanent, invisible part of the game, and once the game is ready for others, I give it the permission once that it wants. Then later, with lots of child prims attached, and hearing my 'Clear' command, could it contain a script that effectively says 'delete all child prims'? - excepting itself. Then, on future runs of the game, could it be told to link to a new series of prims as they are rezzed, by their UUID's, without needing PERMISSION_CHANGE_LINKS  again? Or is that permission required on a prim by prim basis?

I'm a little fuzzy on what conditions might cause a rezzed object's script to get reset (region restarts?) but generally speaking, yes, if left out and alone, prim B should retain its permissions.

As for removing the child prims when no longer needed, that is a little more involved. The only function to actually delete objects is llDie but that targets the object containing the script. So you would need to unlink the child prims with llBreakAllLinks and then return them by way of something like Rolig suggested. Just be aware that your lost and found folder it going to get a lot of traffic from this.

 

Edited December 6, 2019 by Fenix Eldritch
referenced wrong function

[Fenix Eldritch]

It occurs to me that there may be another approach... though it's a bit cumbersome - and I'm not entirely sure if it will work in the first place.

What if you set your linkset to have the temporary status, unlink everything and then remove the temporary status on the remaining prim B? If (and that's a big if) the freshly orphaned child prims retain that temporary status, they will delete themselves automatically after a few seconds (in theory)

Edit: Jumped inworld and tried a proof of concept. And it works!

//Demo script to delete all child prims, but leave the root intact.
//Script will set temp_on_rez status, break all links, then remove the temp status on the root
//The result will be the orphaned child prims keep the temp status and self delete after a short time.

default
{
    state_entry()
    {
        llRequestPermissions( llGetOwner(), PERMISSION_CHANGE_LINKS );
    }
    
    run_time_permissions( integer perms )
    {
        if (PERMISSION_CHANGE_LINKS & perms)
        {
            llOwnerSay("permission granted");
        }
        
    }

    touch_start(integer total_number)
    {
        llSetPrimitiveParams([PRIM_TEMP_ON_REZ,TRUE]);
        llBreakAllLinks();
        llSetPrimitiveParams([PRIM_TEMP_ON_REZ,FALSE]);
        llOwnerSay("all child prims set to temporary and unlinked.");
    }
}

 

Edited December 6, 2019 by Fenix Eldritch

[Rolig Loon]

Can I take it then Rolig that he or she could create a parcel for me, and not fear that my PERMISSION_RETURN_OBJECTS could affect anything he owns outside 'my' parcel? And just for completeness, how (in what menu/dialogue) would he grant me such a permission?

That is granted by request in your script. Issue a llRequestPermissions(llGetOwner(), PERMISSION_RETURN_OBJECTS).  In your run_time_permissions event, you check to be sure that permission has been granted.  Then, if it has, set a global flag (something like iReturnOK ).  If the flag is set, then use it to allow the touch_start event to trigger the return of all objects'

touch_start (integer num)
{
    if (llDetectedKey(0) == llGetOwner() )
    {
        if (iReturnOK )
        {
            // do all your returning stuff here 
        }
    }
}

  If you own the parcel, then, as I copied the description above:

the script can return objects located over land owned by the owner of the script

 

Edited December 6, 2019 by Rolig Loon

[Frankie Rockett]

Hi all

So much for me to digest! I used to code daily but 'use it or loose it' applies here, and as I haven't got down and dirty for literally years, absorbing some of your fine ideas is a little overwhelming. Fenix and Rolig have (with a great supporting cast), between them I think, given me a workable alternative to a 'choir of listens'! Please let me play around with your combined suggestions over the next week or so to see where they lead.

Thank you again so much for donating your brilliances! Much appreciated!!

Frankie.

[Lucia Nightfire]

Just some things I'd figure I'd mention about scripted prim return and sorry if it gets too technical or if I create an information overload scenario, heh.

If prim return is used, be mindful there is a object count limit per hour equal to the parcel sim-wide max prim count.

This limit is returned objects as in linksets, NOT prim count.

So if your land owner carves out a small parcel that allows 256 prims but changes it to a new owner or new land owned group, it won't be using the same "pool" had the land owner remained the same as the land it was carved from, so you will only be able to return 256 objects in an hour's time.

You will want to keep track of return counts regardless.

If you exceed your return allowance, you will never be able to return objects again until the sim is restarted. See https://jira.secondlife.com/browse/BUG-11770

If a prim return fails, it still counts toward the limit.

Whenever you have a failed prim return, prims go into "limbo" where they are not seen on the prim owner's list for two minutes whether they are selected or not.

After two minutes , if the prims are selected they will show on the prim owner's list again. If they never get selected again, they remain off the prim owner's list.

See https://jira.secondlife.com/browse/SVC-7788

This is to prevent autoreturn from repeatedly trying to return prims during times the asset server may be having issues or maintenance.

If you are going to be the owner of the objects used and they are full-perms for you, you can set the next owner permissions of the objects that will be rezzed to yes-copy and no-trans.

Then put these objects in a rezzer and deed it to the land group. Whenever deeded no-transfer prims get returned, they die instead of filling up the last owner's lost and found.

Now for other concerns.

Recently LL made a change that causes object_rez() to not always trigger. I can only hope this gets fixed soon.

As a safety precaution, you might want to have your rezzer set its operation mode in its desc, ie, "1" for on, "0" for off and have rezzed objects check llGetObjectDetails() and OBJECT_REZZER_KEY so they know what rezzed it followed by them periodically checking the rezzer's desc to know it operation was turned off or if the rezzer even exists anymore.

This can help with failed object_rez() triggering and with cleanup if the rezzer is removed/returned or if scripts in either rezzer or rezzed object have been reset.

Lastly I'll plug features that would have helped with this application had they been implemented:

Scripted remote object delete: https://jira.secondlife.com/browse/BUG-8383

Mod Keys(w/ new create/break link functions): https://jira.secondlife.com/browse/BUG-41363

Edited December 7, 2019 by Lucia Nightfire

[Qie Niangao]

Do we have reason to believe there's still substantial overhead to an active, tightly filtered listen()? There was some recent effort invested in making that more efficient.

Of course there's load in having a huge number of scripts running in a region even if they have no active event handlers at all, never mind listen()s. A couple hundred is no big deal, but if we're really talking about the sim limit -- 25,000, say -- those objects definitely can't all be scripted. (And llReturnObjectsByID() also can't scale that far for the throttling reasons Lucia mentions, and the associated Lost+Found inventory traffic and clutter.)

It may be easier for the game to limit its own scale. Each player gets only a hundred rezzed objects, say, then it's over.

Speaking of scale, what about geometry? Will all these rezzed objects be within linkset distance limits? If so, I do favor Fenix's idea of them linking themselves together with llCreateLink(). That would really rein-in the number of simultaneously active scripts: the game pieces will all poof at once, so only need to retain one script in the entire linkset. I'm imagining that the first-rezzed game piece is the only one with a script, which listens to its rezzer for the UUID of each subsequently rezzed game piece, links to it, and later when it gets the game-over command, llDie()s to wipe the board.

[ETA: If using the dynamic linkset thing, may want to set PRIM_SCRIPTED_SIT_ONLY in the game pieces before they're rezzed, to prevent players from sitting on the game pieces and preventing them linking. And if the game actually includes avatars seated on the game pieces, that'll be a complication.]

Edited December 7, 2019 by Qie Niangao

[Nova Convair]

I made some load tests a while ago. 250 listens are nothing and if they are only active when someone is using/playing - the alternatives don't convince me enough to avoid the listens.

2500 listens are still nothing - when just listening. (Don't dare to use up that sim resource 24/7 though 😎 ) When sending 1000 messages as a brodcast to trigger all the listens at the same time (thats 2.5 million events - yes) you will notice a shattering of the force - err - the sim of course - only script-wise - but if you don't pay attention you will barely notice it. Depends on sim type and how much it is already under load of course.

Self delete of 50 objects has no noticeable effect so I assume 250 makes no difference, 2500 maybe, but that takes only a second or two.
I wonder how much load 250 returns will cause.

[Mollymews]

On 12/7/2019 at 9:52 AM, Fenix Eldritch said:

tried a proof of concept

i like this.  Could create some pretty cool effects with this. For a least cost

like, turning the linkset physical. Fire it up in the sky, start particle and sound effects, and then unlink. Prim fall.  Prims raining down all over place, bouncing around when they hit/land on anything. and then they die

[Frankie Rockett]

Wow Lucia!
Yes, danger of information overload, yet I understood 87.396% of it. More than enough to see what an important set of considerations I'd never have dreamed off were it not for your input. I can imagine myself scratching my head for days and wasting hour upon hour trying to figure out why no more object returns were happening. And I've barely touched on half your contribution here, but it's all noted (and in need of sixteen re-readings to be sure I got the rest). Thank you so much.

Qie - again, thank you for your input. Yes, I am leaning towards Fenix's approach like the Tower of Piza is leaning towards agreeing with gravity. Not only to circumvent the issues Lucia points to but also the general messiness of having my Inv fill up with what is conceptually at least, other people's junk. I still need to do a ton of experiments around circumventing the PERMISSION_CHANGE_LINKS complication, but it feels like the avenue I should explore ahead of the llReturnObjectsByID approach. Nice to have a plan B though, so thanks again Rolig. Oh, and a plan C too if you're on the right lines saying that a targeted listen is no biggie, together with a built in limit to how many prims I'll permit to be rezzed in one go. I kind of think 200 would be the limit though for game-specific reasons.

I'll keep this thread posted with findings as I go along.

Cheers.

[Frankie Rockett]

Epilogue.

The solution worked flawlessly. Fenix's proof of concept script does the job really well. The only tweak I had to make was as a result of idiot-proof testing. I found that if I clicked like mad creating scores of prims per second then hit 'clear' while things were still rezzing and linking, then - after a looong delay for things to catch up, two or three child prims were left over - still attached, and not temporary. So I wrote a little delay loop (because llSleep makes everything go brain dead so nothing gets done) before and after the unlinking call and that seemed to make it bullet proof / vandal proof. Success!

Thanks to everyone again - you know who you are - for your superb insights!

Cheers.