making handles on doors move with the doors

i made a cabinet where 2 doors open like they are suppose to but if i make a prim handle and put it on the doors it doesn't move with the doors. Anyone know what i'm missing here?

The solution is nontrivial.

One solution is for the cabinet to not be a single linked object but rather a set of them. (Try selecting multiple objects and right-click->take. You get one inventory entry that has multiple objects and when you drag it out they retain their relationships.) In this case, each door could be an object, which the script can rotate.

However, these "globs" can be a nuisance to sell and for the owner to move around.

The other alternative is to do lots of math to figure out the translation and rotation for each prim in the handle. I get bogged whenever I try this kind of math, but no doubt someone here has the goodies.

What I might do is for each prim in a handle for "door 1", I'd put "door 1 handle" in the prim's name. Then, when rotating the door, I'd loop through the prim set and for each one that contains "door 1 handle" in the object name, I'd calculate the translation and rotation relative to the door's axis, and use llSetLinkPrimitiveParams() to update offset and rotation. Just remember that everything is specified relative to the root prim's location and rotation. My head hurts a bit when trying this stuff, but after all it's only advanced high school math (assuming you convert from quaternions to euler and work in euler form).

I tried scripting a ferris wheel where the weel turned but all the riders stayed in upright orientation. Sounds simple but I never managed to hit on a solution to compensate for setting the rotation relative to the root prim (which was rotating).

i been programming for like 12 years now but never got into the 3d math before. Pretty overwhelming at first. Tons of respect for 3d programmers.

You may be able to use the in-world program Puppeteer for that. It allows you to animate multiple prims in an object by moving them and recording the locations in a script. The scripts that the program puts out are locked, but you may be able to write another script to call the Puppeteer script when the cabinets are touched. I've only used the free version which produces non-transferrable scripts.

Anyone know if this is possible? I know the program allows you to activate the animation on click, but I don't know if it would allow you to call the scripts from another script. You would need that feature to alternate opening and closing animations.

[Edit 3: This works if you make the open and close each one frame of the animation, then set Puppeteer to advance a frame at a time each time the script is called. It is really easy.]

Yes you could set puppeteer to be activated by a chat command on a private channel then make the handles of the cabinet speak the chat command when touched.

Hmm, there is an easier way.

I assume the door doesn't swing slowly; but rather, you click (or whatever) and it opens or closes relatively quickly (in one set-position/rotation).

Close the doors. Drop in a script in the cabinet (same place as the one that moves the doors) to get and say the positions & rotations of the handles, and then deletes itself. Open the doors and drop the script in again.

Now you *should* have the correct parameters to pass to llSetLinkPrimitiveParameters(). However, IIRC, there's a bug for position and/or rotation, where setting exactly what you got moves the prim, that the relative/absolute corrections aren't the same for getting and setting.

Hopefully someone who knows the details on that can pipe up!

I know next to nothing about scripting, but on several of my Paskis doors, I put a doornob on them, linked the knob to the door, and they work fine. Same with a Christmas wreath for one of my tenants. That worked fine too. Why doesn't it work just to "ctrl L" the knob to the scripted door?

likewise you can also have BOTH an open and closed door, and then set one alpha-0 and the other alpha 1.

Or, you could just paint a handle on your cabinet.

Simplest way is probably to send a linked message to the linked knob/handle when the door is touched that sets off a rotation script inside the knob/handle. And if the knob/handle is touched, send a linked message to the door to open.

Avion: What you are talking about involves each door being a different "object". That is fine until a user wants to move the whole cabinet or the whole house; then he has to also move the doors. They do not (unless intelligently scripted) automatically follow.

I have done this sort of thing with linked sets, and there are good and bad things about it. Using LinkMessages and calculating the rotation of the handle about the cabinet's hinge can be, um, challenging. And they will not move entirely together. And if individual prims are not rotated the right way (for hollow prims and such that need special rotation), they may get choppier yet as you have to do *move* and *rotate* separately.

Another possibility (which I've been meaning to try) is to have the cabinet doors be separate objects (linksets) that keep track of position relative to a particular part of the cabinet. If the cabinet is moved, then, the doors get a message to move accordingly.

If you have other questions, feel free to IM or PM me.

I have a house with a sliding glass door that is linked to the house - it has a prim handle that moves with the sliding part.

Using the same simple doorslide script (no link messaging), I made one of the windows into a sliding door, and it worked fine. I linked a handle to it, in MANY different orders, and the handle never successfully traveled with the door. I did succeed in inadvertantly making the usually stationary part of the door slide a few times, grrr. One time the house slid. Double grr.

I am very puzzled by this. It seems to me that if I make the sliding part of the door and the handle into one linkset (with the sliding door part as root), then drop the script in just like a regular sliding door, and link the whole to the nonsliding part as usual, it should work.
.

I have a house with a sliding glass door that is linked to the house - it has a prim handle that moves with the sliding part.

Using the same simple doorslide script (no link messaging), I made one of the windows into a sliding door, and it worked fine. I linked a handle to it, in MANY different orders, and the handle never successfully traveled with the door. I did succeed in inadvertantly making the usually stationary part of the door slide a few times, grrr. One time the house slid. Double grr.

I am very puzzled by this. It seems to me that if I make the sliding part of the door and the handle into one linkset, then drop the script in just like a regular sliding door, and link the whole to the nonsliding part as usual, it should work.
.

option A)
have the door and handle as a separate object from the rest of the build.
+ works like you want
- is a PITA to move/rotate into a desired position requiring either a box solution like rez-foo or detailed scripting or instructions on moving.

option B)
script in a move position for the handle when the door is touched.
+ allows the whole thing to be linked
- somtimes the door and handle don't move in synch

option C)
create the door/handle in both open/close states and have them switch visibility
+ still allows linking
- can't click objects behind the door even when 'open'
- higher prim count
- might not always 'open/close' in synch
- invisible open door state may block other clicks at an angle

other ideas:
two step installation using a variation of option A, when structure is in place, doors are rezzed. when structure moves, doors are derezzed untill it stops moving. kinda of a built in boxing solution, the deRez may be problematic. optionally you could add a menu that allows them to shoose when to rezz the doors.

another idea is to use option A and send messages to the doors when it stops moving, and use the rotation and position to have the doors follow it, but this requires extra active scripting, so I wouldn't reccomend it

scripting a hole size change along with an invisible open state would work for flush designs, and might eliminate the first 2 problems with option C, but may look strange if it renders any inbetweenness in the hole size change.

personally I like the boxing solution variations if you're going to be that detailed.

A final note on using Puppeteer to solve this problem (free version, but supposedly the only difference is that the resulting script is no-transfer).

It is extremely easy to animate a single multi-prim door or cabinet using Puppeteer. You just put scripts supplied by the program into the root prim, put others into each of the door prims, and edit the door and handle into the open and closed positions (2 frames only). Set the final script to advance one step at a time on touch and to loop the animation. That's all there is to it.

BUT - this won't help you at all if you have more than one door/cabinet in your build, because you can only have one copy of the Puppeteer playback script in the root prim. All the drawers will open and close at once. I contacted the creator and he said a future version will take care of this.

i made it work using linkmessaging.

you talk about puppeteer like it will write its own script.
i don't see any functions in lsl that allow writing to any form of notecard or script file.

maybe it'll tell you params for global variables but cant write them, correct?

Correct, LSL has no command for writing to notecards. This is because the implementation of notecards is such that a new asset ID is created every time a notecard is written to. There is much wailing and gnashing of teeth over this.
.

Hi Trolane, I have read all of the replies to this post and they talk about various scripting or notecards and other ideas to make the handle move that it would take someone with a degree in fratistatal discomboominator conversion to figure out when if all you wish to do is make the handle open with the door. Im sorry if I missed something in the OP but....

Simple answer:

Link the handle to the door.....keeping in mind where the root prim is located. (dont make it the door itself)

am I right?

Puppeteer doesn't create a script from scratch - you drop prewritten scripts into the prims that you want to animate. You use chat commands to tell the program to record positions for each frame of the animation, and set how you want the animation to work (sequence, trigger, and speed). Then the program modifies the prewritten scripts in the prims to record that information. I don't know what commands it uses to do that, as the final product is a locked script. There's no way to interact with the scripts other than calling them with the trigger you specify during setup (chat, touch, etc.).

I doubt this is literally true. It's theoretically possible, but I believe it would require a bot (an avatar running a nonstandard client with programmed behavior) because there's no other way I know of to create an SL asset, and that would be required. Scripts can't modify scripts.

Most likely, the scripts simply record the programmed information in variables.

Another common method for a scipt to write a script is for the script to "chat" the script, which you then copy/paste into a script manually (after deleting timestamps etc.) This is more commonly used to create notecard contents, where it often isn't necessary to delete the timestamps etc.

record position and rotation data to a list for each prim... replay the list based on it's index from a controller script... not really hard.

ya thats more like it.

Right, more or less what I said above. I didn't mention a list, and I didn't recommend recording position of all prims, just the ones you want, selecting by prim name. But a list is the obvious choice of data structure.

never played with it, but I imagine it records them all (separately) for ease of use, otherwise there has to be a system to select individual parts, and another system to know when to skip changes for certain parts... it'd get messy fast.

For some kinds of doors and handles, a sculptie may work to make the door and handle one piece. I do this with drawers, which used to animate in pieces. But doing so would mean that your door is sometimes a blob.

For my safe, I made the door/handle a separate object, and then packed it like a house with BB.

Are we going to have new functions that allow for sub-objects?

I just posted a script that does just that Baron , as long as Trolanes doors are in chat range of the cabinet they will just move right into position.
see thread with a link to my platform where there is copyable model
/54/c9/240454/1.html