llDetectedLocation()

llDetectedLocation(integer i)
Returns the location where the event occured.
For collisions: returns the location where the two objects collided.

For touches: Returns the offset, in object-local coordinates, from the center of the object where the touch occured.

For sensors: Does nothing, or perhaps returns the same thing as llDetectedPos().

This would open up worlds of possibilities both in terms of GUI and physical applications. Right now Im trying to implement realistic frictionless bouncing effects for a ball, which wont work if the ball doesn't know exactly where it collided.
==Chris

llGetPos();

This will do the trick. Just put it in the code for whatever event is triggered and it will run when it is triggered.

As for touches, we've asked that we have the ability to determine where touched. We know the data is processed, since our body-particles go to the spot when we click-edit an object.

Really? You too? I was asked by Edgware Marker to do something like this a while ago, and I just gave up.
The land_collision events seem to be borked (overly long and unpredictable firing times), and I have long learned not to force LSL to do what it wasn't meant to natively support, or else I'll end up with a crummy proof of concept that isnt good for any practical application... aside from wasting my time.
FWIW, you can detect collisions with a bunch of invisible child prims.
You can build a bounding box around the ball, and each side of your "cube" will be a prim that detects if the collision was at that side, then linkmessages the ball to deform itself accordingly.
Thing is, balls can bounce around arbitrarily, and we can't deform prims in interesting ways, we can only squash them around the three axes, which isnt very flexible.
In a real programming environment, where we have full control over everything and can collect information on everything, it would be a simple clipping operation...

Hiro, are you on crack? What does llGetPos() have to do with knowing which part of a prim has collided with another?

Heh! This is the same difference of interpretation of the word "location" that led to the famous, "That'd be the butt, bob" response that the New Newlywed game denies.

*ahem*

As for the deforming problem, you really need a mesh or series of prims to do good deformations. In that case we're talking second degree differential equations to provide a smooth representation. Love those eigenvalues! I did 3-D mesh altering of single points back in college in an advanced graduate level class. It hurt my brain to learn, but it's really just following equations and plug-and-chug.

So, uh, yeah, our basic prims have XYZ.

Hiro, are you on crack? What does llGetPos() have to do with knowing which part of a prim has collided with another?

Was that a repost or did you just not read?

I thought location like, yannow... location where the object is - i.e. coordinates

no, location of the collision. IE, where the two objects intersected. Not where the calling object's center is.