A difficult challenge: Rez, then Rez back

Hi guys, I'm in a bit of a kerfluffle here... *sigh*

I made a simple rez script that would rez an object, then kill the rezzer. Ok, fine.. not a problem...

but the problem is.. I need to be able to rez the original rezzer from that new object, basically being able to switch back and forth between the two...

I tried putting the script in each object, then the objects in each other... but this will only allow it to rez as many times as I have "layers" of objects. Ie. 1-2-1-2-1-2-1-2-... 2 was empty, so nothing.

I considered using switching alphas, but object 2 is a vehicle, so it may cause problems.

I considered trying to rez by UUID... but as far as I'm aware - that's not possible (is it?)

Basically the script flow should go like this, able to switch between the two objects with a spoken command::

------------
OBJECT 1
------------

On_rez, get owner.
Listen to owner.
On command (from owner), rez OBJECT 2.
Kill self.

-----------
OBJECT 2
-----------

On_rez, get owner.
Act as vehicle, anyone permitted to drive <--- this is done, no problem.
On command (from owner) rez OBJECT 1.
Kill self.


Help!! What can I do?! I need to get this script finished by 4pm Tuesday (SLT)... and it's really frustrating me.

If each object has a copy of itself in inventory as well, it can give a copy of itself to the other object after rezzing it

Yea... I'm confused... but definitely needs llGiveInventory in the equation

*gasps behind her hand*

So simple! Gaaaaaaah! *screams wildly and bangs her head against the wall* Why didn't I think of that.

*turns and gives Day a big hug* THANK YOU!!! *runs off to the LSL portal to read up on llGiveInventory()*

^_^

lolz <3

*groan* Ok, I got the script working. Seems to work fairly well for what I needed. *hugs Day* The only problem was... if I didn't kill the original object, after three objects or so, it would start giving a 40 or so copies to the new object. Killing the object after giving ended up OK, but there're still bugs in it. Not sure why though ~_~

default
{
    on_rez(integer bleh)
    {
        llSay(0,"GIMME");
    }
    
    touch_start(integer total_number)
    {
        llListen(0,"",NULL_KEY,"");
        llOwnerSay("Rezzing Object");
        llRezObject("KTEST - Blue Sphere", llGetPos()+<1,0,0>,ZERO_VECTOR,ZERO_ROTATION,0);
        
    }
    
    listen(integer channel, string name, key id, string message)
    {
        while (message = "GIMME")
        {
            llSay(0,"GIVING BLUE");
            llGiveInventory(id, "KTEST - Blue Sphere");
            llGiveInventory(id, "KTEST - Red Sphere");
            llSay(0,"-----GIVEN -----");
            message == "GIVEN";
            llDie();
        }
    }
}

Without the llDie, it starts giving copy after copy, even with message being changed. ((Yes, I know it's speaking on channel 0.. that was for debug purposes)) The same happens if the while statement is changed to an if statement (without llDie)

Yep that "while" isn't very good at all. Definitely want an "if".
But you would still have the same problem if the object you are rezzing is saying "Gimme" also?

OK I don't really understand the purpose of llGiveInventory in this instance.

You have 2 objects:

A Blue Sphere and a Red Sphere.

Why not just have the Red Sphere in the inventory of the Blue Sphere and the Blue Sphere in the inventory of the Red Sphere.

Red Sphere will rez the Blue Sphere (which contains the Red Sphere in it's inventory) when touched and the Blue Sphere will rez the Red one(which of course has a Blue Sphere in it's inventory).

Well, if you read the first post, I need it to switch between the two. So it rezzes the alternate sphere and gives copies of each to it before deleting itself. Then, clicking on sphere B replaces sphere B with sphere A. (B and A being Blue and Red respecitvely)

The script originally had an 'if', but the problem was there which was why I changed to 'while' and changed the value of 'message', hoping that would fix the problem - but it didn't. Ultimately, it's supposed to say 'Gimme' when it rezzes and then get given a copy of each sphere by the sphere that rezzed it.

*sigh* I really don't get it. In theory, there's nothing wrong with the script without the llDie().

Well I did read it and you don't have to use llGiveInventory.

You have Red in world and tell it to rez Blue.

Blue rezzes and Red dies.

Tell Blue to rez Red.

Red rezzes and blue dies.

You can keep going back and forth endlessly.

Nice and simple

*pouts* Maybe I'm just stupid or something, but I don't see how. Put B inside A... A rezzes B and dies. B tries to rez A, but there is no A inside B to rez...

My brain just fell out reading this post...

ingenious Jesse, now all you have to do is pack Red into Blue and Blue into Red an infinite number of times.

hahahahahaaha. OMG Sorry. Shouldn't have had to try to think about this last night when I was tired.

OK Acknowledged you do have to give inventory. Now I wish I didn't have to go to work or I would pop into world and give it a go.

BTW I did notice the 2 comments here did nothing in the way of helping the OP with her problem.......................

Katryna until I get a chance to work with the code some more or someone else pops in here and helps. Try setting up an if test as to whether the object is named Red or Blue. Then it will know which object to rez.
Object is touched and it rezzes the correct sphere and gives inventory and then dies.

Pseudo Code:

if(name == red){
llRezObject("Blue", etc)
}

else{
llRezObject("Red",etc)
}

Thanks guys. It works fine if I kill it after it gives, using the llDie() that I threw in there... it needs tobe in there anyway to get rid of the original item. I was just curious as to why it was giving so many times, be it with the while command or the if command. I really don't see why it would give it 40 times if I change the vaule of the message, hence ending the whie script.

*smiles*

As for the two items. I just put a script in red and blue each, with the names modified. Though I do see the use of that code Jesse. It would make it easier for someone to modify and use in their own scripts.

http://lslwiki.net/lslwiki/wakka.php?wakka=object_rez

You should put your give inventory stuff in the object_rez event rather than using the "GIMME" stuff..

Ooooh! Thanks Domino! That should cut the script size down a bit ^_^

Create a 2 prims and name them "Red Sphere" & "Blue Sphere".
Put this script into each and then take both into inventory. Rez one into world and then place both red & blue into it's inventory. Then touch the prim and it will rez the other and pass on the inventory and it will die.

Each prim will generate it's own channel in state rez and pass it on. The newly created prim will get that channel in the start parameter and use it until it is touched and creates it's own.

Tested it in world and it works flawlessly.

integer sphere_listen;
integer sphere_chan;
key sphere_key;
string sphere;
float listen_timer = 60.0;



random_chan()
{
	do
	{
		sphere_chan = ((integer) llFrand(3) - 1) * ((integer) llFrand(-9999000));
	}
	while(sphere_chan > -100000);
}

default
{
	state_entry()
	{
		sphere = llGetObjectName();
	}

	touch_start(integer total_number)
	{
		state rezzer;
	}

	on_rez(integer start_param)
	{
		sphere_key = llGetKey();
		llAllowInventoryDrop(TRUE);
		sphere_chan = llGetStartParameter();
		llSay(sphere_chan, (string)sphere_key);
		llSay(sphere_chan,"GIMME");
	}

	changed(integer change)
	{
		if(change && CHANGED_INVENTORY)
		{
			llSay(sphere_chan, "RCVD");
		}
	}
}

state rezzer
{
	state_entry()
	{
		random_chan();//create a new channel to listen on
		llSetTimerEvent(listen_timer);
		if(sphere == "Blue Sphere")
		{
			sphere_listen = llListen(sphere_chan,"Red Sphere", NULL_KEY, "");
			llRezObject("Red Sphere", llGetPos()+<1,0,0>,ZERO_VECTOR,ZERO_ROTATION,sphere_chan);
		}
		else if(sphere == "Red Sphere")		{
			sphere_listen = llListen(sphere_chan,"Blue Sphere", NULL_KEY, "");
			llRezObject("Blue Sphere", llGetPos()+<1,0,0>,ZERO_VECTOR,ZERO_ROTATION,sphere_chan);
		}
	}
	listen(integer channel, string name, key id, string message)
	{
		if(message == "GIMME")
		{
			llGiveInventory(sphere_key, "Blue Sphere");
			llGiveInventory(sphere_key, "Red Sphere");
		}
		else if(message == "RCVD")
		{
			llDie();
		}
		else
		{
			sphere_key = (key)message;
		}
	}
	timer()
	{
		llListenRemove(sphere_listen);
		llSetTimerEvent(0.0);
	}
}

As you can see I am not very verbose because I know what it does any way. Any parts you need clarification on just give me a shout.

That usually isn't a good idea because of lag. You may end up giving the inventory before the object is even rezzed. So you build in confirmation to protect against that.

4 items:
object 1, object 2, script 1, script 2 (1 & 1, 2 & 2)

Object 1 contains a copy of itself(object 1) w/o any scripts, object 2 w/o any scripts, plus script 1 & script 2

Touch Object 1, it rezes Object 2, then gives a copy of all its contents to Object 2.

Touch Object 2, it rezzes Object 1, then gives a copy of all its contents to Object 1.

The problem you run into via previous methods is infinite regression. Using this method, each child object contains a copy of all the mother object's contents.

Be aware, this is an old method for creating grey goo. If you only do this at very low frequency levels, you're fine. Otherwise, this method will trigger the grey goo fence.

Last time I used self replication in Aditi to build a tower I think it was around 50 or so cycles before I hit the fence. And of course those were as fast as they could be rezzed. So she would have to be pretty aggresive to hit it with touch events.

Kelly and Andrew won't come out and actully tell us what the limits are for obvious reasons. But I do know that 50 cycles is much lower then it was a few months ago. Used to be able to rez a tower 2,000 meters high (200 cycles) and now you can't anymore with out putting some serious timer delays in. Even with timer delays it still reachs a point where it is classified by the server as grey goo anyways.

If that happened to me I'd consider it a bug. Sensible thing for the object_rez event to do would be to only trigger on completion of the rez. I'd even go so far as to suggest it should return a NULL_KEY for failed rezzes. So if the event is triggering before the outcome of the rez is known, maybe there should be a jira bug report we could vote on

It isn't a bug, it's just a fact of life sometimes. Not much sense in filing a jira on lag This is the way I have always coded in cases like this since I 1st saw where it can take several seconds for an object to rez at times. It's a case of 2 completely different systems that have to work together. Always have to be careful when you start dealing with the asset server.

How many times have you seen it where you open a script and it takes forever for the text to show? Sometimes it won't ever show and you have to close the script and reopen it.

Soooooooooooooooo. You just build it in so that the object that is rezzed sends a signal back that it is ready to recieve info or inventory or listen or whatever else.

And almost forgot the most important point, just read another thread and it reminded me . You also can't actually give inventory until you know what the key of the recieving object is and it won't have that key until it is rezzed. So if you look at mine, it 1st sends the key to the original and then says "OK, hit me with what you got".

Now I'm really confused. The whole point of the object_rez event is to get the key of the object you just rezzed, hence why I'd consider it returning a key to a non-existant object a bug. Under laggy conditions it should just take longer before the event fires.

Adding more lag by increased listeners and script time really doesn't seem the best approach to handling some lag problems

Dang! 1,100 posts and this one thread has been the thread from hell for me. You are correct Domino and it would look like this:

string sphere;

default
{
	state_entry()
	{
		sphere = llGetObjectName();
	}

	touch_start(integer total_number)
	{
		if(sphere == "Blue Sphere")
		{
			llRezObject("Red Sphere", llGetPos()+<1,0,0>,ZERO_VECTOR,ZERO_ROTATION,42);
		}
		else if(sphere == "Red Sphere")
		{
			llRezObject("Blue Sphere", llGetPos()+<1,0,0>,ZERO_VECTOR,ZERO_ROTATION,42);
		}
	}

	on_rez(integer start_param)
	{
		llAllowInventoryDrop(TRUE);
	}

	object_rez(key id)
	{
		llGiveInventory(id, "Blue Sphere");
		llGiveInventory(id, "Red Sphere");
		llDie();
	}

}