is there a linkset door opening script?

[Britt32 Beck]

Hello all, 

I'm looking for a script (or a way) to have a swinging linkset for a door (Not joined objects). Example: I have a door as an object and a handle as a separate object. I need to link them, then have them swing open or closed together. The only door scripts i've tried will not swing multiple linked objects, it only swings the primary object leaving all other objects in the linkset in its original place. 

Does anyone know of a door script that supports this? I don't want to waste more money on them only to find out it does not work. 

 

Thanks for your time!

Britt

Edited December 22, 2019 by Britt32 Beck
spelling

[Mollymews]

for a multi-part door then is the most simple when the door is its own object. Meaning that the door parts are linked together and are not linked to the rest of the build

when so then the example script posted here by Innula Zenokova (March 19, 2017) will get you started for a door that swings on the Z axis

https://community.secondlife.com/forums/topic/338230-options-for-scripting-doors/

[Britt32 Beck]

Thanks. But I'm not seeing what I'm looking for there. the door needs to have an object linked to it swing open with the door. Think of a ketchup bottle on the door shelf of a refrigerator door. Every script I have tried will leave the ketchup bottle in its original place while the door swings open. (Ketchup bottle is linked to door with script, linkset is then linked to hinge)

 

[Mollymews]

16 minutes ago, Britt32 Beck said:

Thanks. But I'm not seeing what I'm looking for there. the door needs to have an object linked to it swing open with the door. Think of a ketchup bottle on the door shelf of a refrigerator door. Every script I have tried will leave the ketchup bottle in its original place while the door swings open. (Ketchup bottle is linked to door with script, linkset is then linked to hinge)

 

this is the script

integer intSwing =90;
rotation rotSwing;
vector vOffset;

default{    

	state_entry(){
		rotSwing = llEuler2Rot(<0.0,0.0,(float)intSwing>*DEG_TO_RAD);  //90 degrees on the z axis       
		vector size = llGetScale();       
		vOffset = <(size.x*-0.5),(size.y*-0.5),0.0>;//open away from someone standing in front of face 2 -- that is, in front of the prim -- hinged on the left.    
	}    

		touch_start(integer total_number){
		list l = llGetPrimitiveParams([PRIM_POS_LOCAL,PRIM_ROT_LOCAL]);
		vector v = llList2Vector(l,0);
		rotation r = llList2Rot(l,1);
		llSetPrimitiveParams([PRIM_POS_LOCAL,v+(vOffset-vOffset * rotSwing)*r,PRIM_ROT_LOCAL,rotSwing*r]);
		
		rotSwing.s*=-1;             
	}
}

is best to test this script to understand how it works

test:

1) make a door out of two prims.  One to represent the door, the second to represent the door handle
2) link them together so that the door prim is the root prim (linkset)
3) drop the script into the root prim contents
4) compile and save the script
5) touch the door

result:

the door will swing on the Z axis. The Z axis being at vOffset from the center of the linkset

[Britt32 Beck]

So that worked until i linked the linkset door to the frame. at that point, only the root prim swung open and it left the linked object in place. 

 

 

[Chic Aeon]

It seems like if this was possible we would see it inworld and as far as I know we do not.  I look forward to reading the replies though :D.  

[Mollymews]

Britt, yes. Is why you will find in many builds with doors made of multiple prims the door is not linked to the building

there are two ways to deal with this

1) Make the door as a single mesh object in an external program like Blender and upload it. Being a single object then the script will work as is, even when linked as you have seen

2) swing the door and the handle as individual objects around the axis. This is doable but we can get visual issues when the region is lagging. The place to begin with this kind of solution is  llSetLinkPrimitiveParamsFast()  http://wiki.secondlife.com/wiki/LlSetLinkPrimitiveParams#llSetLinkPrimitiveParams

example:

llSetLinkPrimitiveParamsFast(...theDoorLinkNumber..., [PRIM_POS_LOCAL,v+(vOffset-vOffset * rotSwing)*r,PRIM_ROT_LOCAL,rotSwing*r]);
llSetLinkPrimitiveParamsFast(...theDoorHandleLinkNumber..., [PRIM_POS_LOCAL,v+(vOffset-vOffset * rotSwing)*r,PRIM_ROT_LOCAL,rotSwing*r]);

 

edit add.  Don't do 2).  Is a terrible way to this. I have just included it  to show how it has to be done when not 1) and when linked to a door frame

edit more. We can get some visual improvements using llSetLinkPrimitiveParamsFast in one call with PRIM_LINK_TARGET for the door and a second PRIM_LINK_TARGET for the door handle.  Is still a terrible way to do it tho

Edited December 22, 2019 by Mollymews
b

[Britt32 Beck]

Hi Molly / Chic, the bigger issue preventing me from uploading the objects as a single object from blender is that i need all objects to be available for texture changing, independently. 

Having the door not linked to anything is not an option for me as this is for a piece of furniture that will be in an upcoming event (please note that this is not for a door, and it actually needs to swing on the x axis, upwards.. much like an oven door)

 

The solution may not even be in the door script, but rather a texture changer. Which would bring up a question that probably needs its own thread and that would be a texture changing script that can handle a crap load of faces on one object.

 

 

 

 

[MaxMare]

I can`t help with scripting part, but I can recommend script that solved my problems

 KoolDOOR script 

It`s super easy to set up, works for doors, windows, cabinets, drawers and no matter which way or how you want them to open/close, this script does it in just a few clicks...It also allows your build to be linked, it works with resize script as well as texturing HUDs etc...btw the link is for builders version, but if you just need one for personal use, there is a cheaper option.

Regarding texturing scripts, I use BOSH Material Changer cause it allows me to change not just texture but materials for each face..It has tons of options integrated in one single script and seller/creator is extremely helpful

Hope this helps!

[Britt32 Beck]

Hey Max, Thanks for the recommendations,  I reached out to the creator of the Kool Door script with my needs to make sure it is something it can handle. Will post back here once he answers. (not that i don't believe you, it's just an expensive script and I want to be certain it will work. Otherwise, it will end up in the pile of door scripts I've already wasted money on 🤪)

Edited December 22, 2019 by Britt32 Beck

[Chic Aeon]

10 hours ago, Britt32 Beck said:

Hi Molly / Chic, the bigger issue preventing me from uploading the objects as a single object from blender is that i need all objects to be available for texture changing, independently. 

Having the door not linked to anything is not an option for me as this is for a piece of furniture that will be in an upcoming event (please note that this is not for a door, and it actually needs to swing on the x axis, upwards.. much like an oven door)

 

The solution may not even be in the door script, but rather a texture changer. Which would bring up a question that probably needs its own thread and that would be a texture changing script that can handle a crap load of faces on one object.

 

 

 

 

As long as you don't have more than 8 materials (the maximum for SL) in your JOINED (all in one mesh) object you can easily change the texture faces for that material with a texture change script -- each "face" calls a texture for that assigned material. You can even make some parts invisible by using a transparent texture.  You can also limit the number of textures AFTER baking (if you bake of course) by reassigning the materials to the already baked texture.  So that would be a very easy fix in most cases.

 

Also note that there are some door scripts (smooth door scripts) that cause major issues in houses. That won't affect your project but might for someone else reading this :D.    

 

Good luck. 

[Rolig Loon]

14 hours ago, Chic Aeon said:

It seems like if this was possible we would see it inworld and as far as I know we do not.  I look forward to reading the replies though

It's quite doable, as Molly showed in her response.  I disagree somewhat with her conclusion that her suggested solution is

14 hours ago, Mollymews said:

a terrible way to this.

It really adds very little complexity to Innula's basic script above ^^, and shouldn't result in visual issues when the region is lagging, especially if you combine the two SLPPF statements into a single one and use PRIM_LINK_TARGET.  This is exactly how I would normally approach the OP's challenge.  The optimal solution, of course, would still be to create the door and its hardware as a single mesh object, but that's often not reasonable.

BTW, I should add the standard advice that this forum isn't the best place to look for scripts that someone else has written. This is a forum for scripters to share ideas and moan about their frustrations with scripts they are working on.  The best places to look for finished scripts are the Marketplace, the Wanted forum, and the many script libraries in world and on the Internet. And if you want to hire a scripter, try the InWorld Employment forum.

[Chic Aeon]

50 minutes ago, Rolig Loon said:

It's quite doable, as Molly showed in her response.

Why isn't it used more often then?  I honestly can't remember seeing a "door" or any other hinged object that was multiple prim.  One answer of course is the land impact and maybe that is the underlying reason we don't see it often.  In the case of the OP, just doing the texture change on a single mesh object seems to be the best answer.   As we all know I am NOT a script person :D. 

[Rolig Loon]

2 minutes ago, Chic Aeon said:

Why isn't it used more often then? 

Scripters have been handling multiprim doors this way for ages, but I suspect it's more common in custom doors (which are the only doors that I script these days), because you have to factor in the local position and rotation of each prim in the linkset.  Not long ago, Innula and I were comparing notes about how we each got started in LSL scripting.  It turns out that we were each initially intrigued by how to make doors work.  I remember Void Singer teaching me how to handle multiprim doors well before LL gave us the ability to mess with local positions and rotations in llSetLinkPrimitiveParams, which makes it relatively "easy" now.

[Mollymews]

adding to the discussion

i am biased against this approach mostly because of how I personally prefer doors to work for myself

while I do put Touch to open/close in my doors I much prefer doors that open/close on collision. I like to be able to walk into doors so I don't have to stop walking. I only put Touch in my doors as a convenience for a visitor who might have an expectation that doors open on_touch

for collision to work as quickly as I want then I don't do incremental-step swings in my own doors. I go from 0 to 80 degrees in one call and go with the client side visual effect of the one-step swing. Unlike a scripted incremental-step swing of say: 0 > 20 > 40 > 60 > 80 degrees

as when we have an incremental-step swing then when the door is non-phantom we can get batted off our walking path by the door when it swings towards us, because it is opening to slowly. The batting can be ameliorated by setting the door prim to phantom on_open, and setting it to non-phantom on_close

an aside which is important I think in this kind of discussion. An advantage of the incremental-step swing is that the LINK_PRIM_TARGET approach can be more visually viable, than does the single-step swing. The door prim and the handle prim travel distance on each step is a lot shorter than the big one-step travel. From the client side pov multiple prims moving together visually look to stick together better, when the server side nominated travel distance is shorter    

but, and this but is where it becomes about wants. Adding in a phantom|non-phantom switch means more code. When it comes to scripting my own stuff then the least amount of typing the better. Which tbh is the root of my bias. I am a lazy scripter. Lazy in the added sense that I prefer my scripts to be lazy also - lazy meaning the least amount of work on both my own part and the part of the script to meet my expectation/want

in another thread there is a chat about styles of houses. And I made a example house old school out of prims. Which I put out on my parcel for anyone who wants to use it to help inform themselves of how this can be done

in the house I used a single object mesh door - the only non-prim component of the build. I thought about just using a single prim door with painted on door handles, but that can be a little bit naff looking depending on the texturing. So went with a mesh door

the included door script is an example of how I mean lazy. Is a mod of the quoted above Void Singer - Innula Zenokova door/swing script. A mod for this specific door for this specific house

the mod I post here, so that will hopefully be a bit more clear by what I mean by lazy

// script is from Void Singer with mods Innula Zenovka, then mods me Molly

rotation rot = <0.00000, 0.00000, 0.64279, 0.76604>;
vector axis;

swing()
{
    rotation r = llGetLocalRot();         
    llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_POS_LOCAL, llGetLocalPos() + (axis - axis * rot) * r, PRIM_ROT_LOCAL, rot * r]);
    rot.s *= -1;
    llSetTimerEvent(30.0 * (float)(rot.s < 0.0));    
}

default
{    
    state_entry()    
    {
        vector s = llGetScale();       
        axis = <s.x * -0.5, s.y * -0.25, 0.0>;
   }    

    touch_start(integer total_number)    
    {         
        swing();
    }
   
    collision_start(integer total_number)
    {
        swing();
    }
     
    timer()
    {
        swing();
    }
}

the house has a back door as well. So the only change I made to the script for the back door was this line:

rotation rot = <0.00000, 0.00000, -0.76604, 0.64279>;

in the original script 'rot' is calculated from 'intSwing' set in degrees, which can be a bit more easily read/understood. But like I mention, my scripts tend to be lazy. These particular doors for this particular house don't need to calculate 'rot' when it already knows what that should be

Edited December 23, 2019 by Mollymews
be

[Mollymews]

10 hours ago, Chic Aeon said:

Why isn't it used more often then?

i don't remember now the release timing dates of SLPPF vs Mesh. I think tho the release of each was pretty close together. Before SLPPF then it wasn't always viable to do puppeteering with linked prims because of the SLPP() 0.2 delay

and because mesh came about the same time-ish (maybe even before) then things like linked prim doors and windows kinda fell by the wayside. Except in the custom cases that Rolig is mentioning

things falling away also include the hinged door and the cut prim door. These fell away when people like Ordinal, Qie, Strife, Dora, Void, Innula, Rolig and quite few others over time, began to share the algorithm, on the forums and at inworld classes, to swing objects on a axis offset  

Edited December 23, 2019 by Mollymews
except

[Qie Niangao]

There was a time before there was any way to set link parameters from the root. Imagine the carnage.

It doesn't matter in this case, but even with LINK_PRIM_TARGET, each link affected by a SLPPF call generates it own object updates. For a door that opens maybe hourly, nobody should care (even if the motion needs to be incremental to keep the links assembled throughout). In contrast, for stuff that's moving a lot (or even continuously), it would be worthwhile modelling a single mesh and fiddling with UV maps as necessary to make the up to eight faces texturable as intended.

[Nova Convair]

Since mesh I never even considered to make a linked multi-prim-door.

I have one door that opens to 3 sides (1 part left + 1 part right + 1 part up) - requires a rats tail of extra code though. 😎
Auto setup on bootstrap and change numbers if resized. (I'm too lazy to manually get new numbers in that case)
Find the door pieces in the linkset on setup and when linkset was changed.
There is more than one door in the same linkset, that needs to be adressed and I am too lazy to manually rename the door pieces of course - script job to find the right ones.
People will click the (scriptless) doorpieces. The door script should get that clicks.
Multiclick protection. (3 AV's in front of the door - door opens - closes - opens ... with 2 AV's it's more difficult 😎)

Collision is not my thing. I walk my face into a door, then get squished between door and wall or door switches off physics - which is not immersive. No, don't like it, don't do it. But I use spaceships instead of houses so there is a different point of view here.

However, I will not do it again - one door - one prim - that's how I will keep it. 🎅

[Rolig Loon]

I agree completely that the smartest approach these days is to make a mesh door that includes all of the hardware and glass as a single object, but that wasn't the OP's question. It's still not unusual for a homeowner or an amateur builder to get components from several different sources and then be faced with the OP's question: "How do I rotate them together as a single unit?" The point of my response was that you don't have to throw up your hands and walk away. It is quite possible to rotate several linked components together, and there doesn't necessarily have to be a clunky visual effect. 

Like Molly, I like to be able to trigger a door or a garden gate by walking into it. As far as the script is concerned, of course, a collision event and a touch event are essentially the same thing, so you can drop the same code into either one to actuate a door.  In fact, I sometimes include both triggers in gates and then also add a bit of code to assure that the door always swings away from you instead of whapping you in the face. That can make a script heavier, but in some situations it is the proper tradeoff.

The question of whether to open a door in incremental steps or in one single swing is another interesting one but, again, was not  part of the OP's original request.  Void Singer's simple hinge script and Innula's version both swing the door in a single step.  Various "smooth" door scripts use some version of Toy Wylie's old method (which combines a llTargetOmega rotation with a set of incremental rotations) or do the job with incremental rotations alone.  Within the past year it has become clear that the llTargetOmega approach can have some serious affects on lag, and Molly points out correctly that an incrementally rotating door can look awkward if the region is lagging, or simply if there are too few steps made too slowly. A building with a lot of individually-scripted slow-rotating doors can add quite a bit of script load too.

All of those issues are important ones.  A scripter/builder has to balance their pros and cons seriously to decide what mix of features is most appropriate in whatever s/he is building, and there is no universal "best" answer.  As far as the OP's original question is concerned, though, it is quite possible to rotate linked components of a door together.

[Qie Niangao]

3 hours ago, Rolig Loon said:

The question of whether to open a door in incremental steps or in one single swing is another interesting one but, again, was not  part of the OP's original request.

Incremental motion is kind of relevant, though, to the moving linkset problem. In a sometimes perceptible way, non-incremental motion can make linked objects appear to disassemble when moved. Say the handle of a refrigerator door and the door itself are two distinct links. When the door swings open, even with a single SLPPF call, the actual motion seen in the viewer is slightly interpolated, not instantaneous, and the door link's interpolation looks like a simple rotation relative to its "hinge" but the handle will fly an interpolated straight path from its closed to open local position (and rotation), not the arc transcribed by the edge of the door link. It will look like the handle has sorta "come loose" from the door and reassembled itself at the end. A few incremental steps can approximate that arc and make the handle appear better attached to the door. (This is what I thought @Mollymewsmeant about "multiple prims moving together visually look to stick together better, when the server side nominated travel distance is shorter" -- but I may have misunderstood.)

[Britt32 Beck]

On 12/22/2019 at 3:43 PM, Rolig Loon said:

 

Guys / Gals.. Thank you so much for all the comments here. (sorry Rolig, I know you pointed out I should of posted in a different forum, but look at the discussion I've opened up here ☺) I used door as an example... I'm creating a Murphy bed. I need the pillows and blankets to move with the casing (bed frame) in an up and down swing, pivoting from the bottom edge. Because it is furniture, and will be moved, rotated, positioned by the owner, I need it linked to the main outer casing on the unit. I want to be able to offer texture changing on all objects on the movable door.. this is why i'd rather they be linked objects. The swinging case (bed frame) requires 4 assigned textures on its own.. which leaves me 4 to play with for the blankets and pillows (this is where i may need to adjust my build plans as I believe I'm up to 6 on those now). I also need the texture changer to be able to identify which faces belong to each set of textures (frame has 4 textures assigned, probably arranged on 2-3 texture files).

I do not understand LSL and I've reached out to a few door creators. Kool Mechanic was kind enough to have a lengthy conversation with me and he said he is going to try to tackle this in the next release of his door script.. sadly, not before my event though. Which is why I reached out to the forum. 

Again thanks for everyone's input and Merry Christmas!

Edited December 24, 2019 by Britt32 Beck

[Mollymews]

i just want add here that me and Britt had a chat inworld

what came of this chat was something that people like Qie and Rolig mention periodically. Write scripts for a model and don't model for a script

Britt is a mesh modeller and being mesh then a murphy bed only needs two mesh parts. The standing frame and the bed part. The bed part has the bed base, mattress, sheets, blankets, pillows and eiderdown. Upload these two parts as separate objects and then link them inworld. The frame as the root prim. The bed part as the linked prim. As these are uploaded as separate objects then the frame can have up to 8 faces. And the bed can have upto 8 faces also

can then drop a offset axis swing script in the linked bed prim and done. As it turned out Britt already has a general purpose axis swing script which he is familiar with

having these kinds of chats can be helpful as sometimes when we think with scripting uppermost in our minds rather than the model (design) then we can sometimes miss an otherwise more efficient solution

[Alyona Su]

On 12/21/2019 at 4:59 PM, Britt32 Beck said:

Hello all, 

I'm looking for a script (or a way) to have a swinging linkset for a door (Not joined objects). Example: I have a door as an object and a handle as a separate object. I need to link them, then have them swing open or closed together. The only door scripts i've tried will not swing multiple linked objects, it only swings the primary object leaving all other objects in the linkset in its original place. 

Does anyone know of a door script that supports this? I don't want to waste more money on them only to find out it does not work. 

 

Thanks for your time!

Britt

That answer is simple and can use *any* door script. What I do is link all the parts of the door together: Door, Handle, Glass, Knocker, Gargoyle, Whatever - all linked. Now create a simple cylinder to act as your hinge. Link the door to the hinge (hinge being the root). Drop door script into the hinge, Edit Linked and make the hinge transparent with transparent texture. Link door (with hinge) to building. Done.

[Britt32 Beck]

17 hours ago, Alyona Su said:

That answer is simple and can use *any* door script. What I do is link all the parts of the door together: Door, Handle, Glass, Knocker, Gargoyle, Whatever - all linked. Now create a simple cylinder to act as your hinge. Link the door to the hinge (hinge being the root). Drop door script into the hinge, Edit Linked and make the hinge transparent with transparent texture. Link door (with hinge) to building. Done.

No that doesn't work with any of the scripts I have so 'any' does not apply here. If I do this with the scripts i have, the hinge will swing, not the door linkset.

 

However.. it does work if you don't have it linked to an fixed object.. I need this to be linked to the outer casing.. and when i do this with your suggested method.. only the hinge swings open, leaving the door linkset in place. 

Edited December 25, 2019 by Britt32 Beck

[Alyona Su]

12 hours ago, Britt32 Beck said:

No that doesn't work with any of the scripts I have so 'any' does not apply here. If I do this with the scripts i have, the hinge will swing, not the door linkset.

 

However.. it does work if you don't have it linked to an fixed object.. I need this to be linked to the outer casing.. and when i do this with your suggested method.. only the hinge swings open, leaving the door linkset in place. 

Even if you link the door to the hinge (hinge as root)? Then something is amiss (I/m not understanding) with your build. I do it the way I describe all the time.  Well, I wish you luck in finding your solution.