Locking objects/LSL

[Cam Chattoway]

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.

[redpurple Carpaccio]

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 March 24, 2021 by redpurple Carpaccio

[Coffee Pancake]

Locking the floor of my house / work area was about the only practical use I ever had for this ... and even then, the hilarity of accidentally deleting it sending everyone tumbling to the region floor was often worth the inconvenience.

[Wulfie Reanimator]

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;
        }
    }
}

 

[LittleMe Jewell]

I am absolutely horrid about hitting the Delete key with my mouse focus on the wrong item, thus almost everything at my home is Locked.  Nothing ever has any scripting issues due to it.

Edited March 24, 2021 by LittleMe Jewell

[redpurple Carpaccio]

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 March 24, 2021 by redpurple Carpaccio

[Quistess Alpha]

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 March 24, 2021 by Quistessa

[redpurple Carpaccio]

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 

[Quistess Alpha]

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.

[redpurple Carpaccio]

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 

[LittleMe Jewell]

Oh FFS -- How about this:

Most of the time you should be able to lock stuff without any negative impact, however there are some cases where it **might** cause an issue, depending on the scripts that are running in the items you have locked.

 

[Coffee Pancake]

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 ?

[redpurple Carpaccio]

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

[Coffee Pancake]

You're gonna fit right in here.

[Wulfie Reanimator]

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.

[redpurple Carpaccio]

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 March 24, 2021 by redpurple Carpaccio

[Nova Convair]

Locking adds an additional "are you sure?" dialogue for destructive operations and prevents movement - when editing. It has nothing to do with scripts.

I don't use it - I have backups. But everything is linked so that makes it easy :D

[Wulfie Reanimator]

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

[Mollymews]

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 March 24, 2021 by Mollymews
re-positioned

[redpurple Carpaccio]

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 March 24, 2021 by redpurple Carpaccio

[Mollymews]

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

[redpurple Carpaccio]

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 March 24, 2021 by redpurple Carpaccio

[Mollymews]

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

[Wulfie Reanimator]

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 March 24, 2021 by Wulfie Reanimator

[redpurple Carpaccio]

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 March 24, 2021 by redpurple Carpaccio