This tutorial is currently available at
Creator Resource: Creating HUDs, the builders part
What is a HUD? What is the purpose? How do I create a HUD?
I'm a builder and want to create a HUD so a scripter works the code, what should I take into account?
Creating HUDs is usually a team work between builders and scripters. Come join this class to have answers for the questions above and learn, as a builder, what to take into account to design your HUD the best way for the scripting it may require.
Table of contents
WHAT IS A HUD?
"HUD" stands for "Heads Up Display", that's it, an object that gets attached to one from a few special points in our viewer and shows in our window, but it's not seen inworld by the rest of avatars around. They provide us with an interface to control many things we can think of: our avatar (like animation overriders), objects around, nowadays with the new viewers they can even display media on them.
We sure have used lots of HUDs, being the most popular uses:
- Animation overrides
- Multi-tools
- RP and combat systems
- Books, magazines...
- Texture/Color/etc change for hair, shoes...
and many more.
To use them is very simple: we just have to attach them to any of the EIGHT special HUD points that SL allows us, and begin clicking :o)
The available points for HUDs are:
- top-left
- top
- top-right
- bottom-left
- bottom
- bottom-right
- center
- center2
There are no left and no right attachment points, as of 2013-12-20.
However, nowadays we can use the "Add" function instead of "Wear", so we may have several HUD attachments in the same HUD attachment point, if the HUDs are designed to be placed in the same HUD slot.
FIRST COMMON QUESTIONS ABOUT HUD OBJECTS
One of the first questions that may pop into our minds is,
Is there any restriction about what we can attach to a HUD?
And the answer is: NO.
We can attach even a castle if we feel in the mood.
Of course, the castles being as big as they are, they'll cover all the screen... But can we attach a big castle to the HUD? Yes, we can do it.
So yes, as long as what we want to attach is an object, there are no limits on what we can attach to HUD: From a jewelry nano bead to any other object, no matter the size or the contents (that this is useful or not, is a different matter.)
There are a few properties that HUD objects won't show: we'll discuss them later in the corresponding section of this class.
Do HUDs affect to lag in any specific manner?
No: If our HUD contains lots of 1024x1024 textures that change often, is heavily scripted, has many listeners, sensors, timers... It will be a laggy object, but if textures are kept to small resolution, the scripting is wise... We should not expect more lag from a HUD object than from the same object inworld.
Even more: since a HUD does not exist inworld, the server does not have to check about the possible collisions against it. So common sense applies here: design the textures (sizes) and the scripting wisely, and your HUD won't be a problem.
HOW DO I BUILD A HUD? ARE THERE ANY RESTRICTIONS?
One could wonder,
have HUD objects any specific building requirement?
And the answer is NO: If you know how to build, you know how to build a HUD, as we're going to see now.
The only difference is this: If, after building our HUD,
we need to add a new prim, or unlink a prim to delete it... That forces us to
REZ the HUD inworld, add/unlink the prim, take it again back to inventory, and then attach.
Let's go over building one by doing a small practice.
So please, rez now a box.
In your "General" tab, name it, for example, "Test Box for HUD":
Texture the box with the blank texture.
Then make a SHIFT COPY by following the Y axis (the green arrow.)
Now for this new copy, select another color than white, just to distinguish them. I will tint mine dark red. Then, make this red one smaller, say, a 0.25 cube (it doesn't matter as long as it's smaller.)
Move the red inside the white like this, and link them:
Just this, it can be a HUD :-)
NOTE: a HUD can be even just *one* prim. One prim that has a very complicated texture with many options drawn could be a HUD :-)
The only limit for the number of prims a HUD can be made of are the SAME limits we have for the objects inworld: 256 linked primitives per object. That's the max of prims we can link, no matter the object is a HUD or not (Check here for the reference:
http://wiki.secondlife.com/wiki/Limits#Building)
Ok, so do we have our "Test Box for HUD" object linked?
Take it back to inventory and look for it in the "Objects" system folder.
Now, right click over your object in inventory: this will open a menu.
Look for the "Attach To HUD" submenu and move your mouse over it.
When hovering on it, we see that the viewer offers us the EIGHT attachment points mentioned before, to select one.
Now, select CENTER for this one.
And yes, it's going to cover a lot of the screen :-)
You should have now something very similar to what the picture shows. The red box can be pointing to the same side, or the opposite. It's fine whichever side, don't worry about that :-)
Now that we have this huge thing on... Since it's possible that some of you don't know how to move a HUD object, let's learn that first.
Right click over the HUD object.
Select "Edit".
You see now that arrows appear in the center of the object, same way as when we edit objects inworld, right?
So moving the object in the HUD is done the same way we move an object inworld: we can drag the arrows and the object will move along that direction.
Notice this, though: The HUD is not 3D. The objects attached are 3D, yes, but what we see is a 2D projection of them. Still, we can move objects and ROTATE them in the HUD.
Now, let me explain something... (little side note)
Right after attaching the box in our HUD, the first we've all seen is the attack of a giant box in our HUDs. And the box was simply 0.5 meters inworld!
This leads to an obvious question: What's the size of the HUD display area?
Good and bad news: We can know only the vertical visible size of the HUD. There's no way to know the measure of the horizontal size.
The vertical size corresponds with the Z axis.
Including the menu bars of our SL window and the mottom menu options, the height of our HUD area is ALWAYS ONE METER, no matter the resolution of your screen/SL window size.
This is handy to know if, for example, you have to create a HUD that hides when the avatar goes into mouselook. Your script could change the Z of the HUD to, say, two meters, and the HUD would not be visible by the avatar.
So we have an horizontal, undefined width, and it moves along the Y axis. Then, positive values of Y are when we move from the center of our screen, which always has coordinates (0,0), to the left.
Then, we have the height of the visible area, which is always one meter, and it moves with the Z axis.
And what happens to X?
X measures how "sunk" is the HUD in the screen (although we'll see it always the same size.)
Changes in X may help us to the following: Design a HUD with several panels, they having different X. We know, now, that the ones with a lesser X will be hidden by the ones with a greater X, so a scripter could use this to swap panels.
Now, this is advice that comes from experience: Don't make your buttons to be thin :-)
As you can see in your test HUD now, we only see a 2D projection of our object, no matter how thick are the buttons. If we try now to resize the HUD (how? In a moment,) if our buttons were too thin, we'll quickly stumble against the 0.01 minimal size that SL allows for our prims, and we could not shrink our HUD much.
And since we know, now, that one meter inworld will fill all the vertical part of the screen, it's obvious that we're needing to shrink our HUDs quite a bit.
So let me quickly show an example here of what I mean with what we should NOT do when designing a HUD. I'm going to rez one HUD object I created. (
Almost 2014 note: This HUD dates from 2010 =))
Please, zoom around.
Do you see that my buttons are NOT thin, but quite thick indeed?
(the buttons are even thicker... sunk in the main, black prim)
I don't care about the size that, anyway, won't be shown in the screen:
So why make them thin, and find myself stuck soon in a 0.01 problem?
I make them big.
Is there any recommended size to start with? I usually begin building at one meter (which will cover the whole vertical size,) then shrink once I attach in the HUD. Experience will tell you what works best for you.
I've said that the HUD screen area is one meter vertical, undefined, horizontal. But we have know, before editing things, that the total HUD area is quite bigger in fact. If we lose a sock, we may explore that area :o)
Let me explain what I mean.
Please, right click again in your HUD object, select edit.
And now, use the mouse wheel to zoom out.
NOTE: If you don't have mousewheel, you'll achieve the same by holding pressed ALT key, click with the left mouse button, and move the mouse backward.
Do you all see, as here, that it appears a white frame, and there's more space around?
That white frame delimits always the screen area. But yes, we can move objects further (and thus, make them disappear from our sight.)
When one loses a HUD, has to do this to get to the total HUD area: edit something else in the HUD so we can zoom out. Then find your object, click it, and move it back within the white area. (Unfortunately, what we can't do is zoom in MORE than the own HUD screen area.)
So, when we lose a sock, now we know how to look for it, yes? :o) (or when we WANT to lose a sock, where to send it)
It could be possible that we have no attached HUDs in the visible area, and we want to know if there's something out of the visible area. There's no way to zoom in the HUD unless we're editing something in the HUD, so this is a simple solution:
- Rez a box
- Take it
- Attach it to HUD: Center
And now we for sure have something in the visible area to edit, to be able to zoom out in the HUD total area. Once we've found what we've lost, we can detach the box.
If you are in a place where you cannot rez, then you can try this (which might be quicker in many cases):
Check the "Worn Items" tab from the inventory window, and look for your HUD item there. If you don't find it there, then have a look at your "Marketplace" tab. Worn items from that tab do not show (yet?) under the "Worn Items" tab.
NOTE: When we close the edit window, we're closing the zoom-out in the HUD automatically, and will get again only the screen area, 1 meter height.
Now, how can we edit something that is in the HUD, once we've attached the object? Can we do the same edit options we do inworld?
Almost: remember what was said before... We CAN'T link/delink in the HUD: We have to rez first, then link, or delink, take the object back to inventory and attach it again to the HUD.
But apart from that...
Can we edit linked parts?
Yes.
Can we rotate the objects in HUD?
Yes.
Move them?
We've seen also that yes.
And do we rotate, scale, etc, the same way we do it inworld?
Again, yes.
It's very easy to check this: Please edit again your HUD. If you click now, in the edit window, the "Rotate" option, do you see that the wheels to rotate appear?
Rotate doesn't have handles, but wheels, don't forget!
Also, the keys keep working: holding CTRL in edit mode will make the rotating wheels to show up. And we can hold CTRL pressed, click over the wheel and rotate.
But I don't recommend this, for rotating, for a reason: The HUD is a 2D projection, and we can't zoom around it as we do with the 3D objects inworld. So if we're not specially careful using the wheels, most likely we'll rotate the pieces wrong.
What to do then?
Use the edit boxes for the rotation, in the "Edit" window.
But for size... If you want to resize the whole object at once, use the WHITE HANDLES that show when we click "Stretch", because if we type directly numbers in the edit boxes... This will resize ONLY the root prim, or the child prim we had selected.
Trying to resize a whole linkset typing numbers only changes the size of the selected prim: Inworld and in the HUD. If we aren't into "Edit linked parts", this is the root prim.
You can now detach the test HUD.
IMPORTANT: When you prepare a HUD for sale, make sure that you attach it to your HUD, move it to the position you want it, and then detach it, prior to pack it. Why this? Because it is when you detach the HUD when all the data related, including the position within the HUD, is saved. (This is true for any attachment, not only HUD objects.)
PROPERTIES THAT ARE NOT SUPPORTED IN HUD OBJECTS
Now that we're talking about what we can do in our HUDs... It's time to think about what we
can't do in our HUD objects.
Yes, we've said that there are no building restrictions, meaning, we can attach
any object to the HUD points, and we build them inworld, so same rules for the limit of child prims and others apply too.
But there are a few restrictions when working with HUD objects that we have to know about.
The first difference comes with sounds: If a sound is played using llPlaySound, in a HUD, only the person wearing the HUD listens it.
Also, sadly, particles
usually won't work (they could in experimental viewers... but don't take this for granted! most of the people if not all, will not see them in the HUD object.)
Texture animation, sculpted prims and even TARGET OMEGA and flexi prims
do work in a HUD object. Glow doesn't, but shininess does.
The hover text is supported BUT this is important: The text does NOT scale with the size of the HUD. If we make the HUD smaller, the hovertext will have the SAME size, so keep this in mind if your HUD is small :-)
The hover text sometimes may help you saving on textures, and it's also useful to display values that change often (like the ones that come from combat/RP HUD objects, with meters for several properties of our player.)
Shared media also works in HUDs, but since V2.2.
And don't forget this... A HUD object is an attachment, so, like any other attachment, if our HUD has a sensor active, it
will not detect the avatar that has it attached.
A NOTE ABOUT HUD OBJECTS AND PERMISSIONS OF THE CONTENTS
When our HUD object is
attached, the only assets we can drop in the "Content" tab are those that, for us, the owner, have FULL PERMISSIONS. If we have to drop any asset that has any restriction over the permissions *for us*, we'll have to REZ the HUD object inworld, drop the assets while it being inworld, and then take it back to our inventory. (That's why we have to rez our poses HUDs, for example, since we normally purchase them copy/no transfer.)
Be careful when you do this with NO COPY assets!
Make sure in this case that there are no notified problems that could affect to no copy items rezzed inworld. For this, you can check the
grid status page.
A couple of related resources:
ADVICE WHEN YOUR HUD HAS TO BE SCRIPTED BY SOMEONE ELSE
Before finishing, I want to give one more suggestion, apart from all what we've said.
If we're the builders of the HUD, but then we have to contact with a scripter to make it work... It helps A LOT if you put names/descriptions in the prims that you want to be, either having an action on click, or that have to display information/textures.
What do I mean with this?
Again, let me look for an example to rez.
The HUD I'm going to show will also show another suggestion, in case you need to switch textures for on/off actions. In this case, the customer used the name field of the prims, for prims that were relevant when clicked.
Please, inspect this object.
Go into edit linked parts.
And click the prims.
Do you see that they have specific, unique names?
Why is it important to put names/descriptions to the prims?
Because each one of this buttons has a specific action, and they could be linked in any order.
Even if you're not a scripter, you should know that is better if a script does NOT rely on link numbers. If the script simply looks for specific names/descriptions, and retrieves the link numbers, that makes a scripter's life a lot easier AND should you unlink/relink your object, the script will (should) continue working THE SAME.
So do you all promise me that, from now on, you'll put names/descriptions in the prims you expect actions from, or information to be displayed? :-)
"Make a scripter happy... Use names/descriptions in the prims" :o)
Now, let me "break" this HUD a bit :-)
Look at this button. (The dagger button in the picture, which has been duplicated twice to show the side faces.)
It has, apart from the visible texture (the only we'll see when we attach the HUD), two more textures.
The two textures that should be used for on/off, each one at one side. The reason of doing this, is to have the textures preloaded, so your user doesn't wait for textures to load when switching on/off.
This is something I recommend doing: If you're building HUDs, and need to switch textures, have them in the sides of the buttons. They're not going to be seen anyway, because we only see the 2D projection. The rest is between the HUD and us :o)
(Make sure, though, of using small textures. For small HUD buttons, 128x128 pixels could be more than enough. Even 64x64 could be enough. 1024x1024 textures for small buttons... NO!)
Now, don't forget this: we can hollow and path cut boxes, so this makes up to 9 textures that we could apply in each face. One has to be always the texture that we show to the user: but that makes 9-1 = 8 textures that we can preload per button, should we need them.
MISCELLANEOUS QUESTIONS
QUESTION: Let's suppose that we want to rez a HUD to be able of link/delink, and turns out that the HUD contains a script that makes the HUD to be deleted if the object is rezzed instead of attached. What to do in that case, to be able to link/delink prims to the HUD object?
If the prims are copy/modify, and the script is copy at least, the following is a possibility:
- Make a copy of your HUD object
- Attach this copy
- Delete the script that is making it to be deleted on rez
- Detach the copy, rez inworld and work with it
- Attach it again and add the copy of the script that you deleted, in order to be able to rez and work with it
Alternatively, go to a region where scripts are deactivated. (IMPORTANT: If you do this,
make sure you're no higher than 50 meters above the mesh terrain, otherwise, scripts WILL be active.)
If the prims are no modify, you would not be able to link/delink anyway. In that case you can contact the creator to see if they can make the specific variation you want for the HUD object.
QUESTION: If particles can't be shown in the HUD... How could we create a HUD to make particles effects?
For that, your HUD object has to communicate via llWhisper/llSay/llShout/llRegionSay with an emitter inworld, that should receive the parameters, process them, and generate the corresponding particles effect.
QUESTION: Is it advisable to speak with the scripter before building the actual HUD?
Yes, always. Creating a HUD is a team work, so this previous dialog should happen to avoid later changes in the specifications (which can drive mad the scripter, since at times, a change in the specification could mean to have to redesign the whole scripting.)
And this is all for this class. I hope you come away with new knowledge.
-- Auryn Beorn
