Collision Detect using hollow prims

I'm trying to build an archery target and try as I might, I can't seem to get collision detect working reliably with the smaller prims. The first few rings work fine, and I see no issues, but when I get the last 2, I have issues. If I detect collisions on the rings themselves, more than one ring reports a collision to the scoring prim, and if I detect collisions on my arrow it doesn't report more than one, but try as I might I can't get it to detect a collision on the bullseye, it always reports hitting the ring around the bullseye.

Is there some sort of limitation in size? Anyone know of a way around it? I'd prefer to keep the collision detect on the rings themselves, but multiple hits on multiple rings with one shot is a bad thing.

I've tried hollow cylinders, as well as rings with no luck.

A collision occurs when two object are within about .01 meters of eachother. This is fine for large objects. Yet crap for small ones. I suggest you make your target a single prim and have it calculate the distance the arrow is from the center of the target after a collision occurs.

only issue I see is that if it's a true ballistic flight, you'll also have to take into account the arrow's rotation to determine where the tip of the arrow actually hit the target. It's still very doable like that, just takes a bit more math.

[edit]Thinking on it some more, you'd have to take into account the arrow's rotation AND the target's rotation no matter what because of shots that aren't completely tangent to the target. Recall that llGetPos() returns from the center of the root prim (same goes with llDetectedPos() and llDetectedRot() ). It'd be simple enough to build your target (and arrow) so that with zero rotation they'd collide dead on, and then adjust the math for the rotations from there. I have a locational based damage system I worked on that relies on the same principle.[/edit]

Wow, that sounds way way beyond my capacity.. Is there some sort of example script that can show me how to do this? I learn better by seeing functional code. It's easier for me to understand than trying to root through the wiki and find how to put it all together.

you might try in a collision even of the arrow setting the physics off, if your using physical arrows. This will cause it to "stick". I haven't tested it yet, but something to try.

There's another way too. One that wont involve writing a fancy script. You can make a cylinder and place a target texture on it. Then overlay invisible hollow cylinders/rings over the target's rings and place a simple collision script in each ring. Using this method, you'll be able to make the invisible rings narrower than the visual rings on the target.

Bullseye!



...maybe

that's nearly the same method that isn't working right now, due to the error in bounding boxes.

the turning non-physical sounds like a creative solution to the problem. it should work in theory.

When I get a chance in world, I'll see if I can't put together a collision script that will accurately calculate where on the target an arrow hits.

Have you tried making the arrow's point the root prim?

that could be used to eliminate some of the math with rotations, but you'd still need to compensate for the rotation of the target itself.

or better yet, adding a 0.01x0.01x0.01 sphere, dimpled till it resemble a cone with a roundd base, and adding it as the root prim, at the very tip of the arrow head. since dimple remove prim material from the geometric center of the prim, that fine point on the dimpled sphere's tip is now the geometic center for the whole object and at the very tip of the arrow.

These are all really good suggestions as to the build of the arrow. As for the ring method, I tried that by making the target comprised of several different rings, that's when I had the problem of the arrow not ever reporting hitting the bullseye (if the collision script was in the arrow) or hitting multiple rings (when the script was in the ring).

I'll be interested to see if you come up with something Senuka, thanks for taking a look at it.

My arrows penetrate the target to a greater or lesser extent. How do I calculate a vector distance on two planes that will still work if the target is turned?

I'm getting a problem where the position reported during collision_start appears to be one "frame" before the collision. The faster the object travels the farther away it reports.

I have the direction that the object is traveling and how fast it is traveling, but the math would have to assume that the physics engine is running at it's normal frame rate

collision_start(integer times)
{
vector Vel = llDetectedVel(0);
vector ImpactPos = llGetDetectedPos() + (Vel * someNumber);