HUD Positioning Unfriendlyness :)

Well just started playing with HUDs in earnest today and I've quickly realised that the position of a HUD changes based on your screen size - that's not very user-friendly at all. Basically I positioned my HUD (bottom right) where I wanted it, then played with making my window bigger or smaller. When it was smaller most of the HUD dissappeared (although it did appear to scale, just not correctly in relation to the change in screen size). When I made it larger, I had gaps around the HUD on the bottom. They also don't move up or down if you turn your toolbar on and off.

So, does anybody know of a way around this? I can't think of one, other than the user editing the HUD to reposition it - but that's kind of unfriendly isn't it. I thought of using a prim, centered on the default 0,0,0 position but that made no difference to the scaling problems.

'Enter your resolution' -> llSetPos?

I did something last night, quite by accident, that seemed to resize the screen just for the purposes of the HUD. The various plywood prims I had attached to HUD points all moved into a smaller rectangle in the middle of the screen, one I could seem to resize at will to, say, add a margin between the corner HUD points and the edge of the screen.

Wish I could tell you what I did exactly to do that, but I can't.

It might work as a work-around, but still it's not "instant". If you have a HUD set to attach to bottom right, it should stay bottom right and move as your toolbars change on/off or as you resize. Or at least you should have the option to be able to have that behaviour for your HUD.

It's like not being able to rez and attach a HUD directly from an object's contents. It's fiddly and not intuitive. If I get in a car or wear something that has a HUD, it should be automatically attached and shown.

The initial feature set seems to be missing some features that I'd really think were a given for HUDs to work well.

That'll be the zoom bar on the Focus page in the Edit window I think. But the margins from your positioning won't stay the same as you change your screen size, they'll only look right for your current screen size - that's the problem.

I've been messing with the new HUD attachments quite a bit, and did some experimenting with llSetPos. I've figured out how to align HUD elements properly for differently sized screens relative to the right side and bottom corner.

Basically, the bottom right corner is < x, 0.0, 0.0> (since the only coordinates you seem to be able to modify on a hud attachment are Y and Z). <x, -0.1, -0.1> is a small bit to the left and above the bottom right corner. I have an attachment im working on which always aligns itself to be right up against the right side of the HUD using this method.

I still need to do more testing to see if theres a way to position relative to the left and top edges. Hope this helps a bit in your hud positioning woes!

Ran up against the exact same problem. At the very least, there should be a llGetResolution() function. I could understand having the upper left corner of the screen be 0,0... but the bottom right? O.O Madness.

Nefarious, I'd be interested to see what you've come up with as I've not been able to resolve it, because there's no way of knowing what size the screen is and re-positioning accordingly (save actually asking the user, but I fear that many wouldn't know, especially if they're running in a window). The only way it's working is with a single prim - that resizes correctly. Position that in the default <0,0,0> position and it will scale correctly and stay in the same position. Do it with a multi-prim object, even with a root prim centered on the default position and it will not scale properly as the screen size changes (smaller and you'll get the bottom of the HUD cut off, larger and you'll get a gap below and to the right side of the HUD). But if you've found a neat way around this I'd love to hear about it.

I believe, and have just checked that preferences>graphics shows you the screen size, even if running in a window. Not sure how reliable it is, but looks right to me.

No, it's not correct if you're running in a window. All you're seeing (I presume you mean under the 'Run in a window' checkbox) is the greyed out select box to choose the resolution if you're not running in a window. That's showing 800 x 600 for me, when I'm actually in a window nearly 1920 x 1200.

Strangely enough, according to the positioning grid, 0,0 is the CENTER of the screen, but you are certainly correct, when scripts alter the position of HUD attachments, it's relative to the bottom right corner. Very strange behavior. Even stranger, if you position a prim exactly in the center, at what the grid claims is 0,0, and change the screen resolution, your prim will now be off-center. O.o

Yes, it's not the most friendly of implementations is it! I want HUDs that act like HUDs do in games etc. I want HUDs that stay stuck to the bottom right, top right, where ever. You know, like you turn a toolbar off and the HUD drops down so it's still at the bottom right.

I also want HUDs that can be auto-attached (without all this rezzing nonsense that would leave mutliple copies of the HUD in a user's inventory and wouldn't work in no build areas) when the person sits in a vehicle, or wears an attachment with a HUD. Just like "bingo!", it's there. I guess LL don't have many usability experts involved in the design of features.

Neither of these are really onerous requests - they're normal ways for HUDs to work. They're basic features!