Jump to content

Locking objects/LSL


Cam Chattoway
 Share

You are about to reply to a thread that has been inactive for 1100 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

18 minutes ago, Major Hijinks said:

Hi, locking objects, does it affect scripts or just position? I've been locking en masse, but don't know, tho I've not encountered problems yet.

It may affect the "state of variables" and performance of the script , so the performances of the sim )  . ( depending about what does the script ) 

For instance , if the script does

( while llGetPos() != target ) 

{ ... doing some stuff ..

}

, it never ends when you lock them 

Edited by redpurple Carpaccio
  • Like 1
Link to comment
Share on other sites

Locking an object only prevents anyone from editing it directly.

Scripts will still function normally without any limitation.

Lock this, the object will simply move up and down one meter while rotating, changing color, and updating hovertext:

default
{
    state_entry()
    {
        integer dir = 1;
        while (TRUE)
        {
            llSetPos(llGetPos() + <0, 0, dir>);
            llSetRot(<dir, 0, 0, 1>);
            llSetColor(<0, 0, dir>, -1);
            llSetText((string)dir, <1,1,1>, 1);
            dir = -dir;
        }
    }
}

 

  • Like 3
  • Confused 1
Link to comment
Share on other sites

24 minutes ago, Wulfie Reanimator said:

Locking an object only prevents anyone from editing it directly.

Scripts will still function normally without any limitation.

Lock this, the object will simply move up and down one meter while rotating, changing color, and updating hovertext:

 

Wrong : you are messing between moves by itself and moves by anything else .

Locking moves exist in the tab edition of the object

That s why your specific script is not affected , because it moves by itself . But it doesn t demonstrate that any scripts are not affected 

For instance , is the function llPushObject works for a target locked ?  No 

Edited by redpurple Carpaccio
  • Confused 1
Link to comment
Share on other sites

Even if locking an object were to break llPushObject() (not sure I believe that, but I'll take it as a given)  I can't really imagine anything you would want to lock having that function in its script.

 

Edited by Quistessa
Link to comment
Share on other sites

3 minutes ago, Quistessa said:

Even if locking an object were to break llPushObject() (not sure I believe that, but I'll take it as a given)  I can't really imagine anything you would want to lock having that function in its script.

 

You do a sophism and bad logic here :

the OP has asked if there is some risk . So Even if 1000 objects don t use llPushobject , the ones who are using llPUshobject are enough to affirm there is a risk 

By the way , i have quoted llPushObject , but other instances exist too 

Link to comment
Share on other sites

and you're using logic where logic isn't what was asked for. is it possible that making something locked will break a script? maybe. Should the OP stop locking things? Probably not, because from everyone else's experience the reward is much greater than the negligible risk.

  • Like 1
Link to comment
Share on other sites

5 minutes ago, Quistessa said:

and you're using logic where logic isn't what was asked for. is it possible that making something locked will break a script? maybe. Should the OP stop locking things? Probably not, because from everyone else's experience the reward is much greater than the negligible risk.

You do again a sophism : you have YOUR own experience of SL , and you make the hypotheis  that YOUR experience is the same than others . In reality this hypothesis is often false 

Link to comment
Share on other sites

2 minutes ago, redpurple Carpaccio said:

You do again a sophism : you have YOUR own experience of SL , and you make the hypotheis  that YOUR experience is the same than others . In reality this hypothesis is often false 

At which point did you mistake this thread for an argument that needed to be won ?

Link to comment
Share on other sites

1 minute ago, Coffee Pancake said:

At which point did you mistake this thread for an argument that needed to be won ?

When a post does some desinformation , it s normal to fix it .

The goal is not a contest or a competition , but the truth 

In addition , when someone admits him(her)self (s)he didn t know what did llpushobject , but dares to tell his(her) personnal opinion , is it someone who has written for the search of the truth , or the "need to win"  ?

Hunt the trolls

Link to comment
Share on other sites

45 minutes ago, redpurple Carpaccio said:

You do a sophism and bad logic here :

the OP has asked if there is some risk . So Even if 1000 objects don t use llPushobject , the ones who are using llPUshobject are enough to affirm there is a risk 

By the way , i have quoted llPushObject , but other instances exist too 

llPushObject is not affected by locking an object.

default
{
    state_entry()
    {
        llSetTimerEvent(1);
    }

    timer()
    {
        llPushObject(llGetKey(), <0,0,2 * llGetMass()>, <0,0,0>, FALSE);
    }
}

I think you should take a step back and calm down. Come back with something that actually is affected by locking an object.

  • Like 2
Link to comment
Share on other sites

It s affected .. 

The target is affected

default
{


    touch_start(integer total_number)
    {
        llSensor("Object", NULL_KEY, ACTIVE , 20, PI );
    }
    sensor(integer n)
    {
        llOwnerSay("push");
        llPushObject(llDetectedKey(0), <0,0, 100> * llGetObjectMass(llDetectedKey(0)) , ZERO_VECTOR, TRUE );
    }
}

By the way , i am calm . and rationnal

Edited by redpurple Carpaccio
  • Haha 1
Link to comment
Share on other sites

22 minutes ago, redpurple Carpaccio said:

It s affected .. 

The target is affected


default
{


    touch_start(integer total_number)
    {
        llSensor("Object", NULL_KEY, ACTIVE , 20, PI );
    }
    sensor(integer n)
    {
        llOwnerSay("push");
        llPushObject(llDetectedKey(0), <0,0, 100> * llGetObjectMass(llDetectedKey(0)) , ZERO_VECTOR, TRUE );
    }
}

By the way , i am calm . and rationnal

Now we have something useful, thanks.

Something worth noting, though: The target object, even when locked, does move with llPushObject. It's visually observable, and the locked object's script will receive moving_start and moving_end events. As I was recording a video to demonstrate this, I caught something even more important. The target object was actually pushed as normal, once, before going back to just nudges.

https://puu.sh/Hsca9/a81f61d282.mp4

  • Like 1
Link to comment
Share on other sites

1 hour ago, redpurple Carpaccio said:

It s affected .. 

The target is affected






default
{


    touch_start(integer total_number)
    {
        llSensor("Object", NULL_KEY, ACTIVE , 20, PI );
    }
    sensor(integer n)
    {
        llOwnerSay("push");
        llPushObject(llDetectedKey(0), <0,0, 100> * llGetObjectMass(llDetectedKey(0)) , ZERO_VECTOR, TRUE );
    }
}

 

this behaviour is by design, a locked object cannot be moved re-positioned by an external process

a thing about physical objects that are locked is that they remain and act physically. What happens is that when they are pushed or bumped by another object they do attempt to move in the direction of the push, but the server returns them to the locked position

can see this behaviour by rezz a sphere, set it to Physical and then set it to Locked. Then bump it with our avatar

edit add:

a use case for doing this is when we make a physical bouncing balls display and we script the balls to bounce in some pattern. When we set the balls to Locked then an external object (like an avatar or another person's bullets) can't overly-disrupt the display

crossed out the use case as is no longer the case. See below

Edited by Mollymews
re-positioned
  • Thanks 1
Link to comment
Share on other sites

38 minutes ago, Wulfie Reanimator said:

Now we have something useful, thanks.

Something worth noting, though: The target object, even when locked, does move with llPushObject. It's visually observable, and the locked object's script will receive moving_start and moving_end events. As I was recording a video to demonstrate this, I caught something even more important. The target object was actually pushed as normal, once, before going back to just nudges.

https://puu.sh/Hsca9/a81f61d282.mp4

Thank you . It s incorrect to affirm that the objects move as expected when they are tagged "move locked" . It was just a cancel of the movement by an opposed force , so it gives this impression of "shaking". A bit as the hovering functions who tries to cancel the gravity by an opposed force . A cleaner cancel is to set the gravity to 0

In addition , it shows something inconsistent 

 

It demonstrates too than flagging the physicle objects to "lock move"  continue to consume some physical ressources ( in fact it doubles the physical calls to havor in applying a force and its opposite ) and is bad for performance for the sim 

Edited by redpurple Carpaccio
  • Like 2
Link to comment
Share on other sites

i had a quick play

am not sure if is just me, but at Plum sandbox when I stick any active script in a physical Locked object then the Locked property won't stop the object from being moved by an external force. It will tho for non-scripted physical objects

Link to comment
Share on other sites

25 minutes ago, Mollymews said:

i had a quick play

am not sure if is just me, but at Plum sandbox when I stick any active script in a physical Locked object then the Locked property won't stop the object from being moved by an external force. It will tho for non-scripted physical objects

It depends  : dragging the physical  object tagged "locked move" looks blocked  , but if you drag a physical object without scripts and you try to collide it strongly against the object tagged "locked move" without scripts , inconsistantly , the tagged object moves 

If an avatar collides against a physical   tagged object ( with or without scripts ) , it continues to move

An another point : when the physical object is tagged "lock move" is in suspension in height - with or without scripts ) , and you leave the editor window , the object falls. It doesn t bounce , but it falls 

 

 

Edited by redpurple Carpaccio
Link to comment
Share on other sites

7 minutes ago, redpurple Carpaccio said:

An another point : when the object is tagged "lock move" is in suspension in height , and you leaves the editor window , the object falls. It doesn t bounce , but it falls

at Plum Sandbox when do this then the Locked object (active script or not) when dropped in this way, will roll down any slope (ground or prim)

i think that what we can say is that any scripted physical object can be moved by an external inworld force even when it is Locked

Link to comment
Share on other sites

37 minutes ago, Mollymews said:

i had a quick play

am not sure if is just me, but at Plum sandbox when I stick any active script in a physical Locked object then the Locked property won't stop the object from being moved by an external force. It will tho for non-scripted physical objects

Redoing the test with my own script has similar results, locked object has no scripts but has the same result with scripts:

https://puu.sh/HsdB5/b38174bd97.mp4

default
{
    touch_start(integer total_number)
    {
        key locked_physical_object = "2ed2e1be-f998-62cb-76d4-6ced55c6b1f0";
        llPushObject(locked_physical_object, <0,0,1000>, <0,0,0>, FALSE);
        llOwnerSay("Push");
    }
}

 

Edited by Wulfie Reanimator
  • Thanks 1
Link to comment
Share on other sites

8 minutes ago, Mollymews said:

at Plum Sandbox when do this then the Locked object (active script or not) when dropped in this way, will roll down any slope (ground or prim)

i think that what we can say is that any scripted physical object can be moved by an external inworld force even when it is Locked

So , there is someting unclear : normally this tag should lock the moves , but it doesn t lock the physical moves , and the scripts using physical functions look alterated 

Maybe someone could tell : "it s the same than llSetStatus(STATUS_BLOCK_GRAB )",  but it s wrong . When there is call to this function by script  , it doesn t change the tag in the building editor 

Edited by redpurple Carpaccio
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1100 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...