a faderbox/limiting free movement

Hello.

I just started learning scripting and i would like to get help/advice with the following project:

I am trying to create a faderbox

The controlling faders i've seen in-game, work by steps and i would like to know if i can do it another way.

My idea is to allow the fader to be moved(with edit), but limiting it's movement to one axis and certain ammounts of movement within that axis, just as a fader. Is that possible?

I suppose the other way would be to create a lot of steps, so the illusion that the fader moves smoothly; But, correct me if i am wrong, i won't be able to Drag it, and i will need to click on the different steps to make it moveto them.

So, mainly, what i want is a fader i can Drag

In the same project i wanted u to advice me to see if the idea is good to get the data out from the fader:
I wanted the fader (a single one) to take note of it's position on (i.e.) X axis when rezzed, and to substract it's current position within that axis(when dragged) to the rezzing position to provide an increasing/decreasing number from 0(zero) to a and use this increasing number as data to control the volume of a looping sound playing in another object not linked to it (i don't know how to do this part yet, what function shall i use to send the data to the other script?)


Xcuse me for the, prolly, too many questions in one post and thank you very much in advanced.

There are two different ways to accomplish what you want to do.
if you want to move the object via edit mode, you can restrict its movement using a timer that constantly checks its position and corrects it when the object is dragged off of its path.

If you want a more elegant solution, use touch events to move your object. When STATUS_BLOCK_GRAB is set to TRUE (via llSetStatus), llDetectedGrab can be called within a touch() event to detect where the user's arrow is dragging the object. You can then correct this position value (so its on the object's axis) and then change the object's position accordingly, to create the illusion of dragging the object on a set path.

Hope this helps!
==Chris

thanks for replying.

Will the user notice the correcting position process in the form of sudden movemets¿

As if i drag the object quickly to one non-permitted axis, will it correct position after or before i visually see the object moving to the non-permitted position?

Would it be easier to simply block the movement when it detects going to a nonpermitted axis/point instead of correcting it?

This won't work on edit mode , true? (what's the flag for preventing edit mode)

thanks again

With the former solution (the timer), yes, you will actually see the position correction. For the latter solution, since the position change happens after the script recieves the drag data, you wont see the correction.

Edit mode correction only works for the timer solution, you'll still be able to drag the object off of its path using edit mode using the llDetectedGrab (latter) solution. I think it would actually be better to use the llDetectedGrab solution since you might want to move the object once in awhile.


The llDetectedGrab solution does this.


Only the timer solution works with correcting edit mode changes. The llDetectedGrab only works when the user is dragging the object outside of edit mode.


Anytime

Blocking movement on axises seems a quite difficult task, but it seems u can block rotation on axises using flags.... this lead me to think a knobbox would be easier to make than the faderbox.

But... can i drag+rotate a prim outside edit mode ???

If the answer is NO, would be there any workaround... like:

1-we fix the knob in it's place so it can be rotated on an axis but not dragged around

2-we attach a box to it, a box that can be dragged around but it's phisically linked to the knob

3-when we drag the box it makes the knob to rotate.

With my actual understanding of SL scripts and building i kinda think this is not possible, but what do u think ?

Edit: anyway i still trying the other way, wich i am understanding better right now

float top = 28.0; //The position of your top height in meters
float bottom = 25.0; //The position of your bottom height in meters
integer numSteps = 10; //The number of steps between the two
key agent = ""; //Initialized. Used to block others' control attempts
default
{
    state_entry()
    {
        llSetTouchText("Use"); //Sets touch text
        llSetStatus(STATUS_BLOCK_GRAB,TRUE); //Since we don't use grab...
        llSetStatus(STATUS_PHANTOM,TRUE); //...and don't need to be blown away
    }
    touch_start(integer total_number)
    {
        if(agent == "") //If we have no agent
        {
            agent = llDetectedKey(0); //Get one
            llMoveToTarget(llGetPos(),0.3); //Move initially to where we are
            llSetStatus(STATUS_PHYSICS,TRUE); //And go physical
            llSetTimerEvent(60.0); //In case someone goes AFK at the helm
            llRequestPermissions(agent,PERMISSION_TAKE_CONTROLS);
            //So when we touch it, we need to get permissions
            llSetTouchText("In Use"); //Change our touch text
        }
        else //if we have an agent...
        llWhisper(0,"Error: " + llKey2Name(agent) + " is already using this slider."); //Say so
    }
    run_time_permissions(integer perm)
    {
        if(perm) //If we have permissions...
        {
            llTakeControls(CONTROL_UP | CONTROL_DOWN | CONTROL_LBUTTON, TRUE, FALSE); //Take controls of the user touching it
        }
        else  //If we don't...
        llSetTimerEvent(0.1); //Reset the slider
    }
    control(key id, integer level, integer edge) //So when a key is pressed...
    { //Trigger this event
        vector pos = llGetPos(); //Our initial position
        if(level & CONTROL_UP) //If we wish to move up...
        {
            if(pos.z < top) //And we're below the top... 
            pos.z += (top - bottom) / numSteps; //Move up by step value
            else pos.z = top; //Otherwise stay at the top
            llSetTimerEvent(60.0); //And reset our timer
        }
        else if(level & CONTROL_DOWN) //If we're moving down...
        {
            if(pos.z > bottom) //And we're above the bottom...
            pos.z -= (top - bottom) / numSteps; //Do so by step value
            else pos.z = bottom; //Otherwise stay at the bottom
            llSetTimerEvent(60.0); //And reset our timer
        }
        else if(level & CONTROL_LBUTTON) //If we click the mouse...
        {
            llSetTimerEvent(0.1); //It means we're done with this switch
        }
        llMoveToTarget(pos,0.3); //Reset our movement position anyway
        //Note you can then compare your pos.z to your bottom or top to get
        //where your slider is
    }
    timer()
    { //When the timer is called, either by waiting too long or user-pressed
        llReleaseControls(); //Release controls of the user
        llSetStatus(STATUS_PHYSICS,FALSE); //Shut off physics
        llStopMoveToTarget(); //Stop moving anywhere
        agent = ""; //And remove our agent
        llSetTouchText("Use"); //Reset our touch text
    }
}

Much cleaner, simpler solution in my opinion. Plus this will move smoothly, stay within bounds without correction, and give you easier values to work with.

I do so enjoy commenting like it's a narrative.

Thank u, it has a bug tho.. somewhere, i am trying to find... sometimes it won't move at all.. it uses to happen if i am using it, left click to release... and in a short time someone tries to use it..... it won't move... (i added a whisper position on the timer event and it stills giving it's position each time u press fly up/down buttons, but it won't move)

Ah yes, that. I don't think it's a bug with the script's design, if that's what you're wondering - merely a bug/feature with how llTakeControls works with avatars that are not bound to the object with the script. As far as I can tell, after idling X number of seconds, controls auto-release in this situation.

So if this happens, just wait for the script to unlock or fiddle with the reset timer. I would appreciate any advice regarding editting this behavior, though, beyond simply using llTakeControls/llReleaseControls as written.