Actually Stopping on collide, not bouncing.

So I'm playing around with a crossbow I made. One of the firing modes is a grappling hook and zipline (works amazingly well) but I'd like the bolt fired by the crossbow to actually look like it's touching the prim it collided with.

Having spent hours with llSetForce and llApplyImpulse I'm unable to get a reliable result.

I've tried rezzing a "dead" copy of the bolt on collide but the actual rez location seems to vary depending on the force of the impact (sometimes right on the money, sometimes a few meters away).

I've seen it done but I can't seem to come up with a "sweet spot" on either technique.


I thought perhaps the mass of the bolt (rather small object) was gaining too much momentum but llSetForce(-llGetMass()*-llGetVel(),FALSE); still results in a gap between the wall and the bolt.

Any advice? Am I even on the right track?

Turn off physics on the object.

llSetStatus(STATUS_PHYSICS, FALSE);

Thanks for the idea Hewee but thats been a caveat since the first test and the script still seems to trigger after the slight bounce has occurred, stopping it at various distances from the walll depending on the range it's fired from.

Having played with the speed of the projectile, adding mass and enclosing it in clear prims of various shapes and material types (which appears to do nothing at all) I've decided to just accept that it's going to be a slight bit off.

Only a cosmetic thing anyway, doesn't effect the function of the device

when you switch physics off move it forward a little immediately after?

you can guess how far forward to move it by starting position and contact position... or perhaps with a get velocity call right before. that should give you a good starting point for an effective average.

Oh. Yeah. Unfortunately the timeliness of a collision event often leaves a lot to be desired. Sorry. Thought it was a question of how to stop it rather than when to.

thought of another variation, making the arrow use volume detect, then when you turn off physics it should be embeded in your target colliding object...

The collision model of a prim is slightly larger than the prim itself. That is where your problem stems from.

So when the objects "collide" its actually their collision models which collide which ultimately leaves you with a small gap between the prims.

Now go forth and use that knowledge to your advantage.