Jump to content
Zanpyr

HuD Coding--Moving Prims

Recommended Posts

So I've begun making items on Second Life but I found that the number of variations I've made are such that a HUD is ideal.

 

Unfortunately, I need to move groups of elements on the HUD around (backwards and forwards on the x axis) and I'm not sure exactly how to do this.

What I have:

A HUD, prim buttons including for textures. The buttons for textures work. Each texture button has a unique name button_### and there are roughly five pages of them and likely more in the future--link numbers may change as the thing evolves so I am weary about link numbers.

What I want to do:

Quote

When user presses button, if thisGroup of buttons is not at x axis position p, move them to p and move buttons in thisOtherGroup and thisOtherGroupTwo backwards to pos q if they aren't already there.

I'm new to LSL, but I am familiar with Python, Java, Lua, C/C++/C#, and Ruby so I'm not totally clueless but I'm not sure what to do exactly.

Share this post


Link to post
Share on other sites
Posted (edited)

Re changeable link numbers: use llGetNumberOfPrims and loop through them checking their names with llGetLinkName (counter) and storing the link numbers in variables or in a list.

Re moving linked prims: use llSetLinkPrimitiveParamsFast with the link number and PRIM_POS_LOCAL. You can combine all the prim position changes into one list, selecting different links with PRIM_LINK_TARGET.

Edited by KT Kingsley
Added links to LSL wiki

Share this post


Link to post
Share on other sites

Yes,  always refer to links by name rather than by number.  The system that KT suggests is straightforward and simple,  and it gets around the problem you have identified.

For your main question... you may want to consider making a separate texture for each set of your buttons and then defining "hot" areas on each texture for your buttons in that set.  Use llDetectedTouchST to determine which button the user touched. That reduces the number of prims that you have to keep track of and it also solves your problem of how to switch from one set of buttons to another.  Instead of moving a child prim's X coordinate,  just change the texture that's displayed. 

Of course,  if you really do want to move child prims around,  take KT's advice. 

Share this post


Link to post
Share on other sites

If you name the buttons consecutively you can avoid looping through to build a names list. You'll already know the names.

You might name the buttons to create groups then loop through the group. e.g., button-a-###button-b-###, etc. Process buttons-a from 001 to last.

I try to think of ways to avoid creating lists that consume memory. You have to decide on speed versus memory consumption. You can process small list pretty quickly with loops.

Another way to tackle the pages problem, assuming you use a cube for the HUD, is rotate the cube. Using each face of the cube will give you six pages of controls. You could also use multiple cubes to make changeable parts of the interface just rotating the parts that need to change.

Buttons versus texture touch... I use Rolig's idea in some of my stuff to reduce HUD prim count. I think for a large number of buttons or controls texture-touch is too tedious to script. Even for the few buttons I put on my HUD I wrote a script to help me with the texture coordinates. If you have to rearrange buttons the scripting changes are a major pain. 

Share this post


Link to post
Share on other sites
43 minutes ago, Nalates Urriah said:

If you name the buttons consecutively you can avoid looping through to build a names list. You'll already know the names.

i agree with  this

typically do the loop to get the names while we are developing our HUD.  When our HUD is tested and works correctly, then re-link it all into production presentation order. Go thru and optimize the script - which includes adding the names into the list with the code editor and removing the run-time loop which would no longer be necessary

Share this post


Link to post
Share on other sites
Posted (edited)

Last time I wrote a bit of code to move the whole HUD to the side besides one button (the last link, I believe), I just did this:

list positions = llGetLinkPrimitiveParams(1, [
    PRIM_LINK_TARGET, 1, PRIM_POS_LOCAL,
    PRIM_LINK_TARGET, 2, PRIM_POS_LOCAL,
    PRIM_LINK_TARGET, 3, PRIM_POS_LOCAL,
    PRIM_LINK_TARGET, 4, PRIM_POS_LOCAL
]);

llSetLinkPrimitiveParamsFast(1, [
    PRIM_LINK_TARGET, 1, PRIM_POS_LOCAL, <0.5,0,0> + llList2Vector(positions, 0),
    PRIM_LINK_TARGET, 2, PRIM_POS_LOCAL, <0.5,0,0> + llList2Vector(positions, 1),
    PRIM_LINK_TARGET, 3, PRIM_POS_LOCAL, <0.5,0,0> + llList2Vector(positions, 2),
    PRIM_LINK_TARGET, 4, PRIM_POS_LOCAL, <0.5,0,0> + llList2Vector(positions, 3)
]);

The first PRIM_LINK_TARGET is redundant, yes, but much prettier and less painful to edit. It's simple and it works.

Edited by Wulfie Reanimator
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...