Sliding linked four parts door script

[ainst Composer]

7 minutes ago, Rolig Loon said:

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. 

 

7 minutes ago, Fenix Eldritch said:

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.

Awesome! Fantastic! You guys fabulous! Thank you so much!

But now the question how do i bring the doors back to original position?

[Fenix Eldritch]

Same way you moved them in the first place, another llSLPPF() call using values that negate the original movement. If you moved one locally by <0, 1, 0>, simply using <0, -1, 0> would effectively undo the original move.

How you trigger it can be done many ways, on touch (using a toggle variable to flip flop between opening and closing actions), or a timer are two examples.

Edited February 26, 2019 by Fenix Eldritch

[steph Arnott]

3 minutes ago, Fenix Eldritch said:

Same way you moved them in the first place, another llSLPPF() call using values that negate the original movement. If you moved one locally by <0, 1, 0>, simply using <0, -1, 0> would effectively undo the original move.

How you trigger it can be done many ways, on touch (using a toggle variable to flip flop between opening and closing actions), or a timer are two examples.

FLOATS not INTEGERS. <0.0, 1.0, 0.0>

[Fenix Eldritch]

It was a shorthand example, take it easy. Besides, if you're using literals, those will automatically get converted during compile time anyway. Variables are another matter.

Edited February 26, 2019 by Fenix Eldritch

[ainst Composer]

1 minute ago, Fenix Eldritch said:

It was a shorthand example, take it easy. And if you're using literals, those will automatically get converted during compile time.

But is there any way, maybe even a script with which i can find out these vectors?

[steph Arnott]

3 minutes ago, Fenix Eldritch said:

It was a shorthand example, take it easy. And if you're using literals, those will automatically get converted during compile time anyway. Variables are another matter.

It causes a convertion penalty. It also throws up errors. So no i will not take it easy. It is sloppy.

Edited February 26, 2019 by steph Arnott

[Fenix Eldritch]

Any extra work that must be done to convert an integer literal to a float literal is only incurred at compile time. Once the script is compiled, the conversion is not done again. I'm reasonably sure that's how compilers work. Similarly, the LSL compiler will accept a vector of integers and quietly convert it during compile time to a vector of floats without error or issue. Again, this is with literals. Variables are something else. If you have examples that say otherwise, please direct me to them. Otherwise I will say no more on this tangent.

8 minutes ago, ainst Composer said:

But is there any way, maybe even a script with which i can find out these vectors?

Sorry, I don't understand what is being asked. Can you rephrase?

Edited February 26, 2019 by Fenix Eldritch

[Wulfie Reanimator]

17 minutes ago, Fenix Eldritch said:

It was a shorthand example, take it easy. Besides, if you're using literals, those will automatically get converted during compile time anyway. Variables are another matter.

Stephy's just misunderstood some script error in the long lost past and attributed it to integer/float mixing, even though they are implicitly typecast as needed and wouldn't ever throw a script error. Even their holy Wiki reads: "If a function requires a float as a parameter, and the number is an integer (e.g. 5), you can add the .0 to clearly indicate it's a float, but omitting the .0 is equally valid and actually saves bytecode space in the compiled code."

14 minutes ago, ainst Composer said:

But is there any way, maybe even a script with which i can find out these vectors?

You could create a loop to show the position of each prim in the linkset (and then copypaste the values into your script) like this:
Though, if your linkset is more complex than the one you showed, you might need something a little more sophisticated.

default
{
    state_entry()
    {
        integer prim;
        while(++prim <= llGetNumberOfPrims())
        {
            list local_position = llGetLinkPrimitiveParams(prim, [PRIM_POS_LOCAL]);
            llOwnerSay((string)local_position);
        }
    }
}

Edited February 26, 2019 by Wulfie Reanimator

[steph Arnott]

5 minutes ago, Fenix Eldritch said:

 Once the script is compiled, the conversion is not done again.

Wrong, it is done every time it is called. The server converts it to a float every time. The compiler does not convert integers to floats.

[Fenix Eldritch]

I'm going to disagree with you and leave it at that. I do not wish to derail Ainst's thread with an argument of this subject. If you want to continue this side topic, feel free to message me.

Edited February 26, 2019 by Fenix Eldritch

[ainst Composer]

Thank you all so much! The script turned out just fantastic! Everything works great!!!

[steph Arnott]

4 minutes ago, Fenix Eldritch said:

I'm going to disagree with you and leave it at that. I do not wish to derail Ainst's thread with an argument of this subject. If you want to continue this side topic, feel free to message me.

You show me were a compiler changes anything in a script. That is not the function of a compiler, it does a basic syntax test, nothing more.

[steph Arnott]

22 minutes ago, Fenix Eldritch said:

Any extra work that must be done to convert an integer literal to a float literal is only incurred at compile time. Once the script is compiled, the conversion is not done again. I'm reasonably sure that's how compilers work. Similarly, the LSL compiler will accept a vector of integers and quietly convert it during compile time to a vector of floats without error or issue. Again, this is with literals. Variables are something else. If you have examples that say otherwise, please direct me to them. Otherwise I will say no more on this tangent.

Sorry, I don't understand what is being asked. Can you rephrase?

Laugh all you want. Compilers do not overwrite code.

[Fenix Eldritch]

*sigh* Fine, I'll bite. The OP's question appears answered anyhow. For an example of how compilers can (and do) modify code, refer to what implicit typecasting is. Here's one such example from the LSL wiki: http://wiki.secondlife.com/wiki/Typecast

Quote

To convert the type of a value a typecast is required. There are two types of typecasting, explicit and implicit. Explicit typecasts must be provided by the programmer, but implicit typecasts are put in place by the compiler. LSL implicitly typecasts strings to keys and integers to floats where the latter type is required but the former is provided.

 

[steph Arnott]

Just now, Fenix Eldritch said:

*sigh* Fine, I'll bite. The OP's question appears answered anyhow. For an example of how compilers can (and do) modify code, refer to what implicit typecasting is. Here's one such example from the LSL wiki: http://wiki.secondlife.com/wiki/Typecast

 

WRONG, compilers do not over write the code. It does a basic conformaty test then converts it into what a computer needs.  Your usage of integers instead of floats is converted every time the server come up against it. That causes extra memory. A compiler can be successfull and the server refuse its function. GOOD DAY.

[Fenix Eldritch]

Hold up. This all stemmed from you getting upset over an example of writing out a vector with integers vs floats. My comment was that is didn't matter if said vector was being used as a literal. As in not put into a variable, but typed straight into the code.

My reasoning was that saying something like llSetScale(<1,1,1>) is no different than llSetScale(<1.0,1.0,1.0>) because when the compiler is turning everything into bytecode, those two lines are static. There is no variable present, so they will never change. Thus, the compiler coverts that text to static bytecode which will always execute the same no matter what. No additional typecasting or whatever is done after the initial compile, because nothing in those two statements ever change.

That's what I was getting at. Anyhow, no hard feelings. Hope you have a good day too.

[steph Arnott]

1 minute ago, Fenix Eldritch said:

Hold up. This all stemmed from you getting upset over an example of writing out a vector with integers vs floats. My comment was that is didn't matter if said vector was being used as a literal. As in not put into a variable, but typed straight into the code.

My reasoning was that saying something like llSetScale(<1,1,1>) is no different than llSetScale(<1.0,1.0,1.0>) because when the compiler is turning everything into bytecode, those two lines are static. There is no variable present, so they will never change. Thus, the compiler coverts that text to static bytecode which will always execute the same no matter what. No additional typecasting or whatever is done after the initial compile, because nothing in those two statements ever change.

That's what I was getting at. Anyhow, no hard feelings. Hope you have a good day too.

Am not upset, you are a sloppy coder. You then make bogus claims. A script is NOT over written by the compiler. You introduce lag with your code. END.

[Qie Niangao]

I'll just observe in passing that there's no such thing in LSL as a vector of integers. By the time the compiler has a vector, it's got floats inside. (Surely we're not claiming the compiler waits until runtime to produce every literal vector. This may not be much of a compiler, but it's not an interpreter.)

Anyway, I'm just glad the OP has a solution. I was beginning to worry we'd have to turn even these little doors into Animesh. 😜

One little note about "maybe even a script with which i can find out these vectors" : If one can find a geometric representation of the two arrangements that expresses the component positions as a function of their dimensions (in this case, the distances they move in x and y correspond pretty straightforwardly to their x and y sizes), that's even better than recording the two arrangements as static sets of object positions. That sounds complicated, but in this case it's possible (with a little work) and that way the doors would move appropriately even after somebody resizes the whole linkset.

[ainst Composer]

//* script_starts_here
//
integer DOOR_PRIM = 2;   
integer DOOR_PRIM_2 = 3; 
integer DOOR_PRIM_3 = 4; 
integer DOOR_PRIM_4 = 5; 

integer run;
default
{
touch_start(integer num_detected)
{
if(run)
{
run = FALSE;
      llSetLinkPrimitiveParamsFast( DOOR_PRIM, [ PRIM_POS_LOCAL, <0.0,0.0,0.0>,
      PRIM_LINK_TARGET,DOOR_PRIM_2, PRIM_POS_LOCAL, <0.0,0.0,0.0>,
      PRIM_LINK_TARGET,DOOR_PRIM_3, PRIM_POS_LOCAL, <0.0,0.0,0.0>,
      PRIM_LINK_TARGET,DOOR_PRIM_4, PRIM_POS_LOCAL, <0.0,0.0,0.0>]);
}
else
{
run = TRUE;
      llSetLinkPrimitiveParamsFast( DOOR_PRIM, [ PRIM_POS_LOCAL, <0.0,0.0,0.0>,
      PRIM_LINK_TARGET,DOOR_PRIM_2, PRIM_POS_LOCAL, <0.0,0.0,0.0>,
      PRIM_LINK_TARGET,DOOR_PRIM_3, PRIM_POS_LOCAL, <0.0,0.0,0.0>,
      PRIM_LINK_TARGET,DOOR_PRIM_4, PRIM_POS_LOCAL, <0.0,0.0,0.0>]);
}
}
}
//* script_ends_here

Just replace with your values! Thank you again!