Firing off code in temp rezzes when rezzed...

Hello All,

Long time SL user and forums reader, 1st time poster. I am an intermediate scripter, and have created my 1st problem that I cannot get my head around.

I have this code that fires off whenever 'str' changes from '1' to '0':

default
{
    state_entry()
    {
        llListen(chnl,"","","");
    }
    listen(integer a, string n, key id, string str)
    {       
        if(str=="0")
        {
              //code      
        }
        if(str=="1")
        {       
              //code
        {
    }
}

I have a temp rezzing system that utilizes this code as well. The rezzers that rez the temp rezzes are part of a linkset; I would like the temp rezzes to fire off this code whenever they are rezzed, but the temp rezzes are saved with the condition of 'str = 0', so when they are rezzed, the code does not fire until '0' is manually changed to '1' - which is my core problem.

I understand why this happening, my question is: 'How can I grab the current state of 'str' in the root prim and if 'str == 1', fire off the code in the temp rezzes when intially rezzed?'

(*hope that makes sense, if not, I can try to clarify)

I have been looking into link messages, as well as on_rez to solve this problem, and will be working on it until I find a solution, but in haste, I thought I would post it here to see if any of you had any ideas on how to accomplish this.

Thanks for reading, have a gud one,
~Chipley

Not sure I understand what you're asking but llRezObject lets you pass an integer to the on_rez event of the object being rezzed..

It sounds like you want to use the on_rez event and its parameter. So, the rezzer does something like:

llRezObject("temp prim", position, velocity, rotation, state);

where state is either 0 or 1 - it must be an integer - and the temp prim has

on_rez(integer p)
{
if (p) {
// code for 1
}
else {
// code for 0
}
}

Assuming you're using llRezObject (it's by no means clear from the code snippet you've posted) you can use its 'integer param' argument to communicate to the on_rez Event handler's 'integer start_param' argument of the object being rezzed.

llRezObject("Object Name", llGetPos() + <0, 0, 2>, ZERO_VECTOR, ZERO_ROTATION, 1);

:
:

on_rez(integer start_param)
{
if (start_param == 1)...

Hey you two,

Thanks for the replies and sorry for lame, vague code. I looked into using the integer start_param in llRezObject after both your mentions of it. That variable is already being used by my temp rezzer, but it was quite an interesting read, so thank ya for pointing me in the right direction.

I have implemented a timer instead which seems to solve my problem for now until I can find a better way to finish it:

integer myState;
float gap = 2.0;
float counter = 0.0;
default
{
    state_entry()
    {
        llListen(5,"","","");
        llSetTimerEvent(gap);
    }
    listen(integer a, string n, key id, string m)
    {   
        if(m=="0")
        {
            myState = 0;    
            llSetTimerEvent(0);              
        }
        if(m=="1")
        {
            myState = 1;         
            llSetTimerEvent(gap);             
        }
    }
       timer()
    {
        counter = counter + gap; 
        llSay(5, (string)myState);
    }
}

Thanks for your input, that looks like the right way to do it, I'll use that knowledge next time.

Cheers,
~Chipley

What kind of value are you passing to llRezObject?

If it's just a relatively small number, you could pack more data into it and send both values in one variable. This would be a lot more efficient & reliable than using chat.

You can also change it to pass a large negative random chat channel on which to pass any desired information in a subsequent command (including whatever information is currently being sent in the parameter). That way you can pretty well trust the message and depend more on it being delivered. You might want to wait until at least the object_rez event before sending chats to the rezzed object on the agreed channel though. A small delay after object_rez might even be wise, and/or some kind of acknowledge protocol.