Touch position already known, please expose it

Hi

Rez a cube, size it so that the height and width are big, but depth small. Now 'Ctrl 3' and click in various places on the large surface area.

Note how the particles go to exactly where you click on the prim? Click around some more and see.

SL: please can that target touch/click vector be available to us through a new function, say:
vector llDetectedTouch(integer num_detected)

... returns the offset to the touched prim's position (we need offset and not absolute position in case the object is moving).

What we can do with this?

Using touch_start and touch_end and the new function we can tell where people touch on a single prim. Useful for single prim control panels, virtual keyboards etc etc.

I already know how to use llDetectedGrab(), but that only returns offsets during a drag, but not in the touch_start nor touch_end events. This is not what I need.

Thanks for your time. This is my first suggestion in the forums, so I have no idea how well ideas are received in SL.

- Timeless Prototype

it's a very good suggestion too. stamp stamp stamp

agreed

Particles are a client side effect. I'll venture a guess that the touch particles go to wherever your mouse cursor was, and are not necessarily related to any part of the primitive.

That's a thought that crossed my mind, but then I noticed two things...

1. The particles go smaller, which means there is a sense of 3D space happening.
2. The avie arm moves to point to it. (all people see it so it must be transmitted to the server too).

- Timeless Prototype

I'm cool with the suggestion of something like
vector llDetectedTouchPos()
integer llDetectedTouchFace()

where the vector is in global cords. [edit: mind changed about global cords, should be local]

Best way to test if this is really happening is grab a volunteer, have them edit different parts of the prim, and see if you can see it happening.

Not to mention we can figure out where one clicks (in mouselook only) in LSL as is, but it requires a lot of trickery that would be faster and more streamlined by a direct call. But end result, if it can be done in LSL now, it can be done better by a direct function.

Yeah, confirmed this before posting the first post of this thread. I could see where they were clicking whilst in 'Ctrl 3'.

However, a normal Touch click - the particles go to the centre of the prim. Guess they will need to copy/paste some code after all.

Ok, it's fun discussing it, but at what point does SL staff say anything about it? Otherwise I get the feeling these efforts are a waste of my time (read: will not post here again).

- Timeless Prototype

The point IS known in the code. A click into the world casts a line out from your camera and nearby objects are checked to see if they intersect. The intersection point is what you want.

This feature would be a HUGE boon, allowing complex control boards to be created out of a single prim with a texture, among many other uses.

I'm for it...

Me too! I had a project that I would have preferred to use one or two prims, instead, it became 40 to make up for it...

Yes! Please give!!

maybe instead of making a whole new event handler for the touch, just have

llDetectedActionPos() inside of the touch_* event handler?

Yes, that's exactly what I'm saying.

- Timeless

OK, I see an example would speak a thousand words...

// Example code to show the use of the new function:
// vector llDetectedTouch(integer num_detected, integer local)
// returns offset to this prim that was touched. If the local
// parameter is TRUE it gets the local offset (with prim rotation
// applied), otherwise if FALSE returns global coordinates offset
// (zero rotation).

// by Timeless Prototype (newb scripter, but a RL programmer)
// 2004-10-19

default
{
	state_entry()
	{
	}
	touch_end(integer num_detected)
	{
		integer i;
		vector touchPos;
		
		for (i = 0; i < num_detected; i++)
		{
			// Here we get the LOCAL offset of this prim of the touch (ie. local rotation applied).
			// Using FALSE would return the GLOBAL offset from this prim.
			// Offset rather than global coordinates allows us to deal with moving objects accurately.
			touchPos = llDetectedTouch(i, TRUE);
			
			if (touchPos.x > 0.0)
			{
				llWhisper(0, "You touched the first half of me.");
			}
			else
			{
				llWhisper(0, "You touched the second half of me.");
			}
		}
	}
}

- Timeless

Additional behaviour...

When the root prim has the script for the touch events other prims in the linked set become touchable. If other prims in this set are touched, the offset to the prim with the script in (this case the root prim) is returned and NOT the offset to the prim we touched.

- Timeless

With this feature we will have some control over which way a ball goes, depending where the click hits it.

One last little piece, then: in the touch_end event, let us know the number of milliseconds that the mouse button was down. Now we can control how hard we kick it as well.

Well, arguably you could set a global variable on touch_start() with the current time and when touch_end() happens you can compare the times. Bear in mind that the touch event can happen with multiple people touching. So perhaps in your case you'd need to manage a list of times per avie key.

I don't think we need to add that to the function though.

- Timeless

And what kind of resolution / repeatability would you get?

My guess is that it would be pretty much like adding a random number up to a half a second to the actual value.

This would actually make it easier to implement one of those side-show carnival roll-the-(bumpy)-ball into the slot and win a prize kind of games; but it would make it harder to build a game that people could actually get good at by practicing.

Timing will be affected by current simulator load, network bandwidth and network latency. Sorry.

- Timeless

Yes, but not if the duration of the click is captured in the client and sent along with the mouse up event. Getting this number by taking the difference in arrival times of two events is not a good solution.

I like the idea. Hopefully we get both functions given to us.

Are the Lindens reading this thread?

- Timeless

Sounds good to me, but Ide also like to have cords relative to the prims center without having to use a round about way of doing it.
perhaps simply adding an option to it like this,
vector llDetectedTouchPos(TRUE) -- or FALSE for local cords or not.

or! even,
vector llDetectedTouchPos(integer linknum, integer side, integer local)

I dont know if a script in one prim would be able to detect the touch in another child, but it would be an added bonus. "think rubix cube". one script to do it all.
"and by that I mean setting link textures, and would also require llSetLinkTexture()
But for now llSetLinkColor would do fine."




^ I like this even better, but still with the added features I said above.
so... llDetectedActionPos(integer linknum, integer side, integer local)
so you could even do something like this.



I know that code would give almost impossable odds, I ment it only as a simplistic illastration of an idea.

this is significantly more complex than people think it would be. One major problem would be cut/prim parammed prims. It seems trivial enough to get an x/y on a single face of a cube to be sure, twisted torii... im not even sure what exactly would represent the area touched, or how it would help anyone.

*generally* the way most openGL applications handle it is to consider the top most triangle that was under the mouse cursor as the thing that was 'touched'. Past that location is generally a simple viewer mouse cursor thing. The chances of gettin much more granularity than which *face* was touched are very very slim. On the other hand there probably is alot that could be done with even that limited info so thats probably not an unreasonable thing to ask for.

llTouchedFace() which returns the integer designator for the face that actually got the mouse click

The complex way would be to try and return an x,y point on a face of the object. Best you can do there is eltee's llGetDetectedFace() function.

The easy way would be to return the x,y,z point in space in either coordinates global to the region (sim) or local to the object as an offset from the root prim's position as I believe Timeless is suggesting.

I actually prefer the easy solution. However, throwing in the detected face would be all the better.

Its been a little while since i've played with it, but i believe openGL selection pretty much jus picks a 'triangle', rather than aribtrary world coordinates of the click.. you could attempt to calculate and use the center of that triangle as the positionf the click sure, the problem would be some sides of a cube only have two triangles... hence what i was saying before where the simplest solution would actually be to just return the side that was clicked. Anything past that may very well be asking the impossible, or at least asking something that would vastly complicate the already rather complex process of 'clicking' in 3D, to the point it may produce noticable client slowdown.


this is one'f the reasons you don't really see 'live' grafiti in games, where someone could spray objects with a photoshop like paint system. It would be a great feature, but implementing it within the technology we have now, (openGL/directx9) would be amazingly complicated specifically because its so difficult to determine exactly what is underneath the mouse cursor to a finer granularity than individual polygons