Any good solution to attaching UI from an in-world object?

So, we have these groovy new HUD attachments and it'd be nice for a user to be able to walk up to an in-world object, touch it, and immediately get its personal UI attached to their HUD.

Nice but impossible since I gathered that the "scripts can't attach to anything other than their owner, even though they can get permission" bug(?) is staying around in 1.7.

The only way I can think of doing this is to have a "client" object that the avatar keeps permanently attached (possibly not to UI). When touched, the in-world object asks if the av has a client. If they do, the client replies with its UUID, and the in-world object then "gives" its UI to the client. The client rezzes it as soon as it arrives, and the on_rez of the UI attaches it. But this seems very awkward - can anyone think of a better way?

Not sure, but isn't there a dialog for buying clothes that says something like "Wear clothing immediately after purchase"? Does that work for "clothing" that is comprised of a series of attachment? Like for a mech armor suit, for instance? My assumption, having never created something that uses that dialog, was that it would auto-attach any contents based on the attach-points the content creator specifies. Therefore, perhaps it can be used similarly for the new HUD attach points. Then to get the effect you're looking for I guess you'd have to set the contents for sale at $0 or something. And that is all assuming it works like I'm assuming it works. And we all know what happens when we make assumptions... We make an ass out of... umptions?? lol

I dunno, I'm at work as always so can't test the theory.

As far as I can tell, the "wear clothing" checkbox only works for things that are actually clothing or av parts. Attachments, as I recall, don't automatically attach with that box checked.

Mind you, I could be wrong, it's been a while since I used that feature.

That's what Strife and I are trying to make: an HUD attachment that acts as an inworld browser, which can display a complex shape from data sent to it by another object. the display is touch-sensitive and reacts just like hyperlinks on a Web browser, sending a new request to the object for more data to display.

So where can I get more information about using HUDs. Seems to be nothing on the Wiki or in the official website.

From what I've heard so far, more information—meaning published documentation—will be forthcoming.

This is what I've done with the Dominus Shadow project, as far as I can figure, it's the most elegant way of making sure the driver has a HUD.

New_Driver_Event() {
   ask on special chat channel, "hey does the driver have a HUD attachment?"
   if we get a reply
      initialize HUD
   if we don't get a reply
      I guess you don't have a hud. llGiveInventory( "HUD Attachment", driver )
      "Please attach that"
}

And of course, the HUD will broadcast a rendezvous message as soon as it's attached.

So the user is prompted through all the steps of getting their HUD up and running. It's not automatic, but there's a good deal of hand holding. It also doesn't need to assume they have anything already attached.

I've read your thread on that Jesrad. But that's a bit different from a UI controller for external systems. Your methods are cool for displaying data. But a display prim in your system is just that, a display prim. It won't be wired up to send messages to a game board or racecar, etc...

Yes it is The protocol has support for a form of RPC. Think "JavaScript / Flash" on your Web browser.
Anyway, even without that RPC it can display the velocity of your vehicle already or remote-control it, among other things

But of course it's less efficient than coding your own HUD display (except you have to code everything yourself)

Hmm... ok I missed that part then.

But yes, it does seem a bit more complicated than just using LSL to build your own HUD for your game/car/application. Unless maybe you abstract the complexities to a point it's more accessable to the masses? I dunno...

My impression on your protocol is that its true merits, where it will earn its dues, is as a complex display system rather than as a robust widget factory. Maybe I'm wrong.

Thanks, that's valuable input

As for the the original subject of the discussion, it's also possible to rez a HUD copy, previously set to sell as original for 0L$, and have it auto-attach when its owner changes (a matter of storing llGetOwner() and periodically comparing llGetOwner() to the stored value).

This would mean the person walks up to the object, touches it or interacts with it in some way, then the object checks for HUD and if none is found, rez a copy. Person then just buys the copy for 0 and it attaches.

Given the number of people doing this, would it be of benefit to develop some kind of standard convention for UI clients? So that people don't have to walk around wearing 10 different scripter's UI client attachments?

Yumi, this is EXACTLY what we're trying to make with TLTP/TLML One browser HUD attachment that works everywhere

Ah, well, it's all irrelevant now as there's no longer any way to transfer the UI or data to the client.

TLTP uses chat and email presently.

It exists?

http://secondlife.com/badgeo/wakka.php?wakka=exchangeTLTP
http://secondlife.com/badgeo/wakka.php?wakka=exchangeTLML

We are still in pre-alpha phase; we have many features we want to add but haven't finalized how to add them. The client found on TLML works with the chat server found on TLTP.

(nod) Oh, I didn't know if it was an actual thing yet or just a design document.