Detect face touch/collision

for event touch(num_detected) have function integer llDetectedFace(num_detected).
This could also be used with collisions. Values returned would be hex. face 0 = 0x0001, 1 = 0x0002, 2 = 0x0004 , ect. No face 0x0000. This way multiple faces could be detected. Take a simple box, a vert collision would have 3 face ored together, and edge 2 faces ored together.

Uses
reduce number of prims, such as those used for buttons. Reduce number of scrips, less things to load, faster load times. Less lag.

1 prim could replace 5 buttons. view attached image

and code for this prim, if you would like to use it for other things. text displays.

default
{
    state_entry()
    {
        llSetPrimitiveParams([PRIM_TYPE, 2, 0, <0.199, 0.8, 0.0>, 0.68, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, PRIM_SIZE, <0.03, 2.89, 0.5>, PRIM_TEXTURE, 1, "09b04244-9569-d21f-6de0-4bbcf5552222", <2.48, 1.0, 0.0>, <-0.740013, 0.0, 0.0>, 0.0, PRIM_TEXTURE, 6, "09b04244-9569-d21f-6de0-4bbcf5552222", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0, PRIM_TEXTURE, 4, "09b04244-9569-d21f-6de0-4bbcf5552222", <-14.75, 1.0, 0.0>, <0.130009, 0.0, 0.0>, 0.0, PRIM_TEXTURE, 7, "09b04244-9569-d21f-6de0-4bbcf5552222", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0, PRIM_TEXTURE, 3, "09b04244-9569-d21f-6de0-4bbcf5552222", <2.48, 1.0, 0.0>, <-0.255989, 0.0, 0.0>, 0.0]);
    }
}

to vote on this go here.
http://secondlife.com/vote/index.php?get_id=918

That's a clever prim - 5 almost coplanar almost-equal-sized faces. I'll have to see about using it for text, since I've been using a flattened cube and that only gets you 3 letters or digits per prim. I think it might even be possible to make it flatter than you're showing, but I'm not in world to check.

yes it can be flatter than that, just expanded it so you could see it. less then 0.03 you start to get some texture shimmer problems when viewed from a distance.

Lovely work on that 5 face trick.

As far as touches are concerned though - similar ideas have been mentioned before - but in general we would actually like to tell where on each face the touch was.

We could have, for example, a function vector llDetectedTouchPos(integer i).
Basically it would take a number from 0 to num_detected-1 (just like any other detect function) and return a vector <u, v, f> where f is the number of the touched face, and u and v are the co-oridinates on that face that were touched.

u and v would run from 0.0 to 1.0 - basically if you apply a texture to a face with 1x1 repeats then u would be like the x coordinate of the texture - running from the left hand side to the right - and v would be the vertical coordinate.

LL will have to do this eventually, if they want to have interactive html on prims. The question is only when (and how bugged will it be )

I'd like to see llGetMouseCoordX, llGetMouseCoordY. I think that would be much quicker for LL to implement. That could be used to make detect face and touch position functions in LSL(with a bit of vector math on objects that are not HUDs), and also make HUDs much more useful. An llDetectedTouchPos function would be more useful though, but if just giving us simple mouse coordinates were faster to implement I'd like to see that first. A way to detect touch positions is needed sooner, rather than later.

You've got 5 of my votes.

Prop 288 is essentially the same idea.

P.S. Awesome prim Gearsawe!

What would these functions return? I'm guessing you are thinking of screen pixels - but I'm uncertain how you would use these in LSL to work out where the face was touched.

I also assume, you only want these inside things like touch events, because at other times the SL servers (where the LSL is running) have no idea where my cursor is.

I fully endorse Ben Bacon's proposal.

I did a hotline regarding touch positions, looks like they're at least looking into the possibility of exposing this to LSL.

One thing I've noticed is when I start editing a prim, a particle emitter comes from my hand and hits the exact area i hit with my mouse when entering edit mode. So something tells me that it is very possible to detect x/y position and face already - it's just a matter of SL people of making a method to expose that functionality.

Is this no longer supported??