tricks to making llLinkMessage driven llSetPos work smoothly?

been working on scripting a fully linked dresser to have its drawers slide out and for prim handles to move with it and stuff.
Well i found out that the smoothest but worst deployable method is to just link the drawers and not link them to the dresser.
The other method which is great for deploying the dresser is to linkmessage the handles and stuff that it was touched. Problem here is the touch fires and moves the drawer out, but link message takes time to work so the handles follow after by like half a second or less. Anyone got a trick to make this smoother?

making 2 drawers per each dawer and modding alpha isn't a good answer because that almost doubles prim counts.

I suspect something else is going wrong. Link messages are *very* fast, compared to anything that actually moves prims around. For example, there's a 0.2sec delay after each llSetPos (or llSetPrimitiveParams), so if multiple of those are used to effect one "drawer slide" it will look pretty jerky. The way around that is to use multiple slave scripts that execute in sequence, getting around that delay.

But if it's just using one llSetPos per linked item, I frankly don't know what's going on, but it's highly unlikely that any noticeable delay can be attributed to the link messaging.

i have the body of the drawer, any empty cube, moving with setpos
i then call linkmessage saying which drawer is moving and a flag wether its opening or closing.
the other objects listen and when they see its for there drawer they call setpos.
there's nothing fancy at all going on math wise.

you know what... i think you just nailed it lol will have to try it tonight.
i call the linkmessage after the first setpos so there's my delay issue.

why are there intentional delays in this anyways, goes against anything i know architectually.

the trick for making the linked version work as best as possible is to loopback the touched message...

let me translate that...

instead of moving one part when it's touched, then messaging the others, (or even messaging then moving), instead, just fire off a message, like "drawer A open", then the originating script and all the sub scripts for drawer a handle the incoming message and move together (theoretically), since scripts CAN hear their own link messages.

it still won't be perfect, but it'll be closer than either of the two previous methods, and probably the best you can do and still keep it all linked

the other major options are just like doors.. alpha switching between prebuilt open and closed versions, and unlinked from the main object

Darn good question, and one that has been asked (rhetorically?) many times before. I bet the workarounds everyone does wind up being MUCH harsher on sim resources (and lag) than removing the script delays would be.

I think maybe the llSetPos() delay goes back to some anti-griefer issue.

As for adding more precision, another fine-tuning that you can use is to add a time to the message. That is, don't just say, "Everybody move at time now". Instead, say,

t = now + <some small delay>
Everybody move at time t.

The receivers use some mechanism to wait until time t arrives.

note two things:

This adds to the script execution needs.
This might become more accurate when Mono arrives.