Considerations for designing a configurable HUD?

I'm at a point in one of my projects where I need to pay more attention to HUD design - I want to make one that is configurable with pop out drawers and panels that slide in and out, and that can have different configurations with a code base that can be heavily generalized for other HUD designs. Before getting too invested in one design approach I'd like to know some good practices I can follow to minimize the HUD's impact.

What I had been considering is a script in each component that listens for fold and unfold messages, and which compute their scale and position based on a predefined relationship to a parent prim (i.e. popping up/down or left/right, etc, with the decision being based on both the parental relationship and the HUD attachment point). I'd rather just have the one script in the root for most of this but if I'm not mistaken you can't directly address an individual prim, you're limited to LINK_THIS, LINK_OTHER, etc? Or has that changed? Also looking for any other general ideas on design.

Thanks.

How about a two HUDs? One for configuration - whose final product is a configuration file that is read by the HUD that will be used.

That way, if you have massive complexity, at least it will be short-lived.

you can directly address individual prims with their link number in llSetLinkPrimitiveParams, just not individual groups (so either 1 call each, or one of the constants), so there should be no problems there.

you just can't (at the moment) read their current properties. however for hud slide outs that's hardly a burden (as all changes should be yours).

the only problem I think you might run into in that respect is mapping button images, as I can't remember if you can get the prim coordinates reported properly from a child to the root in huds (you may need to use TouchPos, rather than TouchST if the latter doesn't report properly). though it's doable regardless (and I am not absolutely certain it's a problem)

the root can determine which action to take based on the position return and the return from llDetectedLinkNumber, and you can further protect it from linking/relinking problems by using llDetectedLinkName with that.

you can even use one child to hold multiple menus (that will be mutually exclusive) by placing each menu on a different face and using llDetectedTouchFace to detect which one is being used, and PRIM_ROTATION to change between them (prim rotation, prim size, prim position, and prim color[the alpha part] being the methods for hiding and showing menus... I'd avoid the alpha one though)

ETA:
I'd also recommend using LSO for general purpose huds (one's you'll were around with you as you travel) for sim health, as MONO has load spikes upon changing sims.

Thanks very much, that gives me a good start.

What is LSO? Is it a product, like Be Bar, or an API that general purpose HUDs use for plug-ins?

LSO is just another term for the LSL complied code - as opposed to mono compiled code.

I'm not sure if it's a typo for LSL or an acronym of which I'm not familiar, but I think Void is saying not to compile the scripts in mono, if you possibly avoid it, if the HUD is something people are going to wear all the time. That would be because https://jira.secondlife.com/browse/SVC-3895 means wearing mono attachments bad news for the sim when you TP in.

ETA Pete beat me to it.

Ah. Ugh. Is Mono really so bad the we should compile to LSO for attachments? And that seems like such an important bug to fix since a LOT of attachment scripters are going to use Mono without knowing this.

[I just saw the second reply so I'll head off and vote for that bug]

it's not wonderful for sim exits either, but you don't see the spike as badly (possibly because of ghost script issues)

it's all written in LSL, but LSO distinguishes the original file format of compiled scripts from MONO compiled scripts. I think the naming convention is from the name of the open source library that was used to encode scripts before sending them to the server (or possibly the file tag it received in the cache, but I forget)
ref:http://wiki.secondlife.com/wiki/LSO

Curious, Void, why you advise avoiding alpha for this application.

simple, because the prim is still there so will still be accepting clicks at worst (it's still there, so still clikable), and blocking them at best (transparency doesn't pass clicks**). better to get the menus that are not being used out of the way entirely... which means size, position, or rotation change

**noted for accuracy:
some types of transparency will not hinder some types of clicks, but that trick is of very low value in this case since there's no type that will pass all clicks

Although you can see through an alpha hud, you can not click through it.

EDIT: Void beat me by 176.328 seconds