Are HUDs reliable? Or do you use llDialog?

Would you say that HUDs are reliable for providing an interface to the user (textures and prim update always on time when changed via llSetTexture / llSetPos / etc)?

Or would you say that llDialogs are probably the best bet for a reliable interface?

Looking forward to a response from the community.

I used a combination of HUD and dialogs in my Skoopf Icicles basically because HUDs are good for quick things (I used the HUD to get into the different settings screens and to turn the skates on and off) and dialogs are better (in my opinion) when you have a number of possible settings, so for instance in my skates, the jump animation settings are done through dialog boxes because of the flexibility needed but getting to that settings page in the first place is done by clicking the 'Jump' button on the HUD.

HUD implmentation can get really complex if you're wanting to allow people to change multiple settings (with multiple possible setting values), so much so that I think dialogs end up making more sense for that. We don't really have the ability to create smooth UI widgets with prims on HUDs - it's beset with problems I've found.

Setting textures on HUDs is reliable though. Hope that helps.

I have a HUD that controls the whole llParticleSystem array purely from on screen and have had no troubles ( from me or my customers )

I use dialogs for menu options like an RL program would ( file save - options etc - static options ) - The real time on screen stuff is handled by the HUD.

(And I use the same principle in a number of different HUDs )

What problems have you found?

It seems to me if you can set the texture of a prim face reliably and you can detect a touch (which I believe is pretty reliable), then you can simulate a mouse driven interface very well.

My concern is the llSetTexture though. I worry that I might update a HUD as a result of a user interaction and the client might not get the update all the time for that hud.

HUD texture updates are notoriously slow - but if you use low detail graphics they are normally OK ( and given the size of the buttons you dont really need high definition graphic files for them )

I have several multi panel texture displays on HUD and they are OK.

But if you want split second response time then HUD's wont do it ( nor will anything when it comes to textures )

Movement of linked objects on HUDs ( sliders etc ) is also generally OK.

The only real problem I have found with HUD's is when a user attaches them to a wrong point or drops them on the ground and wears them from there ( they sometimes rotate themselves to be 90 degree edge on to the screen )

My testing has shown that it does respond quick enough for my purposes, my concern I guess, is how it holds up over use by many different people over many different video cards and operating systems.

If one wrong state can mess everything up, then it is a problem.

However, dialogs have their problems too, of course, because of the ignore button which does not report that ignore has been pressed.

They'll get the update OK in my experience, and it helps if you pre-load textures on the back faces of the but prims (mind you that might no longer work with occlusion culling - not sure). The problem is that updates can be a little slow which doesn't generally make a smooth, useable interface.

And as for UI widgets, I'm really talking about rotatable buttons, draggable sliders - stuff that really goes hand in hand with settings where there can be any number of different options, or variations between values. Unfortuantely those sorts of things, although they can be achieved, end up looking decidedly cludgy and error-prone which I why I avoid them.

The ignore button not reporting seems stupid, but there's a simple solution with a time-out which is what I use. What gets really complex with dialogs is having multiple-levels where some sub-options could have the same text. You need to track the state in the script for which dialog was the last shown in order to do the processing correctly here.

To be honest, neither solution is perfect, but it's what we're got to work with

Personally, like Moopf, HUD for immediate information and controls you'll want quick access to, and dialogs for configuration. If there's a lot of information to be delivered which doesn't need to be there all the time I'll mostly use llOwnerSay to be honest, clumsy though that might be. And things you need *really* quickly and/or frequently are done using control(), or automatically.

e.g. at the moment I'm making a derringer that has a HUD. It tells you the current ammunition type and amount as well as where on your body you've hidden it, and has buttons for hide/draw, reload and change concealment place. (Actually, the ammunition counter also doubles as a "toggle ammunition type" button.) However, it doesn't have one button for each hiding place, as that's not something you'll often change. The "change" button triggers a dialog for you to select the place that you want. Firing, of course, is done with the mouse button. All the HUD weapon systems I've used or built have always been too slow and unintuitive for me.

The Engine Rifle that I did was completely controlled by control() and a dialog menu triggered by touch. (It's large enough that you can always touch it pretty easily.) The heat indicator is actually mounted on the side of the gun, visible in mouselook. There's a HUD but all it has is an ammunition readout.

One other thing I'm considering with HUDs is that sometimes, people might not actually have *room* for your HUD, or may not be bothered to put it on. If you can also incorporate an alternative, say a speech-based system, I think that's a good idea.

I think someone might have said it before, but whenever possible, don't change textures. Put all the possible button textures on one texture and change the offset to display the button image you want at any given time. I've found this very reliable.

The only real problem I have had in the past is that when you have two textures overlapping, both with alpha textures, sometimes the SL client can do strange things, displaying the texture you want in front in the back. My last big HUD project, I made it so there are no overlapping textures at all.

Well, changing textures is okay if you're not going to change them too often, I reckon - say a toggle button that changes its label. But it's not a reliable method for rapidly changing displays, any more than it's reliable for rapidly changing textures in-world.

The reason I don't change textures anymore is because you have to wait for the client to rez the new texture. I don't like ugly grey squares on my HUDs.

You do, yes. With small textures I don't find it's that noticeable myself, but llPreloadTexture would be rather useful for these purposes.

You made me look up llPreloadTexture in the wiki. I was disappointed that it wasn't there yet.

i havent worked with huds yet, but something i do in normal building is instead of using 10 textures for an object, if its small/med size ill use one large texture with all 10 on it, then use texture offsets instead of changing textures, this reduces texture loading time.

i am getting ready to start using hud for some things, is this something that might help with the problem?

Yes. As I'm sure you, and the others on this thread know, once the texture's loaded that's basically it, it will stay loaded because it's there on your screen. There's a small penalty at start up, but after that it should be fast.

Tichy textures, which lets face it many button textures are, also load very quickly mind. There isn't, like most of these things, a definitive answer, small but fiddly textures I tend to do one at a time just because it's easier to tweak them that way IMO. Middle sized ones I'll at least sometimes join together into one larger one and use offsets, but I'll rarely go beyond 256 X 256 and unless I really, really need it never beyond 512 X 512 - although that's a lot of buttons usually!

Although you can't preload textures by script quite as shown, you can preload them into the client. Paint them onto a hidden face in your HUD and your client still prepares to draw them, just fails to display them. When you flick to the other texture it's already loaded so you don't get the grey square. Quite a lot of the e-books, and some of the better display systems and even a decent sized subset of multivendors use this tactic so the textures load quickly.

That's exactly what I do now. Try to get everything in one texture for the whole HUD, sometimes I can get it down to 128x128, but usually it's 256x256 or 512x512.

One "problem" with a HUD, if you try to click on a HUD to use it in a property you're banned from, SL won't permit you to. Instead, you have to use chat commands.

Erm... how would you be in a property you're banned from to use a HUD?