Passing Variables between Objects/Scripts

Hi guys,

I can't seem to find how to pass a parameter or a variable to an object script from another object script.

This is what I want to achieve:

I have an object (Marker Deployer) with two things in its Contents, a script and an object (Marker). When the script in the Deployer is run on touch, it will rezz the Marker, and tell it to go to position 64, 64, 22 in the sim. It then rezzes another marker and tells it to go to position 64, 128, 22 in the sim, and so on (maybe reading these from a List and passing them as parameters to the Marker Script).

Right now I have developed the Marker Deployer, but in its contents I have a large number of Markers, each with the correct position inside as a global vector variable, and each marker is rezzed one by one. But I want to get the number of markers down to just one, and pass the vectors to it on rezz from the Deployer script.

How can I do this? Please put me out of my misery.

Vi

You need to either pass the markers the data required as the rez parameter or establish a communications channel.
Se this thread for more details.

Thanks Newgate. I had looked at the param part of the llRezObject command, but it is defined as integer only, not other types, such as vector.

Idea (a): I suppose I could get around this by making a list of vector positions then using the integer passed param in llRezObject to point to positions in the list. Does this idea sound OK. I also saw that a vector position could be passed directly to the rezzed object, but only works within 10m of the rezzed object.

Idea (b): Another route I thought of was to do the initial rezzing where the first marker needed to go, and then have the Marker spawn a copy of itself (self-replicating) with a new vector, and so on, assuming that my markers are never more than 10m apart. But the idea of self replication fills me with dread.

So I think idea (a) will be best.

(or is it?)

If you have a copy of the vectors in the marker script then yes option A would work. But this would require that you create a new marker object script if you ever change any so is far from ideal. The 10m limit is not really a problem, just have your marker trundle its way to the correct position.

Option B would require that each marker have a copy of a marker inside it, again far from ideal. Especially with the additional problem of the vector of positions inside the marker script.

Basically you want to rez the object with a channel ID as the integer parameter.
In the on_rez event handler start a listen on that channel and then have the rezzer pass the required parameter. Once in position you can have the marker script kill itself unless you still need it for some other purpose.

Read the Thread I suggested and the secondary thread that it directs you too for more details and examples.

You can actually tell it the x/y position through the rez parameter.

If a 1m resolution is sufficient, pass it values from 0 to 65535 and then use simple math to calculate the position.

ypos = llFloor(RezParam / 256);
xpos = RezParam - ypos*256;

Or for greater accuracy in x and y only you could use normalised values over a range of 16 bits each, i.e. 0.003891 resolution.

integer packXY16(vector newpos)
{
    integer x = (integer)(65535. * (newpos .x / 255.0) );
    integer y = (integer)(65535. * (newpos .y / 255.0) );
    integer value = ( (x << 16) +  y);
    return value;
}

vector unpackXY16(integer value)
{
    float const = 0.003891; //  approx 255/65535 
    float x = const * ((value & 0xffff0000) >> 16);
    float y = const * (value & 0x00ffff);

    vector newpos = < x , y , 0 >;
    return newpos;
}

Other permutations are obviously possible i.e. 10 bits each (0.25 resolution) and include the Z to 12 bits (4095 m in 1m resolution or 1024 in 0.25m resolution)

If you want to pass more than 1 thing or may want to send further data then opening a communications channel is the best solution.

You could do a variation on idea b, have your rezzing box travel to each of the marker points and rez a copy of the marker there. This would require only one set of vectors (in the rezzing script) and only one running script as the markers would be completely static.

That would be a far better solution.