Is implementing sliders realistic/possible?

Hi

I notice that most control panels and huds seem to be push button or, in covering ranges, with increment and decrement buttons to be clicked repeatedly.

I was trying to figure out how to implement a slider on a control panel that would update as it was moved on a remote prim....smoothly updating the z scale of the prim say, or the color, or really any value that varies over a range. Is it possible to do this? The initial problems I am having at the moment (no doubt there will be others) are how to get the updates running as the slider moves (it would ideally be moved by mouse....but obviously needs something or than moving_start() and moving_end().

Another problem is how to lock the movement in a given direction...obviously you only want a slider to move in one direction when the user is holding it.

Once this stuff shows up, it might be a lot easier: /54/ab/271505/1.html

Until then, yes it is somewhat doable using llDetectedGrab(), but note that the behavior is a little bit screwy (and you'll probably have to mess with the sensitivity quite a bit too). See http://www.lslwiki.net/lslwiki/wakka.php?wakka=llDetectedGrab

Hi.

Thanks for that. Yeah, I was trying to figure out the detectedGrab(), but the documentation on it seems cryptic, and I am not really sure what it is doing. It says the direction in which an object is being dragged, but when I have this in a touch event, do they actually mean moving the object (prim)? I can get llSay to output the vector when I drag the mouse (which is not really what I had in mind for a slider mind you..I was hoping for a moving prim..the prim doesn't move), but the figures seem odd and the Z coord is always 0.0000. What's that about?

Hmm. I can't tell you much more without fiddling with it again myself, but I can tell you that I WAS successful in building a HUD color picker at one point. I think I even accounted for the camera orientation or something. I'd really have to do some digging and find it in my cluttered inventory. But in any case you'll want to move the prim to match what you get back from the function I believe. It might still be a tiny bit hokey/cumbersome when you are done; I got so far as to make it somewhat usable as a proof of concept, then decided I could probably optimize its usability if ever I found the need to actually put the thing to use and left it at that (yet one more almost-finished project ).

I'm just not sure I'm getting what llDetectedGrab() is meant to be doing. Are you meant to be able to move an object with this (eg a slider) or just drag a mouse point.

When I try setting the prim's position to llDetectedGrab() on a for loop, it jumps about 20 m away and downwards repeatedly and ends up underground.

I believe it gives an offset rather than an absolute location, and probably has to be multiplied by some scale factor in order to be very usable.

Increment / Decrement buttons have to be clicked repeatedly because the coders are using touch_start() opposed to touch(). I've (rarely) seen sliders that can be slide on one click (and hold) using the touch event. Technically, I don't see why it couldn't be done right now just using the touch() event instead of touch_start(). It would be sluggish to maintain resolution, but it can be done as is right now I'm sure.


http://www.secondscripter.com