Second Life Forums Archive - bot moved by llApplyImpulse sometimes flies away...

DannyK Bailey

Registered User

Join date: 28 Jun 2007

Posts: 2

06-28-2007 08:48

Hi, all

I am working on a bot that runs around in random directions. If it walks into something, it selects a new random direction and moves there.

To keep it under control, I let my bot run around inside a small fence I build, a physical 2m high boundary.

Now I've got the problem that sometimes under circumstances I haven't been able to reproduce, to little bot (wood sphere) simple flies away.
It seems to walk into a corner, and sometimes while trying to get out again it kinda pops out of the corner and flies away and often leaves the parcel.
It looks a bit as if it explodes away, like those explosions one gets from "mis-placing" physical prims...

Is there a way to make sure that a prim stays below a certain altitude?

Here's some code:

changeDirectionRandomly()
{
float speed = llGetMass()/SPEEDFACTOR;
llApplyImpulse(speed * getRandomVector(10.0, TRUE), FALSE);
}

SPEEDFACTOR is a constant to influence the speed of the bot, currently at 2.0.
getRandomVector(float range, integer flat) returns a random vector, with an unchanged z value if "flat" is true.

Is that enough info?
Has anybody encountered this phenomenom before and can help me?

Lee Ponzu

What Would Steve Do?

Join date: 28 Jun 2006

Posts: 1,770

06-28-2007 09:40

Lots of different ways. One is to create another standalone script. When it starts, it records its position. Once per second or so, it checks its current position. If it is too far from the starting point, it turns off physical and uses llSetPos() to go back to the starting point.

While you are at it, you can check for edge of world, sim boundary, no script areas, over your land, and so on.

Senuka Harbinger

A-Life, one bit at a time

Join date: 24 Oct 2005

Posts: 491

06-28-2007 15:19

I've run into this problem a lot with my A-Life experiments. there are two causes for objects self "orbiting" that I know of and was able to actively reproduce

1) interpenetration. sometimes if the object is colliding into/against a surface (*NOT the ground*) enough times the engine will have calculated it's bounding box as interpenetrating the object it's colliding with and it will cause a relatively fast push on the object tangential to what it was penetrating. There is no simple work around for this, but it is a rare occurance.

2) Impules applied during a collision. If an impulse is applied while the object is actively colliding (*NOT the collision_start and collision_end events), it will regularly orbit itself with a force of nearly 100 times what was applied during the impulse. The easiest work-around I found for this is to use your llApplyImpulse in the collision_end event (and to some extent the collision_start event, although orbits caused by the first cause happen more frequently).

My current working theory is that the impulse given during collision causes the object to interpenetrate what it's colliding with, resulting in the first cause for orbiting, but since the collision event is still being fired, the impulse is still being applied for every collision registered and thus the amount of force enacted on your object keeps on increasing to multiple times what you intended to use.

_____________________

My SLExchange shop

Typos are forgiven; desecrating the english language with reckless abandon and necrophilic acts is not.

The function is working perfectly fine. It's just not working the way you wanted it to work.

Griffin McAlpine

Registered User

Join date: 7 Jan 2007

Posts: 16

06-28-2007 17:54

From: Senuka Harbinger

I've run into this problem a lot with my A-Life experiments. there are two causes for objects self "orbiting" that I know of and was able to actively reproduce

1) interpenetration. sometimes if the object is colliding into/against a surface (*NOT the ground*) enough times the engine will have calculated it's bounding box as interpenetrating the object it's colliding with and it will cause a relatively fast push on the object tangential to what it was penetrating. There is no simple work around for this, but it is a rare occurance.

2) Impules applied during a collision. If an impulse is applied while the object is actively colliding (*NOT the collision_start and collision_end events), it will regularly orbit itself with a force of nearly 100 times what was applied during the impulse. The easiest work-around I found for this is to use your llApplyImpulse in the collision_end event (and to some extent the collision_start event, although orbits caused by the first cause happen more frequently).

My current working theory is that the impulse given during collision causes the object to interpenetrate what it's colliding with, resulting in the first cause for orbiting, but since the collision event is still being fired, the impulse is still being applied for every collision registered and thus the amount of force enacted on your object keeps on increasing to multiple times what you intended to use.

Ive also had the same problems.

Ive recently noticed another odd effects with the A-Life stuff ive made (well not quite A-Life..genetics isnt implimented yet.. but soon

) . More often than not after/during the orbit event they change from physical to nonphysical and just hang there, sometimes a sim or two away. To clean up Ive had to make a hud that llRegionSays a trigger for llDie if NonPhys.

As an aside Ive noticed recently other odd behavour... such as switching targets .. or just switching to non phys for no apparent reason...very strange stuff that I will need to track down... .

oh and thx Senuka will try that work around ...but sheesh its irritating.

DannyK Bailey

Registered User

Join date: 28 Jun 2007

Posts: 2

06-29-2007 02:07

Thank you, Lee and Senuka,

those are some very interesting starting points for further "investigation".

I'll see what I can do with these ideas and post a follow-up with my findings.

Thank you again, since this was exactly the nudge into a new direction, that I had been hoping for.

DannyK

bot moved by llApplyImpulse sometimes flies away...
DannyK Bailey Registered User Join date: 28 Jun 2007 Posts: 2	06-28-2007 08:48 Hi, all I am working on a bot that runs around in random directions. If it walks into something, it selects a new random direction and moves there. To keep it under control, I let my bot run around inside a small fence I build, a physical 2m high boundary. Now I've got the problem that sometimes under circumstances I haven't been able to reproduce, to little bot (wood sphere) simple flies away. It seems to walk into a corner, and sometimes while trying to get out again it kinda pops out of the corner and flies away and often leaves the parcel. It looks a bit as if it explodes away, like those explosions one gets from "mis-placing" physical prims... Is there a way to make sure that a prim stays below a certain altitude? Here's some code: changeDirectionRandomly() { float speed = llGetMass()/SPEEDFACTOR; llApplyImpulse(speed * getRandomVector(10.0, TRUE), FALSE); } SPEEDFACTOR is a constant to influence the speed of the bot, currently at 2.0. getRandomVector(float range, integer flat) returns a random vector, with an unchanged z value if "flat" is true. Is that enough info? Has anybody encountered this phenomenom before and can help me?
Lee Ponzu What Would Steve Do? Join date: 28 Jun 2006 Posts: 1,770	06-28-2007 09:40 Lots of different ways. One is to create another standalone script. When it starts, it records its position. Once per second or so, it checks its current position. If it is too far from the starting point, it turns off physical and uses llSetPos() to go back to the starting point. While you are at it, you can check for edge of world, sim boundary, no script areas, over your land, and so on.
Senuka Harbinger A-Life, one bit at a time Join date: 24 Oct 2005 Posts: 491	06-28-2007 15:19 I've run into this problem a lot with my A-Life experiments. there are two causes for objects self "orbiting" that I know of and was able to actively reproduce 1) interpenetration. sometimes if the object is colliding into/against a surface (NOT the ground) enough times the engine will have calculated it's bounding box as interpenetrating the object it's colliding with and it will cause a relatively fast push on the object tangential to what it was penetrating. There is no simple work around for this, but it is a rare occurance. 2) Impules applied during a collision. If an impulse is applied while the object is actively colliding (*NOT the collision_start and collision_end events), it will regularly orbit itself with a force of nearly 100 times what was applied during the impulse. The easiest work-around I found for this is to use your llApplyImpulse in the collision_end event (and to some extent the collision_start event, although orbits caused by the first cause happen more frequently). My current working theory is that the impulse given during collision causes the object to interpenetrate what it's colliding with, resulting in the first cause for orbiting, but since the collision event is still being fired, the impulse is still being applied for every collision registered and thus the amount of force enacted on your object keeps on increasing to multiple times what you intended to use. _____________________ My SLExchange shop Typos are forgiven; desecrating the english language with reckless abandon and necrophilic acts is not. The function is working perfectly fine. It's just not working the way you wanted it to work.
Griffin McAlpine Registered User Join date: 7 Jan 2007 Posts: 16	06-28-2007 17:54 From: Senuka Harbinger I've run into this problem a lot with my A-Life experiments. there are two causes for objects self "orbiting" that I know of and was able to actively reproduce 1) interpenetration. sometimes if the object is colliding into/against a surface (NOT the ground) enough times the engine will have calculated it's bounding box as interpenetrating the object it's colliding with and it will cause a relatively fast push on the object tangential to what it was penetrating. There is no simple work around for this, but it is a rare occurance. 2) Impules applied during a collision. If an impulse is applied while the object is actively colliding (*NOT the collision_start and collision_end events), it will regularly orbit itself with a force of nearly 100 times what was applied during the impulse. The easiest work-around I found for this is to use your llApplyImpulse in the collision_end event (and to some extent the collision_start event, although orbits caused by the first cause happen more frequently). My current working theory is that the impulse given during collision causes the object to interpenetrate what it's colliding with, resulting in the first cause for orbiting, but since the collision event is still being fired, the impulse is still being applied for every collision registered and thus the amount of force enacted on your object keeps on increasing to multiple times what you intended to use. Ive also had the same problems. Ive recently noticed another odd effects with the A-Life stuff ive made (well not quite A-Life..genetics isnt implimented yet.. but soon ) . More often than not after/during the orbit event they change from physical to nonphysical and just hang there, sometimes a sim or two away. To clean up Ive had to make a hud that llRegionSays a trigger for llDie if NonPhys. As an aside Ive noticed recently other odd behavour... such as switching targets .. or just switching to non phys for no apparent reason...very strange stuff that I will need to track down... . oh and thx Senuka will try that work around ...but sheesh its irritating.
DannyK Bailey Registered User Join date: 28 Jun 2007 Posts: 2	06-29-2007 02:07 Thank you, Lee and Senuka, those are some very interesting starting points for further "investigation". I'll see what I can do with these ideas and post a follow-up with my findings. Thank you again, since this was exactly the nudge into a new direction, that I had been hoping for. DannyK

Welcome to the Second Life Forums Archive

bot moved by llApplyImpulse sometimes flies away...