Draggable HUD elements

Currently, mouse-dragging on objects and the llDetectedGrab function seem to be designed with only in-world objects in mind. I tried using these to create a draggable HUD element (a child prim that would repeatedly llSetPos based on llDetectedGrab values), and while I was able to get it to respond to mouse-dragging, the values were totally wrong. It soon became clear to me that llDetectedGrab was treating my actions as if I was dragging on an in-world object (through world coordinates) rather than a HUD object (through HUD coordinates).

In addition, my mouse cursor would always disappear during a HUD drag and, upon release, reappear at my av's origin. If I moved the mouse to the left or right, my view would start to rotate around my avatar. It seems as if the avatar mouse-drive behavior is activated if you try to drag on a touch-enabled HUD prim (which doesn't work correctly anyway, since the HUD isn't even in world-coordinate space).

Any chance HUD-dragging could get implemented correctly sometime in the not-too-distant-future? I'd love to start seeing sliders, knobs, and whatnot start appearing in HUDs.

I see where you're going with this and I agree in general, but I can't help but feel that a HUD is a 2D object and that LL really needs to deliver a 2D interface at some point.

It seems like we're jumping through hoops to make 2D GUI interfaces work in a 3D Havok environment.

I'm really just interested in the discussion. I don't have any clear thoughts.

This kind of HUD dragging will be needed if people want HUD attached browser windows when the uBrowser hits SL.

Has anyone had success with these things in world either? I tried making a slider thing but it didn't work at all well. Being able to constrain the motion of an object that is being grabbed would do it.

You should divide by llGetRot(). It also returns a vector size that isn't very appropriate so you need llVecNorm too. To make it smooth, you may have to use more than one script.

Zepp, are you responding to Seifert's post? I don't think that's the issue he's having. Sounds like he has it working except for constraints.

Seifert, did you use llDetectedGrab and llSetPos for your slider? You should be able to create constraints by clipping the values sent to llSetPos.

To constrain the motion a simple ifelse check should do. I've found this script to be useful as a basis for knobs. I've tried making knobs with llRotLookAt too, but seems like that doesn't work on attachments even though it works for normal nonphys prims.

Yeah I mean it works, as in the user drags the slider prim up, then it jumps as setpos projects the new position to what my constraints say it should be. It doesn't feel like a slider should feel though, because the constraints are implemented by jerking back to the line rather than the movement only being in that direction.

I wasn't using llDetectedGrab - it wasn't giving me any information (this may have been because I needed to set physics or something), and even if it did, what I need to know is if it moves and where it is, and moving_start() is enough for that.

Drag it up via the building tools?



Until recently, llDetectedGrab didn't work without physics, except for a hack with linking to a physical prim. It does work on nonphysical prims now however. What I've done on some HUDs is use vector grab = llVecNorm(llDetectedGrab(0) / llGetRot()) and then do a few ifelse checks to constrain the motion, it works for sliders and knobs but has all the common problems of making nonphysical motion look good.

Yes, that would work, and I've done projects for which the control mechanism uses the build tools (rotating an arrow object for aiming). For a slider on, say, an elevator control, one would want it to be as intuitive as possible to use. Going to building tools isn't intuitive enough for my purpose.

Currently buttons to push are intuitive enough for someone with no experience of the object to come along and work it. Unfortunately they're too primmy at the moment.

llDetectedGrab returns the direction something is being pulled in right? I can't see how this information alone is useful beyond a binary switch thing, or something you can slide, but only one notch at a time?

Ah, I see what you were saying earlier now. So you actually got sliders, etc. to work on a HUD? When I was messing around with it, it seemed like the behavior changed based on the camera angle, but maybe it was just the direction the avatar was facing...

Heh. I just checked llDetectedGrab on the Wiki again and noticed something at the bottom that I'd missed before. Apparently, it is affected by camera angle. So your method will work when the camera is at its default position behind the avatar, but will malfunction if the user moves their camera around.

Yeah, kinda. If I only check for movement in one direction at once it does return some usable values. Sometimes, but not always, when I start dragging the first value I get is just weird, while the rest are fine. I think I may have seen a solution to that problem once in the forums, but some Linden have destroyed forum search(i.e. disabled searching for functions, like lldetectedgrab) so I can't find it anymore. Anyway a slider or knob that checks for grab in the y direction works. I hadn't tried moving the camera up and down while wearing it before, but doing that I noticed it stops working. Maybe it would be possible to make that work better with llGetCameraRot somehow. It still works when I move around though. But as you said earlier, it will turn the avatar around.

I was wondering about that myself.

If you put it in the event touch(integer tn) it will continously return the direction it is being dragged.

This for example rotates a cylinder on the ground.

default {
state_entry() {   
        llSetStatus(STATUS_BLOCK_GRAB, TRUE);
    }
    
    touch(integer num) {
        vector grab = llDetectedGrab(0);
        if(grab.x < 0) {
            llRotLookAt(llEuler2Rot(<0,0,PI / 10.0>) * llGetRot(),0.3,0.3);
        } else if(grab.x > 0) {
            llRotLookAt(llEuler2Rot(<0,0,-PI / 10.0>) * llGetRot(),0.3,0.3);
        }
    }
} 

Wow, that's really cool. I hadn't realised that you could get information about the direction of the "drag" when you don't actually drag it.

It's a shame that it doesn't know if you're pulling the top or bottom of the "knob", or from which direction you're looking at it. Maybe covering up half of the knob could make that intuitive.

Hmm... this gives me an idea...

(Edit: the delay on llOffsetTexture kills that idea...)

It can know what direction you're looking at it, that's what llGetCameraPos and llGetCameraRot are for.

Ah, yes. What we can't get at is what bit of the prim the user grabbed. I guess it shouldn't be too hard to design around that issue.