Script UI Elements
tracked
researched Resident
Second Life should implement Scripted UI as a modern replacement for prim-based HUDs. Prim HUDs have been a workaround for years, but they are outdated, inconsistent, and often visually clunky. A native Scripted UI system would remove the need for so many prim HUDs from circulation, reduce design fragmentation, and give creators a unified way to build interfaces that look and behave consistently across experiences. It would also improve the overall dialog box and UI presentation, making interactions cleaner, more readable, and more intuitive for residents.
This is a much-needed request because Second Life has evolved, but its UI ecosystem still feels fragmented. Right now, HUDs vary wildly in quality, layout, and usability, which creates confusion and visual inconsistency. A proper Scripted UI would help standardize controls, improve accessibility, and make content feel more polished and professional. It would also give creators more flexibility without forcing them to rely on awkward prim-heavy builds that are harder to manage, more cumbersome to maintain, and less visually cohesive.
It would also help retain new users. HUDs are one of the biggest things that new residents struggle to understand, and many end up needing someone to heavily guide them just to figure out basic interaction. A cleaner, built-in Scripted UI would make Second Life far more approachable, reduce that learning curve, and help new users feel less overwhelmed. That matters because first impressions are everything, and confusing HUD-based systems can make the platform feel harder to use than it needs to be.
Second Life already has a strong creative community, and a modern UI framework would empower that community instead of limiting it. If Linden Lab wants to improve user experience, reduce clutter, and keep the platform competitive and usable, Scripted UI is not just a nice feature, it is a necessary step forward.
Thanks to @hacker.Resident for this article. https://kathar.in/post/149846332570/lsl-ui
Photo Viewer
View photos in a modal
Log In
Lucia Nightfire
I was going to file a related feature request with a popular TPV and a $2000 bounty/reward for release, but two devs were less than enthusiastic about my JSON command 'bridge' between script and viewer approach and suggested an internal/existing data structure would be more ideal, so I scrapped it.
However convenient a themed look/skin might be to implement, we still need something that can create a theme in of itself. Something themed to the in-world application. Roblox offers this with their UI script assets, granted, pre-compiled at the experience level and through its own suite/studio.
The floater has to be able to allow data populating/depopulating, not just building.
Jenna Felton
Thank you researched Resident for opening the request and hacker Resident for commenting with an implementation idea.
I do agree, a framework allowing an easy and flexible interaction with the user which would also use the style of the viewer elements (and thus more intuitive to use) would be a serious improvement for the residents.
When the implementation goes in a direction of improved
llDialog
and llTextBox
then I'd ask to consider features these commands lack (in my opinion):- A way for the script to detect when the user ignored or even blocked the dialog so the script can close the listen and run a default reaction.
- This can happen for example when an other script in the same prim opened a dialog for the same listen channel. Data sent by the new dialog may be invalid for the first script. The first script must recognize this.
- A way for the script to close the dialog when the script stops awaiting the user input.
JoyofRLC Acker
Jenna Felton Good ideas. I like the idea of improving llDialog / llTextBox which may be faster than a whole new shiny UI (not saying that's not a good idea)
I have some half baked ideas that the pros can evaluate - I suspect they may lead to llDialog2. One of my suggested objectives is to simplify / reduce the amount of 'housekeeping' code the scripter has to write - one of my hobbyhorses is the amount such code we have to write, which is extra overhead for interpretation and not all of it is well written
- have a built-in time out (and auto close)
- consider using dialog_event() rather than chat responses that would signify which button was pressed (including ignore) , timeout, detach etc. so no need for user timer loops, or risk of dangling chat channels - its not clear to me why chat was used for signalling the response (it also clutters up the listen() event
- legacy button ordering or top down
- icons or text buttons (the kludge is to just recognise a texture key in the button list elements
- built-in scrolling for longer button lists
- visual options including transparent or semi transparent dialog box
Maestro Linden
marked this post as
tracked
hacker Resident
This exact thing was done almost 15 years ago but LL seems to not have wanted to implement it, hopefully by now they'd be more willing
relevant reading: https://kathar.in/post/149846332570/lsl-ui
researched Resident
hacker Resident Oh damn I had no idea, they have to bring it! At least they acknowledged prim HUDs are literally horrible and made the free Avatar Welcome Pack hudless to help new users, this would just make all huds way more consisent and understandable at first glance than any prim hud could do.