Touch Coordinates

From Second Life Wiki
Jump to navigation Jump to search

Feature Request: Get Touch Coordinates

Please use the talk page to discuss this Feature Request.

Proposal A

Implement the following command:

 list [float x, float y, integer side, integer link_number] = llDetectedSideCoordinates(integer num_detected);

This function returns the side x and y coordinates from within a touch event.

Goal:

The goal is to get more detailed feedback about where exactly an object was touched. It will return the prim number within the linkset, the side on that prim and the coordinates (x,y) where on that side it was touched.

This will greatly help HUDs and other Panels to implement a user interface without using additional prims as buttons. You could make 10 switches as texture, put them on one single prim and then use the llDetectedTextureCoordinates function to find out which button was pressed.

How to implement:

  • Add support for the llDetectedSideCoordinates LSL-command for the server and client.
  • Change handling of client touching things so it is possible for the server to find out where the object was touched.
  • To support scaling of the object, the x and y coordinates will be a float ranging from 0.0 to 1.0 and will be a relative value independant of real prim dimensions. So, x=0.5 and y=0.5 will mean the exact center of that side.

Requested by: User:Fairlight Lake

Pros:

  • greatly improve User Experience with HUDs
  • reduce the number of used prims on operator panels and other objects that heavily rely on touch events to do different tasks

Cons:

  • eventually slightly more overhead on touch event notification from client to server

Open questions:

  • I am not sure if issues would arise with slanted sides.

Proposal B

Same as Proposal A but with changes to the implementation.

Implement the following command:

 vector <float x, float y, integer side> = llDetectedSideCoordinates(integer num_detected);

How to implement:

  • Add support for the llDetectedSideCoordinates LSL-command for the server and client.
  • Change handling of client touching things so it is possible for the server to find out where the object was touched.
  • To support scaling of the object, the x and y coordinates will be relative to the textures scale. The UV offset will effect the values.


Example:

Texture

_____
__A__
_____
Textured face with repeats of (4,4) and offset of (0,0)
0 1 2 3
0 _____
__A__
_____
_____
__A__
_____
_____
__A__
_____
_____
__A__
_____
1 _____
__A__
_____
_____
__A__
_____
_____
__A__
_____
_____
__A__
_____
2 _____
__A__
_____
_____
__A__
_____
_____
__A__
_____
_____
__A__
_____
3 _____
__A__
_____
_____
__A__
_____
_____
__A__
_____
_____
__A__
_____

If the letter A were pressed in col-row marked (2,2) then the x and y of the return of llDetectedSideCoordinates be 2.5, 2.5 respectively.

Textured face with repeats of (4,4) and offset of (-1,-1)
-1 0 1 2
-1 _____
__A__
_____
_____
__A__
_____
_____
__A__
_____
_____
__A__
_____
0 _____
__A__
_____
_____
__A__
_____
_____
__A__
_____
_____
__A__
_____
1 _____
__A__
_____
_____
__A__
_____
_____
__A__
_____
_____
__A__
_____
2 _____
__A__
_____
_____
__A__
_____
_____
__A__
_____
_____
__A__
_____

If the letter A were pressed in col-row marked (-1,-1) then the x and y of the return of llDetectedSideCoordinates be -0.5, -0.5 respectively.

Modification by: Strife Onizuka

Pros: It allows for the user to know not only where on the texture it was touched but which tile was touched. Since touch locations are expressed in texture coordinates, scaling of the object has no effect on the script.

Cons: The programmer has to be aware of this feature when writing their interface.