Some useful things for mouselook

1: AGENT_MOUSELOOK bitmask for llGetAgentInfo().
2: Ability to click on items while in mouselook. It does not appear possible to do this now.
3: llDetectedTouchFace() and llDetectedTouchOffset(). This would make GUIs a lot easier to design, especially for vehicles, where having a lot of prims in a GUI is usually not an option.

I support this totaly. Except for llDetectedTouchOffset().

what would be the llDetectedTouchOffset for a twisted, sheared, cut, and topsized face?

I see no reason for why llDetectedFace couldn't exist. We can edit faces of prims so why not detect which one has been touched? It would improve scripting while adding no downsides. It would reduce the number of prims used and the number of script used; which would reduce load on servers (a tiny bit). (we shouldn't limit it to just touch's, as collisions would also be interesting)

I wrote up a General Mousebutton API definition as a feature suggestion recently, which supports what you requested above.

The touch-originator callback event mouse_touch_originator() would allow you to click things in Mouselook mode and trigger whatever you like on your avatar, by having one of your attachments listen for the event. Since there is already some hand-cursor functionality within Mouselook in the existing client, this would probably be pretty easy for them to implement.

I've purposely made the data returned back in the bitmask mouseButtons event parameter reflect the up/down state of all the buttons, rather than just the buttons that triggered the event. This gives the touch originator (but not the target) even more flexibility in deciding what to do when this touch-back event is received.

The generality makes the sky the limit: for example, you could put on a bracelet that would give you Mouselook-on-demand by right-click-and-holddown of the right mousebutton, during which holding down the middle button produces forward movement in whatever direction Mouselook is pointing. Movement stops on releasing middle, and you revert to 3rd person mode on releasing right.

Anyone that's played any of the popular levelling MMOGs like EverQuest or Anarchy Online will recognize that instantly as the 3D dogfight mode, which allows arbitrary travel in 3D space using the mouse hand alone. It's extremely powerful, and would make team sports rapid and highly interactive.

Notice that, if you're dextrous enough, with this you could jump up in Mouselook, rotate yourself around while rising upwards until you see the volleyball, and slam it down over the net with a left-click. I hope you have good motor skills. )

Take a piece of paper and fold it into a paper airplane, or crumple it into a ball, or whatever. Mark it somewhere with a pencil. Unfold or uncrumple it and lay it flat, and the pencil-mark will exist at exactly one <x,y> coordinate on the paper.

The face of a prim is the same thing - a 2-D plane that may have been distorted, but which still has only one possible <x,y> coordinate for any location on itself. This function would simply return the coordinates on that plane. It is mathematically possible, as evidenced by the fact that even though an object may be cut and sheared and twisted, it can still be predictably texturemapped.

Uhh, I dont know about the "predictably" part

If you have two prims that are identical, and you put the same texture on them, it'll show up the same. Anyway, it seems to me that this is all a bunch of nitpicking. Who is going to try to use something like this on a distorted prim? It's useful for GUI type stuff primarily.

For sanity in programming, the value returned from any llDetectedTouchOffset() would have to have a reasonably simple semantic (and not just a predictable one) at the LSL interface, even if it's a visually diabolically complex one after the geometry transformations.

The concept of a per-numbered-side local touch offset denoting the same location on the side as a local offset into normalized texture space is a pretty clear one, manageable. Whether it would be useful after complex transformations is debateable, but there's no doubt whatsoever that it would be supremely useful in the common cases.

Incidentally, what is the largely non-functional white-hand pointer that's activated by Alt in Mouselook actually intended for? And why does the darn thing keep returning to center-screen on click?

It almost suggests that someone in LL had the very sensible idea of allowing the normal pointer actions to be performed from within Mouselook. But I guess it was too sensible so they fired him before it became usable. Oh well.

oh just to throw a monkey in the system... what would be the offset for a sphere? how about a cut sphere? A twisted cut sphere?

A twisted, cut, hollowed, (hollow shape square at 95%), tapered, torus,

The reason i bring it up is that the math scares me. I only know a few people i trust to do the math properly. The posability for a client crash is huge (do to a devide by zero).


besides scripting i specialize in making prims that wow and amaze. I'll post some screenshots of my newest batch.

We have this situation already, inasmuch as prims vanish with a message about illegality if you mess around with them too much using those transformations.

It's not too hard to prevalidate operations that have the potential to generate fatal client exceptions. As always, whether that gets done properly or not depends on the competence of the individual software engineers and the quality of the team's development process, which includes review and testing.

For a profession that's based on the very precise mathematics of Computer Science, normal program development is an utterly unscientific mess, but we seem to get by somehow. If bridges were built this way though, most of us would prefer to swim across.

It is trivial to write a "safediv" function.

Actually, at one point, SL was entirely first-person. You could use the editor tools and everything.

OMG. This is progress?

I want the <x,y,z> of the touch point. One function instead of two, easy to explain. It might take a little more math, but there's no getting away from the math in SL..

Polar? Not sure.

Anyway, it would be the equivalent of a coordinate within a texture that is set to fill the face one time.