HUD attachments - that wonderful new feature!

While I'm waiting on a reply on the Hotline, I wonder what your feeling is about this idea: moving voice-activated attachments (specifically, very low-prim ones) to HUD attachments, where you can replace voice activation by clicking on buttons that nobody else can see.

Although there is a design issue to consider (ie. after all, you can only have 8 HUD attachments and you still wish to have some space on the viewport left...), I was wondering what would create less lag...

1) A complex voice-activated command system with an open llListen();
2) A HUD with, say, 30-40 buttons that activate commands through llMessageLinked() and no open channels.

If 2) is a far better choice, well then, we have our use for a HUD as a lag-reducing mechanism If not, it'll be a niche device for use on some types of games that need to display hidden information and eventually some things like personal vendors or ATMs (in the future, I suppose that HUDs will also be able to display HTML, even in 1.7...).

[Of course, if we ever get quick object-to-object communication (say, as quick as llMessageLinked() ), I expect HUDs to become widely used!]

How should/could we test this? Sort of having 40 avatars testing two different approaches - a traditional one with an open llListen(), and a HUD-based one - I'm not sure there is an alternative way to do some benchmarking, or is there? Any suggestions?

Implementation is more important. If the open listen is full of if statement string comparisons and the hud is touch_starts it should be pretty obvious which is going to be better!

It's more about choosing the right tools for the job and open listens are very rarely it. Theres a few cases where an open listen is sensible but private listens or dialogs have mostly been grasped by the majority of SL and I think the issue is coming to a close so long as the new scripters learn not to do it that way.

Well, in theory, 2 would be less laggy. HUDs seem to effectively just function as a normal prim would.

I'm curious now though that you mention it if alot of HUDs cause lag, like prim hair. I would think not, but you never know.

The one thing that sucks right now about HUDs is that there is a bug with all prims that 100% alpha'd prims do not pass clicks, they catch them (regardless if they have a touch event). So you can't "hide" things out of the way, and allow people to act as if they're not there. How this effects HUDs? Well imagine having a button you clicked that made visible a slue of buttons across your screen, then you could click it, and hide them again, this would be usefull (atleast to me). But you can't do that currently because of the bug.

Also things that don't work in HUD:

- Shiny
- Particles

Bugs I noticed:

- Target Omega stops when you edit a HUD and only starts up again when you reset the script.
- Sometimes stuff rezed that people attach as a HUD become ghosted and visible still to people around it.

I'd like Shiny and Particles to work in HUD, I'm not sure how, but I think it'd be neat, especialy Particles.

Overall I love it and it opens up many possibilities and will be usefull in the future.

I understand prim hair is to do with the LOD system popping between the number of polygons used on the twisted torus shapes used, whcih people bundle in as lag even though it's just clientside framerate loss (I dont know how the servers treat prims attached to the av but I dont think they do any work for them, I think it would only involve the asset server and the client).

Another thing I notice is that hud attachments don't make any noise when they play sounds. It doesn't give any errors... just that nothing happens.

Target Omega is on the known issues list btw.

Really? I hear sounds on HUD attachments. Hm.

Where is the known issues list?