[#SVC-2367] llSetLinkText or a FLOATING_TEXT option for llSetLinkPrimitiveParams

2. Second Life Service - SVC

llSetLinkText or a FLOATING_TEXT option for llSetLinkPrimitiveParams

Created: 18/May/08 01:07 PM Updated: Yesterday 08:28 AM

Return to search

Component/s:

Scripts

Affects Version/s:

1.21.0 Server

Fix Version/s:

None

Issue Links:

Duplicate

This issue is original of duplicate:

SVC-3209 In the conquest to reduce the number of scripts in a linkset: new functions llSetLinkText and llLinkTargetOmega

~~MISC-2994~~ llSetLinkText - allow use of setting text to link prim

Relates

This issue Relates to:

MISC-268 LSL Features: llGetLink*()/llSetLink*() extensions

This issue is related to by:

SVC-3109 New constants/flags

SVC-4418 llGetPrimitiveParams is not returning the new SLICE values

SVC-301 Meta-issue: New LSL Functions

Description

« Hide

We have llSetLinkColour, llSetLinkTexture, llSetLinkPrimitiveParams, but we still cant set the floating text on another prim in the set without putting a script in it, thus forcing us to put scripts into child prims just to set the floating text.

I suggest two new commands :-

1) llSetLinkText(integer LinkNumber, string Text, vector Color, float Alpha);

2) llSetLinkPrimitiveParams to have a new command added [integer FLOATING_TEXT, string Text, vector Color, float Alpha]

The advantage of this is to lower the number of scripts in an object (especialy HUDs) which will make region crossings more stable, teleporting safer, and lower the script lag in a region because we dont need all those extra scripts just for setting the floating text.

---------------------------

Additionally we need the following commands to complete the floating text function set

string llGetText(key ID) <--- returns the floating text from the object properties.

when llGetLinkPrimitiveParams() is inplemented their should also be a matching command to read the text.

It should be noted that the ability to read the text will save memory and processing. A function can be assiged to a button in an object via the text it is showing, and then read back from the root prim in the touch event, without needing to store a list of which button had what text on it. Why store something a second time in the script when it is stored in the object already? All we need is the ability to read it back.

Darling.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Strife Onizuka added a comment - 18/May/08 01:19 PM

I think the right name would be PRIM_TEXT

[ Permlink | « Hide ]

Winter Ventura added a comment - 09/Jul/08 03:43 PM

regardless of what the constant is called, the function is truly desirable.

[ Permlink | « Hide ]

Nelson Jenkins added a comment - 12/Jul/08 09:08 AM

I don't think this feature will be implemented in the near future - it's not a major issue and, to be honest, would probably cause another wave of bugs that we wouldn't need to handle.

llSetText() modifies the prim's properties and isn't an active script function - same with llParticleSystem(). I'm pretty sure that this would help some scripters, but overall, the impact of 3, 5, or even 10 constantly passive scripts in an object is price Linden Labs is willing to pay to prevent adding more functions to LSL - especially during the Mono transition.

[ Permlink | « Hide ]

darling brody added a comment - 13/Jul/08 08:04 AM - edited

I think you are missing the point. In order to alter the floating text on a prim you need to have a script in the prim that will receive a link message, extract a string, vector, and float from the message and then set the text based on that information. Remember that link messages do not have support for vectors or floats, so there will have to be some kind of encoding method used that also costs script time. Add to this the need for the indevidual prims to sort all incomming link messages for those addressed to them and we have a lot more script time being used that a simple call to the suggested llSetLinkText().

You also need to take into account that even an idle script will take up script time in the region. A minimum of 0.02 seconds according to the estate tools. Common situations where we can all see a noticable benifit are malls full of vending machines, and avatars wearing HUDS.

I can not see any possible BUG that could come out of setting floating test.

Darling Brody

EDIT:
Every script in a prim, regardless of script size, take up 16k of memory. (64k in mono) This is significant when you are teleporting because the memory has to be allocated in the region you are teleporting to before you can arrive there. The more memory you need, the higher the probability there is of a failed teleport.

[ Permlink | « Hide ]

Ezian Ecksol added a comment - 13/Jul/08 10:56 AM - edited

>>llSetText() modifies the prim's properties and isn't an active script function - same with llParticleSystem().
But we have already e.g. llSetLinkColor or llSetLinkAlpha, which are prim properties, too.

Yes, I am tired, too, to place in every child of a HUD where I want to display text a script which is driven by a llMessageLinked.

And although the script is inactive most of the time, waiting for a linked message event, it still occupies some simulator memory for it's VM.

I think it would be not too difficult to implement this function, I dont see where it could influence other code so much that lot of new bugs would appear, maybe LL could at least implement it in the mono driven LSL.

[ Permlink | « Hide ]

Moon Metty added a comment - 04/Aug/08 01:47 PM

This would be a useful addition. Even if the llSetLinkText() needs a sleeptime.

Note: On the mono-simulator memory is handled dynamicly for both Mono and LSL scripts. Small scripts won't use a lot of memory

[ Permlink | « Hide ]

Cheshyr Pontchartrain added a comment - 08/Apr/09 04:39 PM - edited

This would be a very useful feature. I currently hack around it with link messages and a script in the target prim, but that is very wasteful. Especially post server 1.27 when memory limits are in place. The difference in script time on a simple color-coded radar are enormous. Up to 0.60ms using multiple prims, vs about 0.05ms with a single control script.

[ Permlink | « Hide ]

Kyra Vixen added a comment - 02/Jul/09 06:53 PM

Categorized feature request into 'scripts' component, as a new LSL function is being requested.

[ Permlink | « Hide ]

Kyrah Abattoir added a comment - 21/Nov/09 08:28 AM

It seems obvious, today there should be NO NEED for putting a script into a child prim unless for very specific reasons, wich to me does not include hover texts or particles.