Jump to content

HUD Positioning and Sizing


GManB
 Share

You are about to reply to a thread that has been inactive for 1244 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I am using llAttachToAvatarTemp(ATTACH_HUD_*) to attach an object as a HUD from a script in a manner so that the user has only to reply 'Yes' to the permissions UI. The size of the object is <0.01100, 0.43733, 0.59333> and the orientation is correct (in that the proper face appears on the display when attached). The object is a link set.

If I attach to either ATTACH_HUD_CENTER_1 or ...2, I see the complete proper face. If I use any of the other ATTACH_HUD_* values however part of the object's proper face is off the display. E.g., if I use ATTACH_HUD_TOP then the top have of the object's face is off-display or for ATTACH_HUD_TOP_RIGHT only the lower left quarter of the object's face is visible.

It seemed as though llAttachToAvatarTemp() was attaching so that the center of the object was at the position but linking in a transparent prim so that the center of the newly linked object was in an appropriate position made no different in the visible portion of the object's face.

Note that I see the exact same positioning when I attach the object by right clicking the object's entry in my inventory and selecting 'Attach to HUD'. I, of course, have HUDs that position themselves in the corners with proper visibility.

 

How can I control the positioning of a HUD using llAttachToAvatarTemp()?

Also, my customer wants a resize button in the HUD. I haven't tried this yet but I am assuming llSetScaleByFactor() should work as expected. If there are any quirks here I'd appreciate knowing.

 

Thanks,

G

Link to comment
Share on other sites

Generally a HUD user expects, and is expected, to position their HUDs wherever they find convenient themselves, using the standard build tools. It rarely goes well when a creator forces a HUD to position itself where they think it should go in contravention of the user's wishes.

Having said that, you can move a HUD around the screen using llSetPos or llSetLinkPrimitiveParamsFast with the PRIM_POS_LOCAL parameter.

Link to comment
Share on other sites

If you attach to the left side - the center of the root of your hud is placed on the left side of the screen. Y = 0 is at the left screen border then and if you attach to the right side Y=0 is at  the right screen border. Same applies to Z for top and bottom.

Once attached you use llSetLocalRot and llSetPos to set your hud on a proper position and rotation.

For the center attachments Y=0 and Z=0 is in the middle of your screen. That means you dont know where the borders are. Imagine a small notebook screen and a widescreen.

The X-axis is the depth and has no visible effect, except you have 2 overlapping huds. Then you can control who is in front.

Link to comment
Share on other sites

Thanks. I found another way. Attach via right-click from inventory. Position with build tool. Detach-to-inventory. Now the prim 'remembers' it's position on the screen and when I call llAttachToAvatarTemp(), with, apparently any attache point, the HUD/prim attaches to location where it was when it was detached-to-inventory.

 

@KT Kingsley I agree. This positioning is just to be the default initial and there is another artifact in this game I am building, the game table.For the table I set the avs cam to look straight down onto the table with the table positioned to the left side of the display and I wanted the HUD on the right side but, obviously, fully visible. Users are free to move things around and adjust their cam as they see fit. As a side note I was surprised at the number of friends who did not know how to move a HUD around on a display :(... Or resize it as well... They all clamored for a resize button ...

@Nova ConvairAh, missed that it's the center of the *root* prim not the center of the linkset. That's my experiment with the transparent prim didn't change the behavior.

 

G

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1244 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...