HUD With Opening and Closing Panel

I have seen several HUDs that, when you "push a button" somewhere on the HUD, a new "panel" or "drawer" is displayed or opened up that appears to be an appendage of the HUD. This new HUD section provides the wearer of the HUD with an additional set of buttons, sub-choices, etc... all related to the button that was initially pressed. Somewhere on the next section of the HUD there is also usually a button that retracts the appended section so that you are then left with the HUD in its original state, without the new section being available.

My question is a simple one. How does this work? Is the new section just a separate object stored in the HUD that is rezzed to look like it's a part of the HUD? What makes this curious to me is if, once the new section is rezzed and I edit the HUD both the old and new sections of the HUD move together when I use the arrow keys to reposition the HUD on my screen. If this new section IS just a separately rezzed object, what makes it "disappear" when you press the button to "retract" the new HUD section?

One other method I thought that might be in play here is that the new section is really there the entire time, but is kept invisible until the button is pressed which alters the attached section's opacity? I'm thinking, however, that this latter idea isn't really being used because, when I turn on "Highlight Transparent" I don't see any invisible pieces on the extremeties of the HUD.

Thanks, in advance, for any light you can shed on this most curious process.

Rutherford Beresford

i use llSetPos to move my panels off screen. the opacity works but will mess with you selecting and editing things cause the panel is still there.
rez wont work unless you rez and attach and you will have to be on land you can rez stuff.

Ahhh.... so when initially worn, the panels are present but are set far enough enough from the HUD that you can't see them, and then when you press the button to display them, you simply move them in closer? Very cool!

So, the exact line of code I would put in each of the child prims in the "panel" to move them, keeping their same relative to the root prim, would be something like...

llSetPos(llGetLocalPos() + <0, 0.5, 0>;

I'm thinking the tricky part is keeping all the child prims that comprise the panel in their same relative position to one another as you move them back and forth. Will this do the trick?

Thanks again,
Rutherford Beresford

The SLOODLE Toolbar HUD uses rotation. It's basically got three modes: blog, gestures, and 'minimized'. Each panel is just offset 90 degrees from its predecessor. In practice, we actually have two identical 'minimized' panels on opposite sides, so at any point, you just rotate it by 90 degrees to minimize or restore it. When changing between "blog" and "gestures" modes, you just rotate it by 180 degrees. The back and sides of each panel are totally transparent.

It works because HUD devices are rendered 'orthographically' (i.e. there is no sense of depth, so prims become basically invisible if you make the side facing the camera transparent). Obviously the prims are still there, and can still be touched, so you need to check which panel is actually visible before responding to any touches.

The basic script is pretty simple, although it's got a whole bunch of other SLOODLE stuff in there which you can ignore:

http://code.google.com/p/sloodle/source/browse/trunk/sloodle/toolbar/lsl/toolbar-menu.lsl


The advantage over moving stuff is that everything stays in the same relative position, so you don't have to worry about multiple prims getting out of alignment. You could sensibly do up to 6 panels this way, if you rotate around the vertical axis too (basically like 6 sides of a cube). Beyond that, you have to come up with something a little more complicated. And the down-side of all this is that the HUD device is a nightmare to model, because you can only see part of it at a time.

I use llSetLinkPrimitiveParams(2,[PRIM_POSITION,<0.0,0.192500,0.0>, PRIM_COLOR, ALL_SIDES, <1.0,1.0,1.0>, 1.0]);
for this and llDetectedLinkNumber(0) in touch_start event in a script in the rootprim. No need for a script in every button.

SetLinkPrimitive params has that annoying sleep time, and makes any end-user modifications of your HUD a royal pain.

I use a script in each prim that has a collapse function. I would normally consider this an extremely bad thing, but under MONO, being multiple copies of the same script, the negative isn't quite as high as it would normally be.

The new llDetectedTouch*() functions will help a great deal with this type of HUD now, since many applications will be able to use a single textured prim for a whole panel of buttons. That means the whole thing can pop out at once instead of having to coordinate the movement of multiple prim buttons and such. A great option is to hide your sub-panels inside the main panel when they aren't being used. If your GUI is such that you only have one sub-panel visible at once, you can even re-use it it in different configurations by remembering multiple positions and textures, and simply using whichever one is in demand at the time.

Depends on what you want to do. The delay can have cool looking effect, when the buttons fly out in the right order, one after the other.