From Second Life Wiki
Jump to navigation Jump to search

JIRA New Feature llGetText

Here's a first draft. Good to go? Ready to add near after logging in with the usual Second Life name & password? Yes/ no/ almost? -- Ppaatt Lynagh 20:55, 1 November 2007 (PDT)

PROJECT = MISC (chosen from VWR SVX WEB MISC Eventlet Mulib CertifiedHTTP)

ISSUE TYPE = New Feature (chosen from Bug, New Feature)

SUMMARY = A function named llGetText should exist to tell the script calling llSetText if the script is or is not changing the floating text of the prim.

PRIORITY = Normal (chosen from Showstopper, Critical, Major, Normal, Small)

COMPONENT/S = Unknown (chosen from Unknown, Miscellaneous)

AFFECTS VERSION/S = Unknown (not editable)

LINDEN LAB ISSUE ID = (intentionally left blank)



A function named llGetText should exist to tell the script calling llSetText if the script is or is not changing the floating text of the prim. For example, llGetText could return a list of four results: [text, color, alpha, font].

This specific need to add llGetText to LSL illustrates a general design principle. LSL should define a way to get back everything it sets. Otherwise one script cannot discover if another script has set a property. For example, a script cannot see if an object has been labeled for sale, given a custom label, or given no label at all as its floating text. As another example, an instance of an editor script cannot show the operator if the operator has set the property thru another script instance.


PATCH ATTACHED = (intentionally left blank)

SOURCE VERSION = (intentionally left blank)


I think it should point to a JIRA feature suggestion but I'm not feeling inspired enough to write one up. -- Strife Onizuka 12:55, 29 October 2007 (PDT)

Thanks for making time to say so. I didn't know that. Now that I do, I'll volunteer me to research and then publish an article here that invites our audience to contribute to JIRA also. Writing up the JIRA entry for llGetText will be my first example, unless another among us beats me to it. -- Ppaatt Lynagh 13:07, 29 October 2007 (PDT)
User:Strife_Onizuka > > Bug Reporting 101 may be relevant. -- Ppaatt Lynagh 13:16, 29 October 2007 (PDT)
Wow that mess of a web of pages near Bug Reporting 101 is nearly indecipherable. might be the first step that those too many words recommend. As of this moment, llSetText finds hits, llGetText finds no hits, confirming Strife's idea that we should add llGetText. -- Ppaatt Lynagh 20:26, 1 November 2007 (PDT)


I regret that there were so many edits, it's the first time I've contributed content to this Wiki, and am still learning the formatting. Thanks for understanding. It would help if there were a generic page with the formatting already in place that users could edit -- there may be one somewhere, but I haven't found it yet. -- Rich

Don't worry about the number of edits. Just look around at the syntax used on other pages, it's the easiest way. Strife Onizuka 04:54, 8 February 2007 (PST)
With the exception of editing actual template code (as opposed to code that uses templates), the "Show Preview" button will allow you to keep an eye on your changes without committing them to the article :-)
SignpostMarv Martin 05:36, 8 February 2007 (PST)

Different colors in the displayed text?

I recently saw some RPG engine that lets people have colored health bars in the hovertext above their head.

Is there a way to specify colors for individual text characters, or are they doing this by stacking up several llSetText prims, each showing only one color? Scalar Tardis 20:25, 25 March 2008 (PDT)

Stacking. -- Strife Onizuka 15:19, 26 March 2008 (PDT)

llSetText for storage

Regarding the caveat "Do not rely on Floating Text as a storage medium; it is neither secure nor finalized." I'm wondering how necessary some of this is as a caveat anymore?

I'm not aware of the text limit for hover-text having changed in a long time, and even if it were to change that's an argument for checking that any stored data is the length you expect it to be (e.g- store expected length first). The main argument against storage is the lack of security, but the same is true of using prim descriptions, which are also commonly used for storage that can survive resets.

I often use invisible set-text to store short pieces of persistent data that I need to survive resets (but which I'm not concerned about being inspected), while leaving descriptions free for users to change manually (as I like to use descriptions for specifying prim-properties that a script can load, such as allowing a script to change all prims with the "primary" keyword). Obviously pushing the limits of either isn't a great idea, but short text should be fine in both so long as it's nothing sensitive, so I'm wondering if the caveats should be updated to reflect that? The caveats for this page could probably use a cleanup in general actually, as things like clearing text could do with being in examples I think. --Haravikk 01:58, 12 January 2016 (PST)

New Information

Need to add a caveat about llGetDesc


llSetText doesn't parse llGetDesc properly and can't parse line breaks or other string escapes

Please see Category:LSL_String#Escape_Codes for an explanation of what is going on. --ObviousAltIsObvious Resident (talk) 16:45, 29 January 2016 (PST)