Jump to content

Sliding linked four parts door script


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

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

Recommended Posts

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 by ainst Composer
Link to post
Share on other sites
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.

  • Thanks 1
Link to post
Share on other sites

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 by Fenix Eldritch
  • Like 1
  • Thanks 2
Link to post
Share on other sites
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.

  • Thanks 1
Link to post
Share on other sites
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)?

Link to post
Share on other sites
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 by steph Arnott
  • Thanks 1
Link to post
Share on other sites
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.

Snapshot_001.png

Snapshot_002.png

Link to post
Share on other sites

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 by Fenix Eldritch
  • Thanks 1
Link to post
Share on other sites

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.

  • Thanks 1
Link to post
Share on other sites
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.

  • Thanks 1
Link to post
Share on other sites
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]);
    }
}

 

Link to post
Share on other sites

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 by Fenix Eldritch
  • Thanks 1
Link to post
Share on other sites
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.

  • Thanks 1
Link to post
Share on other sites
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

Link to post
Share on other sites

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 by Fenix Eldritch
goofed up the order
  • Thanks 1
Link to post
Share on other sites
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.

ezgif.com-video-to-gif.gif

Link to post
Share on other sites

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 by Rolig Loon
  • Thanks 1
Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 775 days.

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...