Difference between revisions of "Touch Coordinates"
m (→Proposal B) |
|||
Line 135: | Line 135: | ||
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. | 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 | '''Modification by:''' [[User:Strife Onizuka|Strife Onizuka]] | ||
'''Pros:''' | '''Pros:''' |
Revision as of 22:36, 22 March 2008
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__ _____ |
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. |
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.