Linked animation (steam engine)

Hello,

I'm working on a steam engine with several interconnecting parts. To get it working I was planning on using an old VRML technique, where one timer will drive all the animations.

So one object will have a timer, and increment a counter from 1-100 say. Each time pulse it will send this counter to linked objects, who will then use it to work out what stage of the animation they should be at.

I'm hoping it will prevent parts getting out of synch, and also let me change the speed of the animation as it runs (by changing the counter increment).

I'm new to LSL, and just wondering if this might be a good way to go about it. Some psuedocode might be:

Engine object;
on_touch: 
    start timer event (every half second)
on_timer_event:
    add speed variable to counter
    if counter is over maximum reset to zero
    message all connected parts with counter value

Animated object;
on_receive_message:
    extract counter value
    map counter value to position/rotation range

Any comments appreciated, particularly on efficiency. Thanks

Lucius

One thing to keep in mind is that one or more messages could be received. Given your use, you probably want to skip to the last one each time, not process each individual one.

Another possible issue is what would happen if one of the objects gets lagged for some reason. Do you want to try to use a protocol that requires all of the objects to agree on some minimum counter, and then progress to that point?

I'm not an expert in this area. just thinking out loud.

There is a Public Domain protocol called RTI that does something like this. Run-time Infrastructure, I think, or Real-Time infrastructure. The idea is to enable multiple totally independent systems to agree on what stage of a simulation they are agreed to be at.

or, consider NTP. maybe you should have *all* the parts broadcast their counter. Then each part would look at the inputs and select the next best time to advance to. So, if several were running behind for some reason, then the others would slow down a little to wait for them.

interesting problem. hmmmm.

It might not have been clear. There will be just one timer that drives all animations.

So for example when it broadcasts a value of 50 (in 1-100), all linked parts take that number and move to a position halfway through their animations. If anyone remembers timers and position/orientation interpolators from VRML then its just that.

Your point about multiple messages may be an issue. Is there a chance of a back-log building up through lag? That could make it 'stick' and 'lurch' through the animation.

It seems very sensible. Am sort of in middle of testing similar thing (sets of 'morphs/shapes' stored by objects with ability to then interpolate between these shapes in way dictated by control script) so will know better how it works out in practice in a bit, i guess ^^;

That was the point Leee was raising Lucius. If you are unlucky, or its a sunday night, you could end up with half your prims out of sequence. by using an aggregated counter they may be able to resynch them selves.

I suspect if the lag is getting severe enough to cause such lack of sync, it's more likely for parts to resync when they receive another value tick in half second, than actually manage to work out which should slow down in any reasonable manner that wouldn't just result in different parts breaking down.. ^^;;