llRezObject() Delay Workaround?

I have this system setup where it rezzes an object out whenever it can depending on the delay of the llRezObject(). As you all know this can be a drag.

Someone had spoken to me a while back on how to get around function delays by using something like a relay system so that each request for a llRezObject() is handled in its own script from the master script.

Well, I tried setting something like this up using llMessageLinked() to different scripts which can than llRezObject(). I had no idea really, just thought I would give it a shot. Unfortunately, this did not work out.

So, then I tried creating 5 additional prims with their own script. I got an error but only because the object that needed to be rezzed did not exist in the new linked prim. What sucks about this approach is that all the rezzed objects and textures I require would end up having to be duped into each "relay" linked prim. That's an approach I just hope I don't have to accept.

So, I am asking you folks if you know how this is done or if it is even possible with llRezObject(). In their case I believe they were relaying e-mails out and I'm sure you are aware of the delay involved with e-mailing. Any ideas?

Any help much appreciated.

You were on the right track with the multi scripts.

Along the lines of:

(assume a timer event of 0.1)

timer()
   {
   	i++;
   	if(i > 5) i=1;
   	llMessageLinked(LINK_THIS, i, "rez_obj", "");
   }

and in the 5 slave scripts:

link_message(integer src, integer num, string msg, key id)
   {
   	if ( msg == "rez_obj" && num == 1 ) //the num should be different in each slave script, 1 through 5.
   	{
   		llRezObject("object", <yadda yadda yadda>);
   	}
   }

All in the same prim.

Thanks a tons, Jillian. Found out that llGiveInventory() was an additional drag I had to relay. Your script is a huge help in trying to wrap my head around this issue.