HuD Coding--Moving Prims

[Zandrae Nova]

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.

[KT Kingsley]

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 July 5, 2019 by KT Kingsley
Added links to LSL wiki

[Rolig Loon]

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. 

[Nalates Urriah]

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. 

[Mollymews]

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

[Wulfie Reanimator]

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 July 6, 2019 by Wulfie Reanimator