Changed Scale Alternative?

[Ruthven Ravenhurst]

I'm building a HUD, and was wondering if there's a way to detect if the root scale has changed other than with a changed event or a timer. I want the end user to be able to change the size of the root prim, and have it automatically changed the child prim sizes, local pos, and rotation. If i use CHANGED_SCALE, it gets triggered every time the script changes a child prim scale putting it into a loop. I don't want to have to use an un-necessary timer to only check for changes in the root prim size. I suppose I could build it into the touch event to check, but it also seems un-necessary to check every time it's clicked

[Innula Zenovka]

Off the top of my head, one way to avoid the loop when the script changes a child prim might be to do something like

	changed(integer change)
	{
		if(change & CHANGED_SCALE){
			if(llGetTime() > 2.0){
				llResetTime();
				//do stuff
			}
		}
	}

That's what I'd try first, anyway, if I were trying to solve that problem.

[Ruthven Ravenhurst]

ah, thanks, I'll try that

[arton Rotaru]

How about comparing the scale of the root in the changed event, and just do something if it's another size than before?

[Ruthven Ravenhurst]

29 minutes ago, arton Rotaru said:

How about comparing the scale of the root in the changed event, and just do something if it's another size than before?

I tried that too, it still was in an infinite loop, and the object ended up disappearing. maybe the server didn't like that?

Innula's method worked perfectly

[arton Rotaru]

9 minutes ago, Ruthven Willenov said:

I tried that too, it still was in an infinite loop, and the object ended up disappearing. maybe the server didn't like that?

That's odd. This works perfectly for me:
 

vector gvLastScale;

default
{
    state_entry()
    {
        gvLastScale = llGetScale();
    }
    
    changed(integer c)
    {
        if (c & CHANGED_SCALE)
        {
            if (llGetScale() != gvLastScale)
            { 
                gvLastScale = llGetScale(); 
                // do Stuff
            }
        }
    }
}

 

[Ruthven Ravenhurst]

4 minutes ago, arton Rotaru said:

That's odd. This works perfectly for me:
 

vector gvLastScale;

default
{
    state_entry()
    {
        gvLastScale = llGetScale();
    }
    
    changed(integer c)
    {
        if (c & CHANGED_SCALE)
        {
            if (llGetScale() != gvLastScale)
            { 
                gvLastScale = llGetScale(); 
                // do Stuff
            }
        }
    }
}

 

Oh I think I know what I did wrong *facepalm*, it was extremely late. Instead of comparing it to the last scale, I was comparing it to the default scale. So if I resized the root and change scale was triggered, until I set it back to the original scale, of course that would test TRUE, lol

[Lucia Nightfire]

These functions also make scaling simpler than looping through all links changing sizes, local positions and rotations.

http://wiki.secondlife.com/wiki/LlScaleByFactor

http://wiki.secondlife.com/wiki/LlGetMinScaleFactor

http://wiki.secondlife.com/wiki/LlGetMaxScaleFactor

[Ruthven Ravenhurst]

3 hours ago, Lucia Nightfire said:

These functions also make scaling simpler than looping through all links changing sizes, local positions and rotations.

http://wiki.secondlife.com/wiki/LlScaleByFactor

http://wiki.secondlife.com/wiki/LlGetMinScaleFactor

http://wiki.secondlife.com/wiki/LlGetMaxScaleFactor

Right, I was looking at that as well. I wanted the end user to be able to resize only the root prim (main panel) and then the others would be resized to fit. I thought about using this and making the HUD no mod

[Ivanova Shostakovich]

What is the functional goal of having the user cause these changes in HUD element scale, position and rotation?

[Ruthven Ravenhurst]

1 hour ago, Ivanova Shostakovich said:

What is the functional goal of having the user cause these changes in HUD element scale, position and rotation?

The rotation isn't really an issue. There's the main panel and tabs. Each tab also has sub-prims/mesh that rely on lining up with the texture on the tab to function correctly. There's a bit going on for each tab and it can take up a lot of screen space at the default size. On a smaller screen it might need to be made bigger to see what's going on, while on my larger 32inch monitor, I can make it smaller and still read it. I have already accounted for rotating the whole thing 90° on the Y axis for minimizing. I've actually already gotten it all figured out I believe.

[Lucia Nightfire]

It just doesn't sound intuitive or user friendly to have to turn on edit links and scale the root prim just so the rest of the link scales up or down by script. If they have can already scale the root by hand, wouldn't they just be able to scale the whole thing by hand? Am I missing something?

[Berksey]

As an experiment I took a fullperm linkset resizer script I got off the MP sometime last year, took out the touch event and replaced it with a listen, removed the "Delete Script" option from its menu, and added a button to one of my HUDs to call it when clicked. The result is a full-featured resize menu that scales every part of the HUD at the same time...

If you have or type up a good linkset resizer script, maybe this idea could help, but I don't know exactly how you want your stuff to work or if you're simply set on making it work the way you wanted from the start... I know how that can be too, just wanting to make it do what you want because it doesn't want to, lol.