Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Scripted objects wandering away

Umble Serf
Registered User
Join date: 27 Apr 2006
Posts: 3
06-15-2006 00:45
I have some scripted objects that instantiate themselves with the following:

vector homepos;
rotation homerot;
default
{
state_entry()
{
homepos = llGetPos();
homerot = llGetRot();
}
}

and then, if moved, the objects attempt to return home with:

{
llSetRot(homerot);
vector currpos = llGetPos();
while(currpos != homepos)
{
llSetPos(homepos);
currpos = llGetPos();
}
}

Every now and again, I log in and discover that my objects have wandered off and have been returned to my lost and found. Any ideas about what I'm doing wrong?

Thanks in advance,

Umble Serf
Nargus Asturias
Registered User
Join date: 16 Sep 2005
Posts: 499
06-15-2006 03:17
Mmm...your object isn't happened to be near the edge of a sim, is it? I guess it could be a reason.
_____________________
Nargus Asturias, aka, StreamWarrior
Blue Eastern Water Dragon
Brown-skinned Utahraptor from an Old Time
Umble Serf
Registered User
Join date: 27 Apr 2006
Posts: 3
06-15-2006 08:47
The objects *are* within 10-20 meters of three other sims (the natural result of having a corner lot), but they are contained within a building with meter thick walls and roof. Additionally, two of the objects are contained in an enclosure within the building. What I can't figure out is how they manage to escape their surroundings and wind up several sims away (in some instances). About the only thing that makes sense to me is that somehow the global script variables for the position and rotation get changed or corrupted.
Duke Scarborough
Degenerate Gambler
Join date: 30 Apr 2006
Posts: 158
Suggested Fix
06-15-2006 09:41
One thing that may matter is where the item was initially created/rezzed? Remember that default: state_entry() happens the first time you put the script in, and when you rez a NEW copy of it.

If you drag one out of your Trash or Lost and Found, default: state_entry() does NOT fire.

Suggest changing it from state_entry to on_rez

That will set the home coordinates when you drop the item on the ground, whether it's an original or a copy.
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
06-15-2006 09:45
This is really a scripting issue, and would get better treatment in the Scripting Tips forum. :)

First, 32-bit floating point numbers have very low precision, so don't compare to exact positions. compare to within some critical distance to a target position, like so:

CODE

vector homepos;
rotation homerot;
default
{
state_entry()
{
homepos = llGetPos();
homerot = llGetRot();
}
}

and then, if moved, the objects attempt to return home with:

{
llSetRot(homerot);
vector currpos = llGetPos();
while(llVecDist(currpos,homepos) > 0.01)
{
llSetPos(homepos);
currpos = llGetPos();
}
}


Second, if they are not physical (and they have to be for that script to work to begin with), then walls, floors, etc are not obstacles/barriers and cannot contain them. You can llSetPos objects (and yourself, if you are sitting on one) through any other object except the ground.
Nargus Asturias
Registered User
Join date: 16 Sep 2005
Posts: 499
06-15-2006 10:12
If the objects ended up a few sims away, my guess is that it somehow run over the sim edge? If it cross the sim edge, your llSetPos command won't make the object go back to its original position, but run away further more.

Maybe use region pos check will help?
_____________________
Nargus Asturias, aka, StreamWarrior
Blue Eastern Water Dragon
Brown-skinned Utahraptor from an Old Time
Umble Serf
Registered User
Join date: 27 Apr 2006
Posts: 3
06-15-2006 10:19
I initially posted here thinking that this was a technical problem, but it may simply be sloppy scripting. I'm not as much looking for scripting help as trying to understand what's happening. Some more details ... specifically, I have a bowling pin that is physical and, when hit, bounces/rolls around and remains until a listen tells it to reset. At that point it turns off physical, executes the while script to move home, and then turns physical back on. It returns home so it would seem that the position variable is initially set correctly and while it may oscillate around trying to exactly attain new_pos == old_pos, it still doesn't seem to explain how the pin might somehow bounce through the wall and into another sim. Additionally, since I have almost no traffic, I don't believe it is actually moved while I'm logged out ... it just runs off somewhere at random and is returned to me when I log in again.

However, I'll try the suggested changes and see what happens ... also, I'll try posting in Scripting Tips.

Thanks :)
Duke Scarborough
Degenerate Gambler
Join date: 30 Apr 2006
Posts: 158
06-15-2006 10:40
Aye - What Talarus said makes sense too!

In the world of floating numbers, 1.03-1.03 may equal -.0999999 or something equally bizarre. By limiting the precision you expect, you may find that the problem goes away.
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
06-15-2006 10:56
Ahh.. well, now we have some more info, I have a few more possibilities for you to consider.

The physics engine is, at best, primitive, and has some quirks, especially when it comes to turning physics on and off. One thing that is common is when you set an object from non-physical to physical, and any part of that object's bounding box intersects the bounding box of any other object, it will get "kicked" off in a random direction, sometimes quite hard; hard enough to end up off-world and back in your Lost+Found. The same issue applies when you stand up from sitting and you "bounce" out of the chair.

Also, if the object is moving fast enough, it will go right through walls/floors/ceilings no matter how thick they are. Apparently collision detection is discrete and only for the surface of an object (or its bounding box). If the physics engine discovers that two objects are intersecting, it "freaks out" and sends one of them flying off in a wild direction.

Not sure if any of that is the cause, but it is something to think about in the design of physical/non-physical switch objects.