on-rez()

I have one object that rezes another. I want to pass the rezed object a variable, however on_rez() doesn't seem to activate unless the object is rezed from my inventory.

Has anyone managed to get an on_rez to activate when the object is rezed from the inventory of another object ?

Note : according to the LSL manual this should be possible - since the manual states on_rez(integer start_param) - that the start_param is to accept data from the RezObject.

I did manage to get the map working by having each of the map dots as a seperate object. Currently anything over 10 objects tracked return an error due to the object not being in the inventory. I would like to have only one object and pass the sensor index number to the map dot.

Thanks Xavier

Xavier, short answer is "yes". See me in-world for an example if you don't get it worked out.

Or I can post here if there is sufficent interest.

Yes plz post here, I am also working on something needing this....

Interesting because I did this last night with no hassles at all. My script passes on rez a channel number. Here is the call I use and it does work.

llRezObject("Digit",myPosition+<(-.5)*i,0,0>,<0,0,0>,<0,0,0,0>,channel+i);

The only hitch I had was making sure capitalization was correct - trying to rez "digit" didn't work. The i is because it is in a for loop.

-- This is basically what I had.
-- Pulling the slave from my inventory would trigger the on_res
-- This script would never enter on_res when used with RezObject

// Master Object - Slave in Inventory

default
{

state_entry()
{
llRezObject("Slave", <0,0,0>, <0,0,0>, <0,0,0,o>, 5);
}


}

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

// Slave Object

integer test;

default
{

on_rez(integer start_param)
{
test = start_param;
llWhisper(0, "In on_res()";
}

state_entry()
{

}


}

With the exception of the typo in the rotation parameter it looks like it should work.

That line of code I posted is an exact cut and paste of the code I am using that does work, the parameter does get passed and on_rez gets called.

JohnG Linden worked on this last night and we came to the conclusion - thes script did not like the color of the sphere it was on. Once the same script was copied to a red sphere instead of the yellow sphere - it functioned properly.

Actually here is the way I understand what happened. There is a object - state memory -. I must have created the sphere and saved it to my inventory with a script that didn't have a on_res()
call initially in it. The default - state memory - of that object then said I have no on_res() so I won't bother looking for it ever again - no matter how much hair Xavier looses.

So to fix this the script had to be placed on a new object and re-aquired.


Xavier

Does anyone else think it's really funny that JohnG Linden helped fix a script with weird memory problems? Or am I just too much of a film nerd?

so there is a problem with yellow eh?.... that would explain it.

*grumble grumbel*

BBC we can only assume that sice red works and its <255.0.0>.
However yellow does not <255.255.0>, we can logically conlcude.

1. The problem is from green.

2. Since we all know martians are green and of course mars is the 3rd planet.

3. We know that witches always come in groups of 3.

4. We know know that witches are made of wood - note the object was made of wood. ( AHA PROOF )

I would say the theory is now fact.

Xavier

There is a small problem with your otherwise perfect theory (unless you don't believe in Mercury, and there's some good evidence for that position).

Xavier (and anyone else with this problem):

The problem is generic, and has to do with the fact that when objects are saved, they are saved with some of the internal state. (I'd have to have a long chat with one of the server-side people to find out exactly what is happening here.)

Thus, when you rez an object, you are not necessarily getting a fresh, clean one straight from the laundry

The normal way to fix this is to put the following line of code in every state (a trick which I believe Philip Linden originally posted):

on_rez(integer arg) { llResetScript(); }

This completely resets the object every time it is rezzed, and will get rid of any lingering state problems.

The only time you can't use this code is when you actually need the argument you get from on_rez(integer arg) -- because llResetScript() resets memory of everything, including anything you did based on the argument!

The workaround is to copy the script text and paste it into something on your PC desktop, like Notepad. Then delete the script from the object's inventory, save the object, rez another one, hit "New Script..." and paste the script text from your desktop back into the new script.

This is what I did for Xavier because I wanted to test some debugging info without changing his original object: turns out it solved the problem! Then I had to go figure out why.

actually an even easier work around is to just open the script that is currently on the object, put add space some where, and then re-save the script.