What Am I Missing?

Sorry for the vague subject line, but I'm really not sure what's going on. When the object rezzes, this script is supposed to let a companion script in a nearby object know it's there. The other script relays its position and rotation, which this object then matches. When it's done that, the other object deletes itself. The other script is working fine. This one works properly if I manually reset it. If I take it to inventory and rez it, I get the "Rezzed" and "Checking" messages, but the companion object never gets the "Hello". If I then go in and manually reset this script, it all works fine. What am I missing?

integer intSysChannel = -#####;
integer intSysHandle;

default
{
state_entry() {
llOwnerSay("Checking...";
intSysHandle = llListen(intSysChannel, "", NULL_KEY, "";
llRegionSay(intSysChannel, "Hello";
llSetTimerEvent(45.0);
}

listen (integer intChannel, string strName, key keySpeaker, string strMessage) {
list lstTokens = llParseString2List(strMessage, ["|"], []);
vector vecPos = (vector)llList2String(lstTokens, 0);
rotation rotAtion = (rotation)llList2String(lstTokens, 1);

llSetRot(rotAtion);
llSetPos(vecPos);

llRegionSay(intSysChannel, "Done";

llRemoveInventory(llGetScriptName());
}

timer () {
llOwnerSay("No response.";
llDie();
}

on_rez (integer intStartParam) {
llOwnerSay("Rezzed....";
llResetScript();
}
}

Edit: OK, sometimes it doesn't work even on a manual reset.

I'm tempted to suggest that you take all of the stuff in the state_entry event and put it in on_rez instead, replacing the llResetScript, and then remove the state_entry event. It may not make any difference, but it just seems like an unnecessary step to llResetScript when you are going to immediately do all of that stuff when the object rezzes anyway.

I can't see anything in this script that would keep it from working. If you have a really laggy sim, you may just be having trouble with chat lag. I'm just grasping at straws.

Are you absolutely sure that this script is not sending the region say "Hello" ?
Nothing looks wrong here so it could very well be the other script that is not doing the listening correctly.
Maybe put in an llOwnerSay("Said Hello" after the broadcasting the "Hello", or even better set your intSysChannel to 0 so that you can monitor what is going on in chat.
One thing I did notice, is that your object is always going to die after 45 seconds as you don't clear the timer maybe that is correct behaviour but I guess not as you send the owner a "no response" message before dying.

That's true. There really needs to be a llSetTimerEvent(0) call at the end of the listen event to kill the timer.

OK, I got it figured out. This is a two-part system for someone to request that I place an item on their property. They get the placeholder object (the other script), place it where they want it, then click a button on a dialog menu to indicate it's set. The placeholder then fires off an email to me (you probably see where this is going) to let me know to come place the main item, which contains this script. In my testing, I was rezzing the placeholder, setting it, then rezzing the main item, without waiting for the 20-second delay after llEmail(). I assumed it was this script acting up, rather than the placeholder script, since resetting this script suddenly made it work (after the script delay had expired, of course!) Doh!

As for putting the startup functions in on_rez, that's not a bad idea. As I developed the script there was no on_rez event initially, so it just went into state_entry.

As for the llDie() in the timer event, note that when this script finishes its business, it deletes itself. I suppose the llDie() isn't really necessary, as I'm the only one who will be using this script, and I'm not going to be rezzing it anywhere that there isn't a placeholder (except perhaps to work on it); I was just being over-dramatic, I suppose.

Thanks for the replies!

Um.... llDie() won't delete the script; it will delete the object. What you want is llRemoveInventory(llGetScriptName()).

Right -- it's there in the listen event.

Ooops. Right you are. I was distracted momentarily by the words ...



I didn't pay attention to which "it" was which. Sorry about that.