Scripting for HUD's

I'm a builder and am new to scripting LSL, I am curently working on a HUD and have finished the build portion but need to add scripts. I have searched the wiki and the forums but haven't found what I'm looking for.

1/ can I move indivual peices of a linked primset? and if so can I do it by specifiying the name of the peice?
2/ can I move groups of prims in a linkset by giving them a sub-group name?
3/ what call do I use to get an avitars health level?

I will probably have a LOT more questions with this project and would apreciate any help I can get

Um ... looks like you need to start by getting a handle on LSL as a whole ...
Try:

http://wiki.secondlife.com/wiki/LSL_Portal

Or my preferred option:

http://lslwiki.net/lslwiki/wakka.php?wakka=HomePage

Nope quite a bit further on than that, what I'm after are the function calls themselves, and an explination as to wether what I have in mind is possible.

Points 1 and 2 I'm not sure about, I know that I can move indiviual peices about as I've been through the framation scripts and sortof figured out how the menu works, what I need to know is do I have to put a listener in each peice I want to move or can I refrence peices or linked sub-sets from the root prim?

Point 3 Combat attachment display user health above the avitar. What I don't know is the function to get that information. I know that in a damage enabled sim it apears on the top status bar but I would like to have that info available for use in my hud. Hence I need to know the function to get that info from the server. This throws up another question:
Is health in a combat HUD even related to health as displayed in a damage enabled sim?
As I have yet to come across an open source combat hud to work from I have no idea how they function.

Sorry I'm not a programmer so I might not be explaining this in the correct terminology. I can however read code and work out how and to some extent why it functions.

Hi Lucy

To communicate within a linked set use llMessageLinked, this is much quicker and one hell of a lot less laggy than having a listen in each prim in an object. On wiki's this is my prefered one

http://rpgstats.com/wiki/index.php?title=LlMessageLinked

Using messageLinked you can communicate accross all scripts in the object if you set it up correctly. You could use the 'string' parameter of the function to talk to prims based on their name, you could also reference them by their link number using the 'integer' parameter. It depends on what you are trying to achieve, and how you are doing it, as to which way is better. llGetObjectName, llGetLinkNumber are just two functions that maybe helpful in this. Personally I would deal with link numbers not names.

I don't know much about combat, but I don't think there is a function for returning the health statistic at the top of the screen. I think that all combat systems that do display a health status, typically in setText above the avi, use their own methods for determining and keeping track of health.

Hope thats of some help

1. Yes - commands like llSetLocalPos, llSetRot, and llSetLinkPrimitiveParams can be used to control the positions, etc, for all prims in a linkset

2. No, you can't move a set of prims as a group separate from the rest of the linkset. There is no way to flag them as being anything other than part of the main linkgroup. You would need to review the commands from above to move each prim individually.

3. Combat HUDs (the ones with the HP titler) do not use - normally - the true Avatar hitpoints as used in the client. When you are killed in a combat-enabled sim with normal weapons, you get TP'd home, combat HUDs are for a more involved combat where it keeps track of a HP bar of it's own invention and the weapons are scripted to report damages to this HUD to subtract from the number it has recorded. This means that the weapons for the combat system are normally proprietary - meaning that they will only work for that system.

These are mainly so that when you die, the HUD will be scripted to do something, such as run a death animation, and various other things dependant on the HUD creator's desire. Looks much better to have a 'frag fest' with dead bodies lying around rather than an empty tomb with people having to TP constantly to keep in the battle. Some HUDs even have power meters for special attacks and other things, and most record death/kill counts.

Specific to the "by name" thing: the individual prims will be referenced by their link number, either with llMessageLinked() or llSetLinkPrimitiveParams(). But it's possible to set up a kind of index of prim names to link numbers (sort of an "alist"--either a single strided list with "name, linknumber, name, linknumber..." or a pair of matched lists), populated by looping llGetLinkName() over llGetNumberOfPrims(). Or you can hunt for a specific link name with the same loop if it's an infrequent occurrence.

Thx Saskia, Tiarnalalon, and Qie thats helped a lot. I was hoping that their was a way to use the system health info but it will probably be easier to just use my own as you mentioned. I'll have a play around with you sugestions for linking see which is best suited to my build. No doubt I'll be back with more questions soon


Edit::: Erm ! how do I know which peice is which when they are linked? I have all the components grouped, and then linked to a container prim. How do I figure out which link number is which? is there a peice of code I can drop into a test peice to number them like the code for seeing which face is which on a prim?

If you just want to find out a prims link number in a linked set once, then you could create a new script in each prim with this code in it, then delete it afterwards


default
{
state_entry()
{
llOwnerSay("My link number is = " + (string)llGetLinkNumber());
}
}

This is only advisable if you are sure that the object will not get unlinked and then re-linked, since the link order will most likely be different once its re-linked.

Otherwise I would recommending using some method similar to Qie's suggestion on populating an index list.

If the link numbers could change, due to manual or scripted linking and unlinking, what you could do is something like this (not inworld at the moment, so just descriptive, not LSL):-


In each important part ("HealthPrim", "ManaPrim", whatever), have a script that listens for link-change event, and reports their name (or another known unique identifier), and a link-number (via llMessageLinked)

In the 'main script' that deals with these, have variables or a structured list (i.e. where you know index 0 will always be the HealthPrim, index 1 will be the ManaPrim etc). Whenever this script receives an update report, it looks at the name/identifier sent, and updates the relevant variable or list index.

This way, whenever you need to work with the Health (or Mana etc), you don't need to cross-reference a strided or double list, you can go straight to the variable-name, or list index.

Also, depending on how you need the information, you can use llGetLinkName(int). It returns the name of the prim with the passed in link number.

Normally, I use it when I want a single script to react to touch events on all linked prims (like navigation buttons on a vendor where I use llDetectedLinkNumer(int) to know which prim was touched).

string primName = llGetLinkName(1); //gets the name of the linked prim with linknumer=1


That's the best way if you have a link number, and want to know which prim it is.

If you want to go the other way, and those prims have their own scripts, and the link numbers might change, you also might look in more detail at llMessageLinked(). I often use the second parameter as a 'channel number', and have the child scripts only reacting to certain channel commands. I did a prize bank with 'deposit', 'withdrawal', and 'balance' channels for example. (Careful with this though....it could create a good bit of lag if overdone!)

Basically, there are loads of possibilities depending on what you are really trying to do! Grab a nice cup of tea, and a snack, and dive in to the wiki.

Another way to get the linknumbers without putting a script in each prim is to do this from the root:

default
{
touch_start(integer num_detected)
{
llOwnerSay("You touched linknum: " + (string)llDetectedLinkNumber(0));
}
}

Then, when you touch a prim, it will tell you which one you touched. But do it before putting other scripts in; if other scripts have a touch-event-handler, it will not send it to the root and this will not work right.

Did this on the fly, think I got it all right (I rely *so* heavily on my editor to check sytax!)

No quite true. If you put other scripts in other linked parts, you just have to include an llPassTouches(TRUE); statement in the other scripts.

wow! thx Baron, that works a treat I can see me making a lot of use of that little bit of code


Edit::: Next silly question some elements of the hud need to be hidden, origionaly my plan was to move them off screen when not in use. But I could swop the texture to a blank(transparent ) texture instead.

Which would be the more efficient as reguards resorces?

And should I preloading the textures when the hud is attached?

Just use llSetAlpha or llSetLinkAlpha 0.0 = hide & 1.0 = show

Just a caveat, if these pieces extend beyond the size/shape of your main HUD 'panel' and they are touch sensitive, they will cause a touch cursor when hovered over, even if they are fully alpha transparencied (someone correct me if i'm wrong) ... for those parts, having them slide/move out might be a better option.

Depending on their sizes, if you do have any such pieces of your HUD, moving them 'inside' your main HUD prim might be a better bet than moving them offscreen (since you don't know where someone might move the HUD's attach point to.

Luckly the parts I was thinking of moving are info bars and dont need to be touchable. Also because of they layout of the hud I will have to force it to the center atacment point, this will help cut down on the code for the "moving" parts as I won't have to allow for different atachment positions.

Actually, that's not quite true either, you only have to do this if the scripts in the child prims have touch events but you still want the touch event in the root to fire at the same time. Child prims will automatically pass touches no matter what their contents are unless they have their own script with a touch event.

True enough, but I was responding to the following:-



(minor editing on line breaks, since the bold didn't seem to want to work)