Sliding linked four parts door script

[ainst Composer]

Hello! I need to create four parts linked to house sliding door like on picture. all parts move frome one position in the linkset to another. 

Any suggestions greatly appreciated!

[steph Arnott]

If you slide them it is likely to judder horribly. Use the scale function. http://wiki.secondlife.com/wiki/LlSetScale

[ainst Composer]

1 hour ago, steph Arnott said:

If you slide them it is likely to judder horribly. Use the scale function. http://wiki.secondlife.com/wiki/LlSetScale

Hello! Thanks very much for your answer!

You see this sliding effect is required...

llSetPos(llGetPos() + <0.0,0.0,10.0>);  <<< сan I use it for this?

and it doesn't seem to work if I link the door to the house.

(It can even be 4 scripts for each part so that they work simultaneously.)

Edited February 26, 2019 by ainst Composer

[steph Arnott]

1 minute ago, ainst Composer said:

Hello! Thanks very much for your answer!

You see this sliding effect is required...

llSetPos(llGetPos() + <0.0,0.0,10.0>);  <<< сan I use it for this?

(It can even be 4 scripts for each part so that they work simultaneously.)

Yes, but it not vey realistic viewing wise. You can set the shrink to be a percievable movement rather than a snap, snap movement.

[Fenix Eldritch]

llSetScale() by itself only affects the single prim in which the script resides - which means if you were to use that, you'd need a script for each prim of the door, plus additional logic to synchronize everything.

Instead of that, I would suggest you look at llSetLinkPrimitiveParamsFast(). This single command can be used to target each child prim at the same time with just one command using the LINK_TARGET for each child. And using its other constant PRIM_SIZE which is equivalent to llSetScale.

Edited February 26, 2019 by Fenix Eldritch

[steph Arnott]

1 minute ago, Fenix Eldritch said:

llSetScale() by itself only affects the single prim in which the script resides - which means if you were yo use that, you'd need a script for each prim of the door, plus additional logic to synchronize everything.

Instead of that, I would suggest you look at llSetLinkPrimitiveParamsFast(). This single command can be used to target each child prim at the same time with just one command using the LINK_TARGET. And using its other constant PRIM_SIZE which is equivalent to llSetScale.

Which the server has to calculate. One prim with a basic texture applied is all that is needed. The shrink can be time linited to get a plausable closure.

[ainst Composer]

6 minutes ago, Fenix Eldritch said:

llSetScale() by itself only affects the single prim in which the script resides - which means if you were yo use that, you'd need a script for each prim of the door, plus additional logic to synchronize everything.

Instead of that, I would suggest you look at llSetLinkPrimitiveParamsFast(). This single command can be used to target each child prim at the same time with just one command using the LINK_TARGET for each child. And using its other constant PRIM_SIZE which is equivalent to llSetScale.

 

2 minutes ago, steph Arnott said:

Which the server has to calculate. One prim with a basic texture applied is all that is needed. The shrink can be time linited to get a plausable closure.

But will this affect texture (shrink / stretch)?

[steph Arnott]

1 minute ago, ainst Composer said:

 

But will this affect texture (shrink / stretch)?

You shift the text offset.

[Fenix Eldritch]

I don't understand what you are saying, Steph. The server has to make calculations in either case.

llSetScale(<1.0,1.0,1.0>) and llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SCALE, <1.0,1.0,1.0>]) are functionally the same, are they not?

[steph Arnott]

13 minutes ago, Fenix Eldritch said:

I don't understand what you are saying, Steph. The server has to make calculations in either case.

llSetScale(<1.0,1.0,1.0>) and llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SCALE, <1.0,1.0,1.0>]) are functionally the same, are they not?

Trying to get it to one prim and not multiple. The door does not need to be four.

Edited February 26, 2019 by steph Arnott

[ainst Composer]

2 minutes ago, steph Arnott said:

You shift the text offset. 

 

2 minutes ago, Fenix Eldritch said:

I don't understand what you are saying, Steph. The server has to make calculations in either case.

llSetScale(<1.0,1.0,1.0>) and llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SCALE, <1.0,1.0,1.0>]) are functionally the same, are they not?

the parts themselves should not stretch or shrink, they simply move to another position behind each other.

[Fenix Eldritch]

Ok, I see what happened now. It wasn't clear that you were suggesting the OP switch to using a single prim instead of four.

My response was under the assumption that the OP wanted to keep using the four prim design. In which case, llSetLinkPrimitiveParamsFast  would be a viable option to move all four prims at once.

Edit: and if you don't want to stretch/shrink the scale, you can alter the prims' offsets instead using the same function.

Edited February 26, 2019 by Fenix Eldritch

[Rolig Loon]

So just do as Fenix suggests. Write a single SLPPF statement that combines commands for each prim (using PRIM_LINK_TARGET) and moves the link with an offset in both X and Y, as appropriate.  It's very straightforward.  You can put your script into any part of the linkset, including the house that the entire door is linked to.

[steph Arnott]

4 minutes ago, Rolig Loon said:

So just do as Fenix suggests. Write a single SLPPF statement that combines commands for each prim (using PRIM_LINK_TARGET) and moves the link with an offset in both X and Y, as appropriate.  It's very straightforward.  You can put your script into any part of the linkset, including the house that the entire door is linked to.

Does not change the fact four prims is three more than needed. RL mech in SL is a pointless endevour.

[ainst Composer]

6 minutes ago, Rolig Loon said:

So just do as Fenix suggests. Write a single SLPPF statement that combines commands for each prim (using PRIM_LINK_TARGET) and moves the link with an offset in both X and Y, as appropriate.  It's very straightforward.  You can put your script into any part of the linkset, including the house that the entire door is linked to.

So i started with something like this:

default
{
    touch_start(integer num_detected)
    {
        llSetLinkPrimitiveParamsFast(LINK_SET, [PRIM_LINK_TARGET,
                            PRIM_POS_LOCAL]);
    }
}

 

[ainst Composer]

2 minutes ago, steph Arnott said:

Does not change the fact four prims is three more than needed. RL mech in SL is a pointless endevour.

I absolutely agree with you but I was asked to do just that

[steph Arnott]

1 minute ago, ainst Composer said:

I absolutely agree with you but I was asked to do just that

What people ask is 99% based on not knowing a more conservative way.

[Fenix Eldritch]

I think it's a matter of taste... Yes, fewer prims are generally preferable, but perhaps the OP wants the aesthetics of a four-paneled sliding door. 4 vs 1 is relatively low in terms of impact, and from a Land Impact perspective, you can knock that down to 2 if you change the prims to use convex hull.

 

As for using the command, do note that the list follows the format "CONSTANT, value". So PRIM_LINK_TARGET must be followed by the actual link number you want to target. And PRIM_POS_LOCAL must be followed by the vector of the new position you wish to apply. And all elements in the list are comma separated.

Edited February 26, 2019 by Fenix Eldritch

[steph Arnott]

1 minute ago, Fenix Eldritch said:

I think it's a matter of taste... Yes, fewer prims are generally preferable, but perhaps the OP wants the aesthetics of a four-paneled sliding door. 4 vs 1 is relatively low in terms of impact, and from a Land Impact perspective, you can knock that down to 2 if you change the prims to use convex hull.

 

As for using the command, do note that the list follows the format "CONSTANT, value". So PRIM_LINK_TARGET must be followed by the actual link number you want to target. And PRIM_POS_LOCAL must be followed by the vector of the new position you which to apply. And all elements in the list are comma separated.

Four prims to many on a limit is a real issue to them. They want a fifty prim look on a two prim object.

[ainst Composer]

11 minutes ago, Fenix Eldritch said:

I think it's a matter of taste... Yes, fewer prims are generally preferable, but perhaps the OP wants the aesthetics of a four-paneled sliding door. 4 vs 1 is relatively low in terms of impact, and from a Land Impact perspective, you can knock that down to 2 if you change the prims to use convex hull.

 

As for using the command, do note that the list follows the format "CONSTANT, value". So PRIM_LINK_TARGET must be followed by the actual link number you want to target. And PRIM_POS_LOCAL must be followed by the vector of the new position you which to apply. And all elements in the list are comma separated.

integer DOOR_PRIM = 2;   
integer DOOR_PRIM_2 = 3; 
integer DOOR_PRIM_3 = 4; 
integer DOOR_PRIM_4 = 5; 

default
{
    touch_start(integer num_detected)
    {
    llSetLinkPrimitiveParamsFast( 
    DOOR_PRIM,  PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,0,0>,
    DOOR_PRIM_2,PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,0,0>,
    DOOR_PRIM_3,PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,0,0>,
    DOOR_PRIM_4,PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,0,0>]);
    }
}

I did something incomprehensible

[Fenix Eldritch]

Close, the format is a little off, and you're missing the start of the list "["

llSLPPF() takes two inputs, a link number and a list of stuff to alter. That format must be adhered to, so your first link number can be the first prim of your target set. Then the list starts, so your first entry would be the prim pos local keyword followed by the value to apply - for that first child prim (DOOR_PRIM in this case). Then after that, you get into the pattern of specifying additional prim link targets, the attribute keyword, and the associated value, etc, etc.

llSetLinkPrimitiveParamsFast( DOOR_PRIM, [ PRIM_POS_LOCAL, <0,0,0>,
      PRIM_LINK_TARGET,DOOR_PRIM_2, PRIM_POS_LOCAL, <0,0,0>,
      PRIM_LINK_TARGET,DOOR_PRIM_3, PRIM_POS_LOCAL, <0,0,0>,
      PRIM_LINK_TARGET,DOOR_PRIM_4, PRIM_POS_LOCAL, <0,0,0>]);

 

Edited February 26, 2019 by Fenix Eldritch
goofed up the order

[ainst Composer]

31 minutes ago, Fenix Eldritch said:

Close, the format is a little off, and you're missing the start of the list "["

llSLPPF() takes two inputs, a link number and a list of stuff to alter. That format must be adhered to, so your first link number can be the first prim of your target set. Then the list starts, so your first entry would be the prim pos local keyword followed by the value to apply - for that first child prim (DOOR_PRIM in this case). Then after that, you get into the pattern of specifying additional prim link targets, the attribute keyword, and the associated value, etc, etc.

llSetLinkPrimitiveParamsFast( DOOR_PRIM, [
      PRIM_POS_LOCAL, <0,0,0>,
      DOOR_PRIM_2,PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,0,0>,
      DOOR_PRIM_3,PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,0,0>,
      DOOR_PRIM_4,PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,0,0>]);

 

    When i make it:

  llSetLinkPrimitiveParamsFast( DOOR_PRIM, [
      PRIM_POS_LOCAL, <0,1,0>,
      DOOR_PRIM_2,PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,2,0>,
      DOOR_PRIM_3,PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,3,0>,
      DOOR_PRIM_4,PRIM_LINK_TARGET, PRIM_POS_LOCAL, <0,4,0>]);

it acts this way, only first prim moves, and whole link set jumps up a little and disappears after a while.

[ainst Composer]

and it becomes physical, temporary and phantom, i see why it jumps - its physical, because of my clicks

Edited February 26, 2019 by ainst Composer

[Rolig Loon]

That's because the order of parameters in the list is wrong.  Refer to the LSL wiki:.  It should be

llSetLinkPrimitiveParamsFast( DOOR_PRIM, [
      PRIM_LINK_TARGET, DOOR_PRIM_2,PRIM_POS_LOCAL, <0,0,0>,
      PRIM_LINK_TARGET, DOOR_PRIM_3,PRIM_POS_LOCAL, <0,0,0>,
      PRIM_LINK_TARGET, DOOR_PRIM_4,PRIM_POS_LOCAL, <0,0,0>]);

Using the correct offset vectors, of course. 

Edited February 26, 2019 by Rolig Loon

[Fenix Eldritch]

Sorry, I had an error in my previous post. I had incorrectly posted my example with things in the wrong order. I did edit it, but I might not have been fast enough. Re-check my post and try what's currently there.