Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Script failure depending on rez location

Ethan Cinquetti
Registered User
Join date: 5 Jul 2005
Posts: 24
09-21-2005 17:35
Hello,

I've created a simple object which offers a weblink when touched.

To avoid the 10-second delay built in to llLoadURL(), I've set the main object to rez a small, short-lived workhorse pellet, and to pass over the key of the citizen to whom the link should be offered.

The pellet is rezzed non-physical, and opens a listener on the channel which it receives as the argument to its on_rez() event. When it receives the key, it steps through this sequence (I'll list the order carefully, in case something here is the problem):

- removes its listener,
- sets its buoyancy to 1.01,
- sets PHANTOM | PHYSICS to true,
- sets a timer event to 25.0, which will trigger llDie() when called (I should probably set temp-on-rez as well, but I understand it's unreliable...?)
- finally, offers the URL as it wafts skyward.

All of this works fine when I rez at the main objects's position without using an offset. But it looks wrong. The pellet should rez in mid-air, slightly above the main object, which is shaped to suggest a projector of some sort.

As soon as I try to rez with a slight positive offset on the Z axis, the rezzed object hangs. It rezzes in the right position, but that's it.

Can someone spot something obviously wrong?

Thanks!

-- Ethan
Keknehv Psaltery
Hacker
Join date: 11 Apr 2005
Posts: 1,185
09-21-2005 19:09
You don't need a workhorse object. Just have about 5 of them in your object, and give them commands with a link message. That's a much nicer approach.

Make the object die after the llLoadURL call. Why does your object need to be physical?
Ethan Cinquetti
Registered User
Join date: 5 Jul 2005
Posts: 24
09-21-2005 19:30
Thanks for responding, Keknehv :-)

I thought about doing it the way you mentioned, but decided this approach was slightly more visually interesting. And I think I have the hang of linked messages, so it was just an excuse for me to tinker with a couple of features which I hadn't tried before.

The pellets turn physical just so they can float upward.

Oh, and thanks for pointing out the needless timer setup...a simple llDie() call would obviously work just as well if there's a built-in delay, and I'm a bit embarrassed that someone had to correct my thinking on that :-)

-- Ethan
Ben Bacon
Registered User
Join date: 14 Jul 2005
Posts: 809
09-22-2005 02:04
Ethan: This is just a guess (and don't ask me to explain why offset should make a difference here, but multi-threading is often susceptible to the strangest factors). When does you rezzer say the key? Is there any chance that it is saying it before the rezzed gets around to listening? You may want to have the rezzer open a listen before rezzing. The rezzed opens its listen before saying "hi" to the rezzer. Only then does the rezzer say the key - knowing that no matter what delays occured on the sim, the message will get through.
Ethan Cinquetti
Registered User
Join date: 5 Jul 2005
Posts: 24
09-22-2005 06:11
Ah! I thought about that issue, briefly, when I was thinking the problem through initially...then, completely forgot about it when I sat down to do the work.

I'll try that fix tonight.

Thanks, Ben!

-- Ethan
Ziggy Puff
Registered User
Join date: 15 Jul 2005
Posts: 1,143
09-22-2005 09:33
A couple of suggestions. I had a setup where the rezzer needed to talk to the rezzed object. The rezzer gets an object_rez event when the child object has been rezzed. You can use that, instead of waiting for a while after llRezObject - it gives you a slightly better guarantee that the object actually has been rezzed. In my testing, I found it best to sleep for a bit inside the object_rez event before trying to talk to the new object, to give it time to set its scripts up. Butif the initial handshake comes from the child object, that might not be necessary.

Also, set buoyancy before you turn on physics (you're probably already doing this). And it doesn't hurt to have the child object give itself a slight impulse upwards to ensure that it starts floating up, in case the buoyancy itself doesn't take care of it.

And finally, throw in llOwnerSays at key points in your script for debug - that way you'll know if the listen events got triggered, stuff like that. Of course, remove the says once you have it working.
Christopher Omega
Oxymoron
Join date: 28 Mar 2003
Posts: 1,828
09-22-2005 09:52
I would recommend you not use physics at all here. If you plan on rezzing many of these workhorse objects simultaniously (I use the same workaround to get around the email delay) use temp-on-rez instead. Set the workhorse object to phantom using llSetStatus(STATUS_PHANTOM, TRUE), and temp-on-rez using llSetPrimitiveParams([PRIM_TEMP_ON_REZ, TRUE]).

Instead of using a timer event to call llDie, why noy simply call it after calling llLoadURL?

Here's a little sample:
CODE

// Put this script in an object called "urlworker".
string SEPERATOR = "#~#";
default {
on_rez(integer param) {
if (param != 0) { // Rezzed by script.
llSetStatus(STATUS_PHANTOM, TRUE);
llSetPrimitiveParams([PRIM_TEMP_ON_REZ, TRUE]);
llListen(param, "", NULL_KEY, "");
} else { // Rezzed by user
llSetPrimitiveParams([PRIM_TEMP_ON_REZ, FALSE]);
}
}
state_entry() {
llSetObjectName("urlworker");
}
listen(integer c, string n, key id, string m) {
list urlParams = llParseStringKeepNulls(m, [SEPERATOR], []);
key dest = (key)llList2String(urlParams, 0);
string msg = llList2String(urlParams, 1);
string url = llList2String(urlParams, 2);
llLoadURL(dest, msg, url);
llDie();
}
}


And here's the code you use in the main script:
CODE

// Call this function instead of llLoadURL:
loadURL(key dest, string msg, string url) {
integer chan = (integer) llFrand(18271) + 1;
llRezObject("urlworker", llGetPos(), <0,0,0>, <0,0,0,1>, chan);
llWhisper(chan, llDumpList2String([dest, msg, url], "#~#"));
}

==Chris
_____________________
October 3rd is the Day Against DRM (Digital Restrictions Management), learn more at http://www.defectivebydesign.org/what_is_drm
Keknehv Psaltery
Hacker
Join date: 11 Apr 2005
Posts: 1,185
09-22-2005 15:14
Aaaack... wrong brace style. My religion calls you infidel-- I must destroy you now.

Christoper, for your loadURL function, you really need a pause before it issues a command.

Ethan, for the effect, it might be easier on both you and the sim to use a particle effect. The object could emit one particle that gradually rises--and you wouldn't have to bother with physics at all.
Ethan Cinquetti
Registered User
Join date: 5 Jul 2005
Posts: 24
Thank you!
09-22-2005 21:22
Thanks so much for the thoughtful examples and insights. I'll keep this entire thread handy as a resource. I appreciate the time you all took to help me!

Keknehv, I also appreciate your post on the PHP versus CODE tagsets. I was unaware of the former.

-- Ethan