Touch position already known, please expose it

eltee, I hear you, but do me a favour, and actually TRY the 'Ctrl-3 and click on a large, flat prim'... it really does know where you're clicking. Do it with a friend too. Cross the beams! lol

As far as returning the detected touched surface - simply steal the code from the 'Select Texture' code and return a face number. Even works ALREADY on those poor tortured prims.

Not rocket science, these are quick wins.

- Timeless

Of course it know the location, when hold Alt down and click on an object the camera centers on where you click (a vector pos).

I would like to ammend my command request.
vector llDetectedTouchPos(integer number)
integer llDetectedTouchFace(integer number)

llDetectedTouchPos would return a local vector (it's easer to work with a local vector then it is a global vector, as with distance there is precision loss with the floats that make up the vector.) I don't think many will want it in global pos.
llDetectedTouchFace would return the integer number of the face touched.

you already know which prim was touched by llDetectedLinkNumber

I approve.

This is such a desirable pair of functions. Ever since I tried SL for the first time I felt it was lacking this. If it's that obvious to a newb you know it's fundamental. Major major desire for these two functions. I mean all those poor people using up all their prims for a single 104 keyboard, lol.

Think of the server resources and bandwidth we could TAKE BACK by reducing prims everywhere! It would also reduce the number of scripts used. eg. a 4 prim vendor (photo + left + info + right) with a script in each prim becomes 2 prim (photo + button bar) with a single script. Even the number of textures gets reduced. It would be madness to ignore this.

- Timeless

Not a normalized solution.

Wouldn't you rather have llDetectedTouchPos and a second function that converts an arbitrary prim ID and a vector to a face number on the prim? Then you could use the function with other vectors without touching the object, for example to find out which face of a prim was facing up (as was requested a couple of days ago).

I would be very happy with an llDetectedTouchFace
It would enable us to make XyText screens truly interactive.

you don't often need to know which face is down. More over i beleive the solutions given for the facing up problem were not the best solutions (was to tired to crunch the math). Most importantly llDetectedTouchPos & llDetectedTouchFace would be the easiest to implement, as when you edit a texture the client knows which face you clicked on. So the client already has the data at hand, it just needs to send that off to the sim when it send off the touch event (the mouse click). But a function like you describe would require the sim to duplicate the math the client has already done. And honestly i don't know of many situations where you want to know which face is up outside of craps.



And we could build true 1 prim venders.

It would seriously inhibit us if we only had the one function. We really really do need the touchPos one. If we only get touchFace well I'd be very disappointed.

- Timeless

I want the function to return the local offset of the clickpoint:

vector llDetectedTouchPos( integer num );

So that if I have a default 0.5 meter cube with zero rotation at 100,100,100 in the sim:

vector pos = llDetectedTouchPos( 0 );
llWhisper( 0, "You clicked me at " + (string)pos + " from my center." );
llWhisper( 0, "You clicked me at " + (string)(pos + llGetPos()) + " in the sim." );

would return, if you clicked the center of the top face...

You clicked me at <0,0,0.5> from my center.
You clicked me at <100,100,100.5> in the sim.

To account for the object being rotated:

vector pos = llDetectedTouchPos( 0 );
llWhisper( 0, "You clicked me at " + (string)pos + " from my center." );
vector global_pos = (pos * llGetRot()) + llGetPos();
llWhisper( 0, "You clicked me at " + (string)global_pos + " in the sim." );

You could make a script that could detect which of the four corners of the top face of a cube was clicked:

vector pos = llDetectedTouchPos( 0 );
if ( pos.z = 0.5 ) // top face was clicked - or replace with llDetectedFace()
{
    if ( ( pos.x < 0 ) && ( pos.y < 0 ) )
        llWhisper( 0, "You touched corner #1." );
    else if ( ( pos.x < 0 ) && ( pos.y > 0 ) )
        llWhisper( 0, "You touched corner #2." );
    else if ( ( pos.x > 0 ) && ( pos.y < 0 ) )
        llWhisper( 0, "You touched corner #3." );
    else if ( ( pos.x > 0 ) && ( pos.y > 0 ) )
        llWhisper( 0, "You touched corner #4." );
}

Or you could make a sphere that projects a particle stream from it's center towards the point that was last touched on its surface. The possibilities are endless.

But a...

integer llDetectedTouchFace( integer num )

function would also be good for simpler scripts that don't need to know where on a face they were touched. You could then make a one-prim multi-object vendor out of a flattened cube 3 times as long as it is wide with a topsize on its long axis of 0.3, the image of the obejcts for sale shown on the top face (center) and the two opposide side faces ( on the left and right) are arrow-like textures you can click to change the image.

Yeah, nice isn't it?

Please Lindens can we have it?

- Timeless

Ahh, sweet, cool, yes, ditto, bump!

bumping this again

This is an excellent suggestion and deserves a bump.

I've also addressed the operation of llDetectedTouchPos(n) within my Mousebutton API. At the target, this would work exactly as in standard touch events, but there are interesting new semantics back at the originator.

In a nutshell, local coordinates as suggested here make a lot of sense, whether they be relative to the center of the touched prim or relative to the CoG of a composite object.

In contrast, back at the reflected mouse_touch_originator() event, local coordinates for the touch would make very little sense. To be useful, the originator needs to be returned global coordinates for the touched target point, or possibly a vector to that point with its origin at the toucher's hand. (Having a fixed touch effector point is rather poor too, we need to be able to rebind it dynamically, eg. to one's head or foot for many ball sports.)

Perhaps I should propose a separate llDetectedTouchPosOrigin(n) function for use back at the reflected originator event? The function proposed by Timeless would then return the same local vector both at the target and in the originator.

This is a great suggestion of Timeless's, and very nicely honed by others. Keep it up! Everything you do here applies to the extended Mousebutton API. I'm trying to take SL interactivity far beyond what I've seen in other 3D environments, and precise targetting is very important for that.

*Stamped as a good idea*

More importantly, llDetectedTouchPos() is a quick win. Unlike some of the other cool things I can dream up.

As I bump this again, a little head scratching ...

I find quite perplexing the occasional, seemingly random appearances of devs on the forums. The forum-related strategies that make some kind of sense to me are, perhaps:

1. Total dev absence, maybe because of a company directive to not engage the customers here, either because forum browsing wastes dev time, or because commenting on suggestions might indicate LL acceptance, or because Cory runs a strict ship and nothing else is allowed to affect direction, or even because the forums are regarded as totally boring and we are not worthy.

1. Regular dev presence, not necessarily meaning regular posting, but certainly regular enough to be able to pick up the very easy wins like llDetectedTouchPos(), and actually state "Good idea guys, I'll add this to the customer-request list, but no guarantees of course." It would save us a lot of followup effort and frustration, and of course it would save LL more browsing effort, which the "regular dev presence" interpretation assumes anyway.

1. Bug-fix and newbie-help only presence, ie. only the bug hunters and direct front-line staff browse the forums looking for bug reports or newbies in trouble. This is a common strategy in ISPs in their forums and newgroups.

1. Official Customer Relations staffer presence only, everything goes through him so no devs (nor anyone else from the company) ever appears on the forums, but it does have the benefit that absolutely everything gets browsed as that's his job. I've seen that work semi-reasonably in one MMOG, although it has the downside that the official becomes incredibly powerful and his personal preferences skew everything.

1. There is an official internal LL directive that the forums are purely for allowing customers to let off steam and so to relieve their frustrations while continuing to pay the subscription.

Clearly none of the first four operate on their own here, and the last one is both uncharitable and lacking in vision so I'm striking that one off, which makes the role of a forum like this one particularly confusing.

Maybe F.S. should be renamed Forum Suggestions Randomly Read And Randomly Considered by Random People on Random Days?

Very odd.

Edit: In hindsight, I should have posted this as a thread. Extremely unlikely to attract an official response, I know, but who can tell, seeing as it's random.

Edit 2: Going to repost it. You never know ...

Why do you even expect LL to have a position?
They are people. Their position is seated and coding. They come here if and when they can be arsed. They know very well where to take their company without the aid of back-seat coders. They do browse these forums, it's just that 30,000 people can come up with suggestions much faster than 10 or so coders can implement them.
They are deep in debugging mode now... because WE asked for it. ANY new feature we suggest is going to the very end of the priority queue, regardless of whether or not it's the greatest thing since sliced bread. Any smallish feature you suggest will probably have less priority than the massive overhauls they have been wanting to do for the past year or so, such as the new permissions system, for instance.

I assume that's a joke, since otherwise it would be insulting to the devs to suggest that they are pure slaves. Also, it's untrue, since occasionally they do appear here, but randomly.

So you're saying that they do have a position, and that is to treat the back-seat coders as irrelevant, or even with disdain? That may be so, but a lot of people spend much time on carefully thought out feature suggestions, like Timeless and others did in this thread, so it would be an uncharitable view of LL to think that they consciously couldn't care less, and only look "when they can be arsed".

I didn't refer to implementing suggestions at all. My query was about forum presence alone, and letting people know when an item in Feature Suggestions was noted as sensible and a possible candidate, with ZERO guarantees. That requires no implementation resource, and the speed of implementation versus the speed of suggestions appearing is then irrelevant.

They're in bug-fixing mode right now, but the question was generic, not specific to this point in time.

We can only speculate.

LL staff are not allowed to show favoritism (for obvious reasons). There are too many people to deal with at the same time. Answering individual forum posts will not scale well when SL takes over the planet if they did it like that anyway.

Our saving grace is that if the appointed forum snoops find any ideas worth using we will be pleasantly surprised when it comes. Similar to syncronicity in fact.

In any ecosystem, organisms adapt or die (as an entire species).

If the environment conditions become too extreme the entire ecosystem dies. I'm quite sure that whilst LL staff like making money and having fun with SL they will try not to have such an extremely undesirable environment.

So far, they've done well.

A reflection on the SL monoculture?

Well, Philip is clearly trying to diversify away from what is almost entirely a creative world. It could happen.

Oddly enough, while other things are much more important, I'd like to see some simple diversity in geography. We have effectively just 3 landscape types, grass, rock and snow, and 3 geological types, island, flatland, and occasional mountain. While that's not a problem in itself, every pair of landscape and geology is identical everywhere!!! The terrain generator badly needs some more parameters ... it's just plain boring.

In a creative world, that doesn't really matter too much, but since Philip wants to compete with MMOGs and FPSs which are full of eye candy, they're going to have to put more effort into giving zones some real environmental character and uniqueness.

See, we only participate in hijacks.

Yes, better enviromental effects is something that would be very cool, but the simple "heightmap" is fairly flexible, and very easy to stream. As we have been saying, first priority right now is to get the system fast and stable, then we can start adding candy again. In the meantime, we will see about adding more parameters to Xenon.

And I also agree that sometimes it would be nice to get that touch position

ben

You tease, you.

Don't worry, Bush has no real intention of stopping you, that would impact on arms sales.

Get those extra dev staffers first Ben, to oversee open-sourced subprojects like Philip mentioned, and farm out the LSL compiler and other independent bits to the community.

Then there would be no need for a features slowdown while your guys are busy making the SL core a bug-free zone.

In addition to oversight staff, it would need two isolated test sims joined in a mini-grid to allow border crossing and teleports to be tested as well, but any old boxes will do for that.

By the way, two adjacent sims is not a valid enough test. You need three or four cornered with eachother. Then traverse them rapidly. Bet it doesn't cope. One handover is still completing whilst it starts another, and another.

Very good point. Darned corners.

Interestingly, the four FOSS dev test sims could be running entirely different versions of code until the point where a global change needs to be merged in, so allowing progress on four different fronts at the same time.

That could be pretty interesting.

For isolation, the test database ought to live on a fifth old server within the test cluster, but at a pinch it could be run on one of the four sim boxes I'd imagine. The one that changes least.