Discussion and alert!!

This definitely the place for this post. I also posted a gripe in the Hotline forum.

In the 1.7 release notes they have, as a BUG FIX!!!, the following line:

* Touch events no longer make objects draggable by owner


....
....
.......!!??!???!?? WHAT?????

How was that a bug?? In fact, in my initiation, I remember a beach ball on a table that more or less tauted this as a FEATURE! Apparently too many people couldn't figure out how to use STATUS_BLOCK_GRAB. Great! Now all my handles on my UI interface controls in my applications are broken. Unless I'm missing something.

Someone please tell me I'm missing something.

You're missing something ...

it was a damned annoying bug !

To move objects with the edit window closed you were supposed to hold down the ctl key I think it was. Anyway certainly not simply move by touch. It took me ages to get into the habit of locking everything. One of the most annoying bugs in SL has just been fixed at last !

Ok, I get it now. I was holding Ctrl to move vertically. Thanks for fixing me. Kelly Linden said the same thing in the Hotline. Whew.

Well I don't get it yet. I just started building scripts that use the dragging capability, and I was very excited about what it was allowing me to do. Suddenly it is gone. Apparently I was taking advantage of a bug. But it was a very useful bug.

Now I have the opposite problem. Not even Ctrl-drag will allow me, the owner, to drag these objects that were draggable before. Not even selecting the "Allow anyone to move" allows it to be movable. With or without ctrl key. I see the hand icon with the little black lock on it. Why this is happening definitely seems to be a bug. Has anyone else observed this behavior? Is there a way to reset these objects so they work as they are supposed to?

However, when I create a new object, with no script in it, then the ctrl-drag works fine, as it did before. It moves vertically rather than in the 2D x-y ground plane, which is NOT what I need for my scripts. Maybe it is moving parallel to my view plane. Hard to tell...

So it is understandable that merely having a touch event handler allowing the owner to drag is considered a bug. But I never found it annoying, and I can't see wny other people do. It is easy to work around in at least two ways. And even if you do move your object accidently, big deal. There are several much more annoying bugs that are also very dangerous and I haven't seen any evidence that those have been fixed.

I would suggest that if a script has a move event handler (move_start or move_end) then it is intended to be moved, and the click-drag capability should be enabled.

I would also like to see a better system for constraining the motion of objects. It would be grand if drag motion could be limited to a line, a plane, or the bounding box of an object. The previous behavior constrained click-touch-drag to the region x-y plane, ctrl-drag constrained to some vertical plane, and ctrl-shift did rotation.

In fixing the bug which caused a touch event handler to allow the owner to drag an object without pressing the ctrl key, they have now disabled dragging at all when there is a touch handler, even while pressing ctrl key. This is a new bug. Or at least it is a bug that was exposed by the previous fix.

I experimented last night and found that creating a new object allowed it to be draggable (with ctrl key) but as soon as I added a new script, the default script that has a touch handler, then the object was no longer draggable. Very simple test. How did LL miss it?

My question is why was dragging enabled in the first place when there was a touch handler? This must have been explicitly added at some point (I think it was first in 1.6). Furthermore, the way it did the dragging was unique, and useful. It would always drag parallel to the x-y region plane, no matter how your camera was oriented. You don't get that accidently. I suspect it was added as an experiement and then forgotten about.

The only way we have of dragging objects now is with the ctrl key, and then it only drags parallel to the view plane of your camera. That is, you can't drag it closer to you or farther from you (from your camera's point of view, anyway). This kind of dragging may be useful for tossing balls around (or maybe not - how can you throw a ball away from you?) but it is not useful for interacting with objects relative to each other in any controlled fashion.

I have been developing a slider control that works with a 2D plane, taking advantage of the touch-drag bug. This is like a scrollbar but you are effectively controlling two values at once, the x value and the y value. It was working very well (except for the lack of any distance/volume constraints), but now I have no way of implementing this. At best, the user would have to position their camera parallel to the dragging plane, ctrl-drag the "puck" around, and I would have to reset the puck to the plane evey so often. There is enough lag in the response to dragging that this will be awkward at best.

It sounds like LL has plans to allow us to customize the user interface, but if that entails only modifying the look and feel of the 2D widgets in the client program, that won't begin to address the kind of thing I want, which is a way of building interactive 3D controls in the SL world that everyone can see and use. This is sort of the opposite of the HUD, which is 3D objects that only a single user can see. That is also useful, and perhaps I can build my 2D slider control in a HUD, but I find the lack of a shared experience unappealing.

Does this happen even if you manually disable the block grab status?

Zeno, a library of UI controls was exactly what I was working on too. I have certain prims in the controls act as handles for click-dragging (like the top title bar in a Windows window)... I have not been in 1.7 yet to test anything as I've been working too much.

I swear I remember the beach ball in my orientation bakc in March having this click drag functionality, and hold Ctrl to move up/down. This was such a useful feature. Adding llSetStatus(STATUS_BLOCK_GRAB, TRUE); to your prims would disable the click-drag altogether...

Anyway, I was content when Kelly Linden and Laukosargas here said you can still click-drag, but now it's hold Ctrl to activate, and Ctr-shift to move up/down (Kelly said something like that)... but if it's like you guys say it is, then I'm back to pissed.

But I'll reserve my pissed-off-ed-ness for when I actually can get in to see what's going on.

I thought it was control-drag to move up and down, and hold alt while holding control to move in the XY plane...

Nope. Alt-control changes the camera view, as does Alt by itself, but differently. Both allow left-right rotation around what you click on, but Alt zooms, while alt-ctrl allows up-down rotation as well.

In answer to Yumi Murakami's question, I did try using llSetStatus(STATUS_BLOCK_GRAB, FALSE) to hopefully stop the blocking of grabbing, but that didnt help. I didnt try first setting it TRUE and then FALSE, in case that resets the bit properly, but I have my doubts. It seems that the current fix of the touch-drag problem was to explicitly disable dragging, whereas what they should have done (if anything) is stop enabling it.

Is there another way to "manually" disable the blocking of grabbing? I did try setting that bit in the editor to "Allow anyone to move". I also tried setting the Lock bit in the editor and then clearing it, but that was no help, and it also cleared my setting of the "Allow anyone to move". No biggie on that, but it is not as friendly as it could be.

So I wonder if there is a way we could get LL to reenable this valuable feature of dragging parallel to the x-y plane (or any other plane in the world). One thought is if a moving_start or moving_end event handler is defined, then moving should be allowed, even parallel to the x-y plane. But moving should be allowed anyway by ctrl-drag and ctrl-shift-drag (which rotates), even if there is a touch event handler.

While I am at it, there is another significant difference between touch and move events. When you start dragging a prim using the mouse, a touch_start comes first, then a series of moving_start ... moving_end pairs (sometimes with extras of one or the other), with touch events intermixed, and finally a touch_end when you release the mouse. There is no other way to find out whether you are done with the moving than to detect the touch_end. So a drag-and-drop kind of action requires the touch event as well. When you drag by using the editor, you still get the move events (at least sometimes, not sure about this), but you don't get any touch events.

ya... 'tis currently phacked. So is llDon'tGiveInventory.

No, I mean it, I've just tested this to make sure. Go try it. Create an object, and start control-dragging it. While still holding control and dragging it, hold alt as well. That'll change the plane you're dragging in. It seems like letting go of control while still holding the mouse button does the same thing as adding alt.

Of course, if you pressed ALT first, then you're zooming and panning instead.

Does it still fire off touch events? Zeno made some good points about that.

You are quite right. Thank you for your persistence. This is fairly subtle, and easily misunderstood. Ctrl-alt vs Alt-cntrl are the same if you hold both before dragging, but different if you start dragging after holding the first but before the second.

And letting go of the ctrl after starting a ctrl-drag ALSO switches to the x-y plane, as you say. Very odd and unexpected. I wonder if it is intended. And what other features are still lurking.

Good enough, however, for me to continue my project. It is more awkward than necessary because you actually have to start dragging out of the x-y plane, before switching to the x-y plane. I'll have to do my automatic return of the control to the starting plane just to be safe.

One more thing I discovered. Ctrl-alt-shift moves the camera in yet another way. It pans the display while looking in the same direction, whereas the others rotate the view around the focus point or zoom toward/away from it.

Touch events are triggered even with ctrl-click-alt-drag (as we should say, to be clear) and ctrl-click-unctrl-drag (ew!) And actual moving of the object is still disabled for both when there is a touch event handler, as it should *not* be. I reported this bug, by the way.

Errrr.

If the object is *physical*, you drag it by grabbing, control-drag to move it vertically.

If the object isn't physical, you shouldn't be dragging it at all.

Have they disabled dragging of physical objects or something?

Ah ha! Thank you. Dragging of *physical* objects by touch-drag still does work, even with a touch event handler in it. Ctrl-drag works too. Also ctrl-click-alt-drag and ctrl-click-unctrl-drag moves parallel to the x-y plane. The easiest to use touch-dragging does drag along the surface it is resting on.

By the way, ctrl-drag doesn't necessarily move vertically because it depends on your view angle. It moves the object parallel to your view plane, which means it stays the same distance from your camera.

I believe all the previous messages have been about non-physical objects. At least, that has been true for me, and the answers from other people are consistent. If an object isn't physical, why should we not be dragging it? It has been working, and if we don't care about the physical simulation of mass and collision, why disallow dragging? It is useful. Rotation works too by the way, using ctrl-shift, for both physical and non-physical objects.

Yes.. I was wondering the same thing and was about to ask what you just asked...

If people wish to use non-physical objects with touch event to drag.. they could set the object to physical while it is being touched....

default
{
    touch_start(integer num_detected)
    {
        llSetPrimitiveParams([PRIM_PHYSICS,TRUE]);
    }

    touch_end(integer num_detected)
    {
        llSetPrimitiveParams([PRIM_PHYSICS,FALSE]);
    }
}

Nice idea, but it doesn't seem to work. I put the script you provided in a new object. Touch-dragging does try to start the dragging, just as for physical objects. but then the presense of the touch handler seems to override the permission to drag anyway. I get the hand with the lock icon on it.