reducing prims / determining where user hit object

Hi,

my problem is that i created an object where the user is supposed to select 4 out of 40 numbers. Currently i solved this by having 40 prims, each with the same script informing a motherscript on the touch event.

But with todays shortage in aviable prims i think this is an rather bad solution. I once was told month ago there is a way to determine which area of an object the user hit, therefore it "should" be possible to reduce the number of prims greatly.

I tried alot of the aviable commands but i failed. Does anyone know how to archieve that? I searched around within the world and saw that most objects use "great" amount of prims, so its maybe not really possible..

Thanks for your time,
Felix McCoy

not possible for touch events.

but what you could do is have a pointer and have people move it to select numbers. Xylor made ages ago a color selector that uses a similar method to work. You should be able to find it in Gray around 20,50 but i could be wrong for the actual location (pretty sure that it's still in Gray)

The easiest is probably to have them give a verbal command: "pick 23 34 45 56"

If you don't want other people around them hearing it, they can say it on a different channel: "/123 pick 23 34 45 56"

(Not that clicking things can be observed, unlike channeled text.)

If you must have a clicker, then just have 10 buttons (0-9) and have them type out the sequences they want.

I also have a slider that can be done with as little as one prim. No slider is wonderful to use, however, for people with slow machines or a laggy connection/sim.

You can detect where the mouse click was done in mouselook via calculating the AV's position and rotation and the objects.

Have you actually done this, or is this theory?

It may be hard to figure out what exactly a client is looking at.
There are two obstacles as I see:
- I've noticed their are some discrepencies between where an avatar is facing, and what they're actually looking at. This discrepency is usually pretty minor (visually speaking) but may present an obstacle when you want to use the user's rotation as a presice reference. (Of course, this may be entirely a client-side rendeirng artifact)
- When you're in mouselook mode, you're actually looking through your avatar's eyes. To the great frustration of scripters everywhere, there's no way to figure out where someone's eyes are, relative to their position. So it's very easy to be off in the vertical up/down component when calculating the av-direction/object intersection point.