Scripting Limit & Graphic/Button Heavy HUDs

Hey all,

I'm currently developing a HUD that is very heavy on separated graphical elements, such as buttons, number variables. This HUD will be featuring many pages also.

The way I am currently developing them is llSetPrimitiveParams for each object, as making it controlled through one object will cause delays and a slow transition of pages. Depending on the page, the objects are resized, repositioned and textured to make buttons, variables or hidden if not needed (consists of about 50 interchanging objects). These objects are commanded all through a click of the user and every prims reads the command and changes/stays the same (hidden) accordingly.

I haven't done my research with the script limit thing, but how will this effect me - if it will? I've noticed that people are putting focus on resizing prims for hair or prim clothing. So I'm a bit worried my project will be compromised.

If anyone can throw any advice my way (e.g. Don't do it that way, change it to this method once you need to, etc). It'd greatly be appreciated and lack of time wasting on my behalf.

Cheers.

Yes, they will affect you and your customers. I would very strongly suggest considering the new llDetected functions when possible, which you should be able to deploy from one script in the hud's root to tell which part of which child prim has been touched.

They include functions to tell you which part of a texture has been touched, so it might well be possible for you to cut down on the number of prims you're using as well as scripts by effecting your page changes by switching from one texture to another (I don't know, but it's a possibility I'd be considering).

Even if you decide to use multiple prims rather than textures, the llDetectedLinkNumber and llDetectedTouchFace will be very useful as, of course, will be the new llGetLinkPrimitiveParams and llSetLinkPrimitiveParamsNoDelay functions we've been promised to help us cut down on unnecessary scripts.

Theoretically, I think you could do it all with one script, at least if you wait for llGetLinkPrimitiveParams and llSetLinkPPNoDelay.

You can use functions like llSetLinkTexture, llSetLinkAlpha, llSetLinkColor and even llSetLocalRot to alter the look of HUD buttons instead of llSetLinkPrimitiveParams. The alternatives are much faster for a start. As Innualla suggests, detected functions like llDetectedlinkNumber, llDetectedTouchFace and llDetectedTouchUV will also help you get the most out of a few prims in a HUD. Playing with touches and timers can also alter the functionality of each button.

Any or all of those suggestions would work in a single script.

I guess this is obvious but use an obscure negative channel to communicate with the HUD-controlled object and pass your messages on to particular prims with llMessageLinked.

Very probably there are a lot of other useful functions and techniques besides but I am certain of those examples because I have used them myself and the extent of my scripting knowledge can be summarised on a postage stamp along with a very good recipe for baked hummus.

Nobody knows, despite the good advice above. The limits aren't even set to be announced for a month or two, then we'll have "several" months to see how they will affect us before they are enforced.

If you have to have multiple buttons... you can detect the buttons with this:

integer hudchan = 0; // for testing purposes
string buttonName;
default
{
    touch_start(integer num)
    {
        buttonName = (hudchan, llGetLinkName(llDetectedLinkNumber(0)));
    }
}

simply give each button a unique name and process the buttonName string from there.

So it's not even guarantee'd if it'll affect me like everyone's anticipating?

It's guaranteed, for instance, that if you use llSetLinkPrimitiveParams each scripted change will take 0.2 seconds.

It's guaranteed it will affect you and your customers. What isn't yet known is the extent to which it will affect you, because we don't yet know what the limits are.

It's almost certain to affect you indirectly because people will have to take into account how much your hud will contribute to their total script usage in assessing whether they want to use it; there are a couple of scripted devices I always wear that I don't want to take off if I can avoid it, so if wearing your hud takes me over the limit when I'm wearing both them and the hud, I probably won't be that interested in buying the hud.

But it may be that the limits are so generous I can easily afford to wear my cherished gadgets and your hud both... we just don't yet know.

Ephraim - Isn't that delay already set?

So, forgive me I'm a bit dull when it comes to this, scripts will not be limited, just the weak/useless scripts filtered out like particles/draw distance by the viewer? Isn't that the same concept of setting it so people can't see objects no bigger than 0.5m or something rediculous?

It's just really agitating to see that my hours of work will be wasted when I'm forced to replacing my button concept entirely with texture heavy Detected scripts which will take up even more time to recode.

The delay is set in llSetLinkPrimitiveParams, which is one reason for rescripting stuff with llSetLinkPrimitiveParamsNoDelay when it's available.

And as I understand it from what Babbage has been saying in his office hours, when it comes to attachments there will be a memory limit per avatar. It's not wholly clear yet how it's going to be enforced -- by disabling scripts that take you over the limit or just not letting you rez stuff that takes you over -- but one way or the other, there will be a fixed amount of script memory available to you, to be shared among your attachments as you want.

Put it like this, if you are planning on putting scripts in all your buttons and sending link messages you are considerably more likely to find your hud runs into problems (people will find they can't wear it unless first they take off their AO or Mystitool, perhaps, or they can wear it but it doesn't work unless they turn their AO off) than if you use Johan's suggestion -- which doesn't, of course, mean using textures, just detecting touches and controlling the prims differently.

Innuala has already answered but, my apologies, I got the thrust of your OP wrong in the first place.

From the general description of your project, I still think you would be well-advised to optimise your HUD with as many of those functions as you can efficiently use. Since the introduction of 'Top Scripts' (I think it's called) and the current proposal of limiting scripts per head, it certainly looks like creators will have to be much more careful about script efficiency, which is a very good thing in my opinion. However the limitations may work, it is very likely that residents will also become more critical of scripted devices when they can see the immediate effect they have on their avatars and home parcels. Not everyone will mind but a fair proportion will.

I understand that it must be a hassle to rehash your scripts but my impression is that you have already done most of the donkey work on planning and execution. The extra time spent tightening up on performance will pay dividends in this respect and reduce the likelihood of your HUD being viewed as a dud.

short version... it's gonna affect everyone... regardless...

slightly longer version.
if you are doing a lot of dynamic data display in the interface, you are going to hit more than if it's static data in the interface.

Years ago (before Mono & llSetLinkPrimitiveParams) I wrote a windowing api ontop of LSL, using prims to construct the controls. It was very versatile but slow. I hit two bottlenecks: Minimum event delay and memory limits. It had three layers of abstraction which turned into a lot of comms (hence the event delay problem). Because of the complexities of the code, Layer 1 could not be effectively divided nor could the event delay be effectively bypassed.

Layer 0: Scripted prims that made up the display
Layer 1: Prim allocator, simple control allocator & message router
Layer 2: Complex controls.
Layer 3: User code.

As you can imagine if I were doing this again today, I would do it very differently. With the increased memory of Mono, and llSetLinkPrimitiveParams it would have made it so much easier. For starters I wouldn't have to use every sneaky little trick I know for saving memory on bytecode which does nothing for readability. It would make the rez time required much faster as I could eliminate many of the slaves by using shared slave scripts with llSetLinkPrimitiveParams. I believe the min event delay has been halved in Mono which should make the chatty nature of it easier to deal with. The new llDetected* functions would eliminate many of the rows of buttons I had and other interface parts, reducing the number of prims required. If I were to rewrite it for now, it might actually be usable.

Another change would be to rework message routing so they wouldn't have to go through Layer 1. I would have done it in the original implementation but I lacked the memory to track that information in the higher Layers.