moving two objects in a linked set in unison

Hey,

I am learning how to build vehicles and I now know how to move/reconfigure pieces of them like flapping a flap on a wing or whatever. It's fantastically difficult compared to how it *should* be, but that's another thing altogether.

My problem is that any really good designs I can think of involve moving multiple pieces of the craft in unison (for instance a nice looking wing is usually made of multiple pieces).

I have been advised however to compromise my design by making the wings or other moving parts out of single prims, since moving two prims together, "never works." (the lag will make them unlikely to move together, thus the wing or flap would appear to break apart momentarily)

Is this really true? Are there any methods people have developed that get around this problem?

I am thinking if the pieces could somehow communicate with each other they could coordinate their movement? I guess the question is whether the source of the uncoordinated action is amenable to any kind of correction or if its just lag and the attempt at communication would similarly lag.

You'll generally want a 'controller' script which issues the commands through either llMessageLinked() or things spoken on dedicated channel, and 'receiver' scripts in relevant prims which interpret these commands. This may make things appear like they're more or less synchronized, though probably still shouldn't expect it to work perfect by any means ^^;

With my own experiments I can say that unless you are in a sim where nothing is working anymore you can safely use linked messages and expect coordinated, simultaneous movement.

Any difference will become more visible, the slower and smoother you try to move - the eye detects glitches much better then.

Do some experiments but linked messages work just fine. Normal chat listeners, even when set to negative channels, have sometimes weird "thinking pauses".

Using linked messages to coordinate the movement of 'subsets' of a link set works, but the effect is a bit unpredictable. One day your door (with linked catflap, handle and separately openable window) will appear to move seamlessly as a single unit, the next day all its components will decide to stroll independently to their new positions, over the space of a second or so. You are at the mercy of the SL scheduler, I guess.

You will also have to deal with the problem that each prim will take a separate route to its destination, based on its own axes and shape, so your sub-assembly may well morph quite spectacularly during its transition. As a scripting exercise, though, the challenge of coding synchronised rotation and translation for coupled prim hierarchies, particularly in attachments, is quite bracing.

Bracing, now thats anice way of putting it!

Indeed.

I've made a rotation-around-any-point-and-even-multiple-points system, where you specify in a notecard the location of joints and where they rotate, and what prims they affect. It consists of a script named RotatePrim on every prim, one named RotateControl on the root prim, and another script which sends the rotation commands (basically saying rotate joint #0 to 0.7, for example, where 1.0 is its maximum rotation and 0 is the minimum). I developed and tested this on a little swordsman figurine which had joints in the shoulder, elbow, and hand, and basically repeatedly did two things, one after another: raised a sword above his head and then swung it down, and also stabbed forward with the sword.

What it can do:

1. I can rotate prims around any arbitrary position,
   
2. Their new position and rotation is based on their original one (which is recorded in a notecard (what you should put in it is spammed at you by a script designed for that purpose)), so floating point math errors don't build up to destabilize the system,
   
3. You can have joints which rotate around other joints (figuratively - the joints don't rotate in the rotation system, but the effect is the same) - they have to be in the right order in the Joints notecard, however. Basically, for a part of the swordman's sword, the prim is rotated and repositioned around the hand joint, then rotated and repositioned around the elbow joint, and then around the shoulder joint. The effect is pretty impressive, although probably not to anyone who doesn't know anything about scripting and rotations.
   
4. Joints are not prims, don't need to be represented by them, and can be anywhere.
   
5. However, joints' can only rotate along one (arbitrary) axis, so to make a "ball bearing"-like joint which can rotate in any direction requires three joints at the same position (At least, I couldn't convince it to work with just two for some reason).
   
6. Prims are rotated and repositioned only once with an llSetPrimitiveParams call per tick, even if they rotate around multiple joints.
   
7. I couldn't make the prims ALL move at *exactly* the same time. Right now it works fairly well, but not so well if you want to make the movement slow and smooth. I tried llSleep(0.01) in a loop in every prim to delay until a specified time, but that didn't end up synchronized. I also tried a while loop with no sleep statement (which I expected to affect time dilation noticeably, but it didn't), which STILL didn't result in synchronized movement. I don't remember what timing mechanism I was trying, but the next thing to try would be making every prim camp llGetWallclock() until a specified second arrived.
   
8. However, right now, rotating something does not rotate the rotation axes for the next joints. The main effect is that to rotate something to face an arbitrary point, I needed three joints instead of two and cannot prevent it from tilting to the side at an odd angle as long as it still faces the target (Well, that's more an effect of the math I'm doing to determine where to rotate the joints to face the target - not something in the rotation system itself).
   
9. If you constantly send joint rotation messages despite the rotation not being any (or much) different from the joint's current rotation, this will cause lag in the rotation as well.
   
10. Lag in the rotation is simply a result of linked messages building up faster than they can be read, processed, and reacted to. It doesn't cause sim lag or affect time dilation.
    
11. I currently have RotatePrim always setting pos/rot in a timer tick even if it hasn't changed, which probably makes linked message lag more likely if there's a lot of messages. I'll probably try making it compare the old and new position and rotation and do nothing if they're the same, but I'm wondering if that will cause desynchronization in the event of even an tiny amount of link message lag (As the currently non-moving prims would breeze through the messages faster than the ones which are moving, and if both sets of prims are then ordered to move, the previously non-moving ones would then start before the others).
    

In testing, I found that:

1. Timers aren't accurate,
   
2. llSleep isn't accurate, but seems to be a bit more accurate than timers,
   
3. llSetTimerEvent(0.01) waits only slightly less time than llSetTimerEvent(0.1)
   
4. Sending a link message incurs no delay, but receiving one does seem to,
   
5. If you have too many linked messages going at once, you will get lag in the messages, and will eventually start silently losing messages.
   
6. You also can't rely on all your prims reading the linked message at the same time, especially if you're also sending other linked messages.
   
7. In my tests, I found that llSleep(0.1) was taking about 0.156 seconds on average, and llSleep(0.01) was taking 0.054 seconds on average, and a 0.1 timer was taking 0.070 seconds on average (which made me say WTF), a 0.01 timer was taking around 0.06 seconds, llSetPrimitiveParams setting position and rotation was taking 0.23 seconds on average, sending a linked message was taking 0.006 seconds, and receiving a linked message was taking about 0.12 seconds.
   
8. Note: I didn't record the actual results from the 0.01 timer test, just that it was close to 0.7, and I remembered that it started with 0.6. The rest I recorded. Those above figures were all from running something 100 times: the main test which I used was a loop with 100 llSetPrimitiveParams calls. I determined the time taken by the loop overhead and by llSetPrimitiveParams, and subtracted that out of the later tests to determine the time needed for whatever I was testing.
   

If you try to synchronize multiple prims by using timers in each prim set to the same time delay, that will cause the animation to get more and more out of sync as time goes on. I tried sending a tick message from a single prim several times a second, but it flooded the linked message buffers and, as a result, caused lag in the rotation system. It also still didn't generate synchronized movement due to different prims noticing the message at different times. Currently I have it a 0.5 second timer in every prim updating the rotation and position of that prim, with a resynchronization message being sent to every prim every 10 seconds. The resync message just clears the timer event and resets it to 0.5 seconds. In my turret, the rotate-to-whatever-angle commands are sent every time the 0.5 sensor reports on the target's position, but stops when they stop moving. This works fairly well and fairly fast without causing link message lag or lost messages.

A specialized system may be faster, if designed well, but has the downside that you have to edit it significantly for every new object you want to use it in. The aforementioned generic system is great because I can install it on any object and basically just define the joints and set up a script to send the rotation commands when needed.

I had noticed some similar 'limitations' (lets be polite) with the timers.
I think sleep works more accuratly because its not event driven, you're still in 'process'.

Some for of time synchronisation from the master script based on Wallclock would possibly work, but would still be subject to the whim of SL's scheduler.

Sounds like a fun script to have designed/written.