Touch X,Y coordinates!

Wouldn't it be nice to be able to detect the X,Y,Z of a 'touch' by an avatar, relative to the prim being touched?

Buttons/prims for the buttons could be saved and scripts could calculate where on a texture face the object was being touched. With proper bump-mapping, indentations and extractions could be accomplished through proper texturing.

Fewer scripts would be necessary to accomplish multi-use items.

Right-click menu would detect where the initial menu-touch was on the object and send the information with the touch.

X,Y,Z would be sent in %age (0,0,0 for top/right/front to 100,100,100 for bottom/left/rear) to avoid calculation problems with current zoom and camera rotation. The face being touched would set one of the params to 0 or 100 (e.g. touching the front would yield a 0 for z, touching the rear face would yield a 100 for z).

EDIT: There are two proposals for something similar on the vote forum. They should be encapsulated into one proposal and the votes combined:

Proposal 918 and
Proposal 621

The first one doesn't go far enough - it asks only to detect touched face.
The second one asks for a vector x,y,z but that can be problematic in zoom/non-zoom mode. The x,y,z vectors are based upon meters in SL and objects can be .5 metre in size, giving decimal vectors for those items. (This may work but may be harder to program to?)

I've voted for 621 - but these two should be combined to reflect the number of votes applied to both proposals (so we can get to 500!)

The vector would be nice actually. I'm not sure what the issue with zoom and non-zoom modes is? Surely the click location of a touch is always going to be where your mouse cursor is when you clicked? So if I click on a side of the object my avatar can't see, it doesn't matter as that is where I clicked.

As for the vectors being in metres, fractions of metres are just fine, I'm not sure that's an issue unless you want to have buttons on your object measuring less than 1cm horizontally or vertically
So with a 0.5 x 0.5 face on a vendor, with it being divided into two buttons across the middle.

Only thing I'm undecided on is what type of vector is most useful, I'm thinking it would likely be best to have a vector simply be relative to the object. So if the object is facing some odd angle then it won't have to calculate this in order to deal with my touch. If you REALLY need to have the touch co-ords in region co-ordinates or something then you can calculate it from that rather than the other way about.

But yeah, this would have been really nice for my doors, currently they are just sticking with looking at where the avatar is rather than which side they touch to determine which way to swing.

Actually, was just thinking on this recently. Phenominal idea.

Right now, if there is a multi-option menu, builders actually use a 1-prim invisible cover for each option. A vector touch would allow menus of any length that use only one prim. What a boon!

Conceptualization is easy: go by percentages and faces. That way, no matter if the item is resized or not, it will still register the same touch area.

Graphic example:

MENU OBJECT:
-----------------------
1. First Choice
2. Second Choice
3. Third Choice
-----------------------

llTouchVector(variable); // where variable is a vector <x1,x2,y1,y2,face>, x being top to bottom and y being left to right, face being side of the object.

If (variable = <10,30,5,95,1>.... choice is 1
If (variable = <31,62,5,95,1>.... choice is 2
If (variable = <63,90,5,95,1>.... choice is 3


Resize/stretch all you want, vectors would remain constant since they are representations of percentage of overall size. Internals would do the actual math.

Viola!

[edit: just realized that's what Duke proposed in the first place. doi. LOL I like the way you think, Duke. ]

agree.
But not integer return values - why limit accuracy like this for no real gain?
Vectors are real valued regardless - ranges of 0 to 1 or -1 to + 1 make more sense than integer only 0-100. You will generally be checking if the touch was inside a larger area anyway - so will have to check whether the touch x and y are within a particular range.

Expect some very odd results on odd shaped prims

It would certainly simplify a lot of my work - I currently rely on user being in mouselook, and use a modification of this script by Jeffrey Gomez:
[thread=38717]

I'll see if I can free up some votes.

Meanwhile, check proposition 1289


ps One nice thing in 621, if you want to rez something at touch position, that becomes trivially easy - but if you have one UI face, it should remain very simple to get useful x,y values

Surely the easiest implementation is:

state_entry() { llSetText("Click on the buttons for stuff!", <1.0,1.0,1.0>, 1.0); }
touch_start(integer x) 
    vector touchPos = llDetectedTouch(--x); // Returns <x%, y%, z%>
    integer face = llDetectedTouchFace(--x);
    if (face == 1) 
        if ((touchPos.y >= 0.0) && (touchPos.y <= 0.5)) llSay(0, "Button 1 pressed!");
        else if ((touchPos.y > 0.5) && (touchPos.y <= 1.0)) llSay(0, "Button 2 pressed!");
    else llSay(0, "That side doesn't have any buttons!");
}

The x/y/z would be as a percentage to reflect changes in size/shape as you say.
But yeah, there's not really any need to have a new vector type (five values) just to accomodate this, that and float values aren't great for handling integer values, though I suppose you can round or cast it in order to be sure, but it seems wasteful.

Note: Z% is included to llDetectedTouch() for things like spheres, where the side isn't very uniform so it's going to be hard to work out where it was touched. The alternative to this is to have the values refer to the position on the TEXTURE that the user touched, so if it tiles once and you know it is divided in half, you're fine. If it repeats twice then you'll have to consider values such as x=1.5000 as "tile 2, half way across"

Yeah, one thing about this: in pretty much every touch-vector application I can think of, it would be primarily done on a relatively flat-panel surface. Concepts that immediately come to mind are "books" with sub-articles, event menus, cockpit buttons. Pretty much all of those would be pretty easy to lay out.

Of course, along with this feature might be a very nice in-game panel which would tell us WHERE we touch an item so we could plug those figures right into code. But considering that we don't even have a "color selector" tool, I don't see this being implemented by LL any time soon. It would rock and imo would be MUCH more valuable than a "floppy prim" because it would increase functionality to the whole system and significantly reduce prim usage. But alas..