llAttachToAvatar and HUDs

Heyos All,

Well, I'm in post release blues now. Much like many scripter-friendly releases in the past, I find myself pondering my existance and our newest attachment points. Of course, the docos are lacking any details, so I ponder to myself:

Without forcing the user to right click and attach a prim to their HUD, do we have any scriptual/runtime way to attach a HUD? I can deal with having to rez an object first then calling that standard, request for PERMISSION_ATTACH and llAttachToAvatar, but yet it appears there are no attachment points I can use.

Anyone have suggestable work arounds? What I seek to do is to make the user experience as user friendly as possible. The lease amount of clicks, right clicks and hoops for the user to use the content. I hate having to write novels for my users to enjoy the content, and specifically like making things easy enough to use that a newbie can enjoy it without almost any learning curve. All I simply want to do is attach progmatically to an avatar, a pre-rez is acceptable and the good'ol "blue dialog box of harrasment" is fine with me.

Thanks everyone,

Hey Trim Long time no see!

From the wiki, the attachment points seem to be called by number:

http://secondlife.com/badgeo/wakka.php?wakka=llAttachToAvatar

where:

31 HUD Center 2
32 HUD Top Right
33 HUD Top
34 HUD Top Left
35 HUD Center
36 HUD Bottom Left
37 HUD Bottom
38 HUD Bottom Right

lol, now my depression has passed Thank you Kris for being my daily dose of antidepressants


PS, Kris, have I told you recently, I LUV YA? Even if your a grouch!

Trimda, the implementation of HUDs is my current bug-bear I'm afraid, one of the reasons being the problem you highlight here. There's only one way to automatically do it, but it's messy:

Person sits in a vehicle, or whatever, and it rezzes the HUD, then tries to attach it to the avatar. But it won't work in no-build areas and the end user would end up with lots of the HUD objects in their inventory.

Francis has opted to give the user the HUD object to attach to themselves if they're not already wearing it, so that's another option.

Either way, it's hardly user-friendly.

You may want to look at the following threads about HUDs as well:

/54/b0/68003/1.html
/54/d7/67753/1.html

Whut?! *innocent*

Mpoof,

Yes, I was reading the other threads, and it seems to be a lack of friendlyness in the design. Another attachement useability issue is the fact that we can't attach objects owned by Person A to Person B, even if we have permission to do so (I've raised this one in the past).

This could make handing out UIs/HUDs much less complicated. Sure, a rez would be involved, but atleast if the owner has permission to rez the object on that land, it could autoattach properly. Even if the owner changes on attachment, it'd still be a workable solution. Imagine the possiblities, click on the object, it does a bit of chatter to get configured and boom, on the user's interface after the "blue box of harassment"

Hehe, guess its another subject for a Trimda-Rant (TM), but I'll save it for later No 10 page rants from me today

I try not to, that they won't be implemented gets me down

but... but... it says so right there on teh wiki! teh wiki lies?! my faith is shattered. my bible is a sham. who would do such a thing? *walks off shaking head dejectedly*

No, it doesn't lie, but in order to get the stage where it can be attached it has to rezzed first, request permissions etc. And it goes into the user's inventory..... *yawn* I know I'm starting to sound like a stuck record but the implementation sucks.

Yeah, I know. I sympathise. I tried playing around with it briefly, decided it was kinda cool but more trouble than it was worth and I'll wait for the rest of the implementation to be implemented

Well apparently this HUD feature had been in planning and specifying for a year, so I'm really suprised the implementation is so poor, and kind of don't hold out much hope for the near future. I'd love to be suprised though. I think they've almost totally missed the ball with HUDs - they're clunky currently.

Really? To me, it kinda feels like its slapped together really quickly. No attachment point constants for llAttachToAvatar, no rethink to "on-the-fly" changing of ownership for attaching objects to AVs for people other then the owner, more control over docking/default postioning, et cetra.

I love the concept, but the implementation reminds me XMLRPC, a half-way there solution to something that could be way more. Its almost as if no application study was done, where us as the consumers of the feature were polled, or if it was done, the wrong individuals were asked. Really, in my first few days of implementing on two projects I have, I'm having to make my consumers suffer for the lack of the implementations flexibility in its deployment.

-= Trimda-RANT ALERT =- (I'll keep it short )

Infact, I'd go as far to say this is another example of SL's and LL's design flaws that keep SL from really going bigtime. So far, the biggest comment I get from many non-addicts is that SL is just to clunky. One of the biggest issues on user-retention is the fact that the learning curve of SL is too steep for many. For a while, LL's marketing strategy was aimed at "Come to SL to prototype your games and test against a sample user base", it'd be allot easier if the tools provided allowed us a bit more control.

Having said this, once again, straight forward functionality has been omitted that would allow us as designers to make SL an easier place for our new and existing users. I'd almost recommend LL starts talking to us creators before designing what they think is best. Maybe we can help out with that instead of this current willy-nilly design process that currently exists.

We demand something, and LL does implement but implements something often not quite what we wanted or need. I do commend LL for listening, but I think they need to talk to those who use the tools everyday to see what may be the best was to make them come together.

In short, this all reminds me of XMLRPC, imho, SL's biggest feature flop ever. XMLRPC if fully implemented could have changed the way the grid looks today. True application intelligence, instead, we have only half of the tool it was billed to be. Now having said this, the HUD only makes second place in the biggest feature flop, for the fact its still somewhat useable, just chunky and a pain for end-users to use.

Eh, I've just given up on new scripting toys. I was really excited by 1.7 for the HUD stuff, but am now realizing the my dreams are only half met. Guess we need to get used to living inside the box LL provides and not try not to dream of the perfect LSL world I guess I'm just getting disgruntled with having to jump thru hoops if I want to try something innovative.

Trimda, I couldn't agree more. Whoever puts together the implementation designs is a techie and there appears to be no input from those with useability experience. That's asking for a system that's inaccessible, inconvenient and not suited to those who just want to come and enjoy the content. And without those being retained, what's the point in being a content creator?

They released LindeX to help content creators realise their Lindens into US$ (that was Philip's take, as he thought it would put more US$ into the hands of content creators - his big thing). The biggest thing he can do for content creators is give them features that are actually fit for the purpose. HUDs aren't yet, it's just not easy for the end user because of the attachment ridiculousness(!), or for the content creator because of the positioning ridiculousness and limitations caused through a flawed implementation.

Just my opinion.

no love for the wiki troll who dug the numbers out of the client and added them to the wiki?

Sorry Strife, thank you. Your addition is definitely appreciated.

I'm sorry Strife! Thank you soooo much. You've made me a Wiki beleiver now!