How Do I Temp-Rez Sequential Items From An Object?

[Lenny Stickfigure]

I want to build a simple display base that temp-rezzes an item from its inventory every 60 seconds, replacing the previously rezzed item that disappears.  It should go through the items in order and then repeat.

As an example...  Let's say every 60 seconds I want a mesh or sculpted number to appear over the base.  It starts with the number 1.  In 60 seconds when that number disappears (because it is a temp) then the number 2 appears (is rezzed).  Then 3, 4 and so on, every 60 seconds.  At the end I want it to simply go back to the beginning and rez the first item again.

I've searched for quite a while and the only thing I've seen that comes very close is the behavior of PlantPets.  I've seen that they are simply a series of objects, with each slightly more developed than the previous, to give the impression of the plant growing as it cycles through it's inventory.  Each object is temp-rezzed and the next object is rezzed when the previous one disappears.

P.S.  This is my very first post even though I've been in SL since May 2010!  Please be kind to me if my post is not in the right place or if there is already an answer to my question I hadn't seen.  I'm pushing 50 y/o in RL...   LOL

Edited January 31, 2021 by Lenny Stickfigure

[Rolig Loon]

Simple answer.....

1. Put all objects into the rezzer.

2. Write a script that includes (or creates) a list of those objects, in the order in which they should appear.

3. Build a 60-second timer into the script, designed to use llRezAtRoot to create a different object each time it triggers.  Just be sure that the objects are rezzed as temporary objects, so that they disappear automatically about a minute later.

4. Tell your script that when it has rezzed the final object, it should start all over again.  This will introduce you to the basic behavior of lists in LSL.

Voila!  It's almost as simple as that.  If you paw through the collection of example scripts in the LSL wiki, you should find several that include a basic rezzer (or you can look directly at the wiki's description of the llRezAtRoot function).   Fiddle with them by making little baby step changes to see what happens.  Do the same with scripts that contain a timer, and then glue them together.

It really is almost as simple as that.  Basic rezzers are often the first things that new LSL scripters make.  They are easy and versatile, and satisfying.  If you get stuck after you have given it a good try, come back and show us what you did.

[Lenny Stickfigure]

Thank you so very much Rolig Loon!  I've had a lot of fun looking over full perm scripts and making little changes to see what effect it has.  I've picked up a thing or two doing that; or at least the code doesn't look so foreign to me, and in some cases it almost makes sense!   

I will definitely do as you suggest.  And yeah, I kinda figured the script I'm wanting to write is pretty simple.  I just didn't really know where to begin looking.  You're been a great help!  Thanks!

[Lenny Stickfigure]

Rolig Loon,

I've made some progress!  I created a temp prim and put it in the main prim along with the script below.  Now it rezzes the temp prim every 60 seconds, 1 meter over the main prim:

default
{
    state_entry()
    {
        llSetTimerEvent("60");
    }
    timer()
    {
        llRezObject(llGetInventoryName(INVENTORY_OBJECT,0), llGetPos()+<0,0,1>,ZERO_VECTOR,ZERO_ROTATION,0); 
        llSay(0,"It works!"); 

    }
}

So I got the loop working, the temp prim rezzing and being replaced every 60 seconds.

Now I need to figure out how to get it to go down a list of stored prims, rezzing each one in sequence, then repeat.  I'm a 'little' less intimidated now.  I found a few scripts, but they were set up to randomly rez the stored items.  I need mine to rez them in order.

How may I do that? 

[KT Kingsley]

You need a index that you increment (making sure it doesn't go out of bounds, and resetting to 0 when it does) whenever you rez an object. It should be declared as a global integer variable so that it persists across each timer event. Use the index variable in llGetInventoryName, replacing the constant 0.

Incidentally, llSetTimerEvent ("60") won't work: you need a float value there and not a string literal.

[Lenny Stickfigure]

KT Kingsley, thanks!

I do need some clarification with regard to the use of a float value.  At present, my script rezzes a new temp prim every 60 seconds perfectly.

I just read the following in regard to float value, and it seems to suggest that leaving off the .0 saves bytecode space:

"If a function requires a float as a parameter, and the number is an integer (e.g. 5), you can add the .0 to clearly indicate it's a float, but omitting the .0 is equally valid and actually saves bytecode space in the compiled code."

From:

http://wiki.secondlife.com/wiki/Category:LSL_Float 

I'm doing my best to "do my homework" because that's the only effective way to learn.  I'm determined to learn!

 

 

[Rolig Loon]

Either a float or an integer works in that spot, because an integer is typecast implicitly there.  You might save a byte or two by doing that, but then you probably lose a little efficiency because you're forcing the typecasting.  It's trivial either way but personally, I tend to use a float in that sort of spot.

[KT Kingsley]

I tend to use explicit floats and explicit typecasts, though this is mainly to help keep my own head straight. Where I do have some exceptionally busy code (which is hardly anywhere) I will look for any optimisations I can make.

[Mollymews]

3 hours ago, Lenny Stickfigure said:

I just read the following in regard to float value, and it seems to suggest that leaving off the .0 saves bytecode space:

"If a function requires a float as a parameter, and the number is an integer (e.g. 5), you can add the .0 to clearly indicate it's a float, but omitting the .0 is equally valid and actually saves bytecode space in the compiled code."

From:

http://wiki.secondlife.com/wiki/Category:LSL_Float

a little FYI

sometimes on some small occasion, wiki writers are not right about these kinds of things

is as Rolig says,  the Mono compiler implicitly converts the characters 60 to a double type. Same as it does 60.0. So is no bytecode saving in typing 60 instead of 60.0. The only space saving is in the source code (2 characters less)

and we when use typing shortcuts like this then we have to weigh up whether is good coding readability practice to not enter the value as the expected type in our source code

we can proof these kinds of things by writing little test scripts. For example:

default
{
    state_entry()
    {
        llSetTimerEvent(60.0);
        //llSetTimerEvent(60);
        // both 60 and 60.0 result in LSL Mono bytecode of 3364
        llOwnerSay((string)llGetUsedMemory());
    }

    timer()
    {
        ;
    }
}

 

 

[Lenny Stickfigure]

Alright!  Thank you Rolig Loon, KT Kingsley and Mollymews.

Mollymews, I see your point.  Just because "someone" wrote the wiki entry doesn't always mean it's entirely correct.  In fact,, looking at the bottom of the page it shows it was last edited on November 26, 2015.  That's a pretty big gap between then and now also.

Thank you all.  I will spend a few days studying and working on the code and will report back with (hopefully) a working script, or at least my progress thus far.

[Rolig Loon]

1 hour ago, Lenny Stickfigure said:

Just because "someone" wrote the wiki entry doesn't always mean it's entirely correct. 

It's worth pointing out, in fact, that there is no system manual for LSL provided by Linden Lab.  The wiki is created and maintained by those of us who use LSL, building on our own experience and experiments.  It's a remarkable edifice, detailed and imaginative in many places but with occasional gaps and contradictions in others.  We learn by doing, as scripters do anywhere, and we teach each other and develop examples of good practice by making a lot of mistakes and recovering from them.  Scripters also suggest new functions from time to time, and developers in Linden Lab sometimes make innovations, so LSL evolves and the wiki adjusts to reflect the changes.  This forum is a good place to trade discoveries, moan about our failures, and speculate about unexpected behaviors.

[Mollymews]

a bit of history

in the beginning 2003 there was the "Linden Scripting Language Guide" - authors Aaron Brashears, Andrew Meadows, Cory Ondrejka, Doug Soo and Donald Kjer

used to be accessible as a html document in viewer 1.x browser. As I remember somebody also ported the guide to a PDF and posted it somewhere I can't remember now. I think somebody linked to it years ago on sluniverse. Don't remember exactly

i couldn't find any reference/link to the document on now google

so I looked on my second hard drive which is even more messy squirrel than my SL inventory. And found it in a folder named sl-src-1.132.12 dated 19/01/2007. I couldn't remember at first why I would have a copy of the source code for viewer 1.13x, then after a bit I remembered that was about the date the viewer went open source. So I had a further burrow in my endless zip file folders and found my own viewer mods from back in them days when it seemed like a good idea for me to do

now I am thinking about modding it again just enough to be able to login on Haragyaru avatar. Just so that I can go V1.13 Retrolight is the best SL sky ever !!! and them newbie windlighters need get off my lawn. No that I be able to see any of them meshy people but still !!  😸

[Lenny Stickfigure]

I DID IT!

I spent the past several days studying available full perm scripts and learned how to use a number of functions.  It now works and does precisely what I wanted it to.  It feels so good to have researched, studied and experimented with this rather than just asking for a free lunch ("I don't want to put out any personal effort - I just want someone to hand me a working script").  People like that really grind my gears.

So now, not only do I have a working script, I also UNDERSTAND how and why it does what it does.  So now I can build upon that to make it even more useful.

Ok, 'nuff said about that.  So here's the setup I created:

A prim cube.  Inside the cube are four objects named "Object 1" to "Object 4" and the script I wrote.  The script causes each object to appear over the cube for 10 seconds, then is replaced by the next object, and so on.  At the end, it simply restarts with the first object again.

Script:

vector pos = <0,0,1>; // where to rez inventory item in-world
vector rot = <0,0,0>; // if the rezzed object needs to be rotated
float te = 10.0;      // the time in seconds before the next object is rezzed
integer no = 0;
integer co = 0;
string obj = "";
default
{
    on_rez(integer start_param)
    {
        llResetScript();
    }
    state_entry()
    {
        no = llGetInventoryNumber(INVENTORY_OBJECT);
        obj = llGetInventoryName(INVENTORY_OBJECT,co);
        llShout(6672,(string)llGetOwner()+","+"Delete");
        llRezAtRoot(obj,llGetPos()+pos,<0,0,0>,llEuler2Rot(rot*DEG_TO_RAD),42);
        state sequence;
    }
}
state sequence
{
    state_entry()
    {
        llSetTimerEvent(te);
    }        
    timer()
    {
        co = co + 1;
        obj = llGetInventoryName(INVENTORY_OBJECT,co);
        llShout(6672,(string)llGetOwner()+","+"Delete");
        llRezAtRoot(obj,llGetPos()+pos,<0,0,0>,llEuler2Rot(rot*DEG_TO_RAD),42);
        if ( co == (no-1))
        {
            llSleep(te);
            llResetScript();
        }
    }
}

[Lenny Stickfigure]

Now, I need to figure out how to edit the original title of this thread so it says "Solved" at the end - anyone know how I can do that?

[Rolig Loon]

Congratulations.  Isn't that a great feeling?  That's what scripting does for me too.  I am faced with a puzzle and I need to find ways to express it in code.  The challenge is not so much about writing the mechanics of the puzzle as it is about understanding how it all works, finding optimal paths through it. I get a great rush when I have coded some truly complicated logical structure and it actually does what I have been seeing in my mind.  The odd thing for me is that within a week of finishing a great script, I almost lose interest in it.  The adrenaline rush was all about finally seeing the script alive and understanding how it ticks; once that's done, I revel in the accomplishment but I'm ready to move on.

21 minutes ago, Lenny Stickfigure said:

Now, I need to figure out how to edit the original title of this thread so it says "Solved" at the end - anyone know how I can do that?

Nope.  You can edit a post for the first 24 hours or so after you have created it, but it's frozen after that.  What's important in this case is that you know you solved the challenge and you're aching to get into the next one.  It won't mean anywhere near as much for anyone else.

[Lenny Stickfigure]

11 hours ago, Rolig Loon said:

The odd thing for me is that within a week of finishing a great script, I almost lose interest in it.  The adrenaline rush was all about finally seeing the script alive and understanding how it ticks; once that's done, I revel in the accomplishment but I'm ready to move on.

A not-so-bad addiction.