How do I have the movement of an object trigger the firing of a script? Simple example - moving A causes B to follow it by a fixed offset.
Related, perhaps, in the 'scripting' category, what's an example use of the 'triggeringObject' dude?
Thanks, Randy
Randy & Others - This too is a tile that should have been "surpressed" as was part of an experimental set. Sorry for any inconvenience. cheers, Kim
At 4:44 PM -0500 6/9/05, Randy Heiland wrote:
How do I have the movement of an object trigger the firing of a script? Simple example - moving A causes B to follow it by a fixed offset.
Related, perhaps, in the 'scripting' category, what's an example use of the 'triggeringObject' dude?
Thanks, Randy
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
"Randy Heiland" heiland@indiana.edu wrote:
How do I have the movement of an object trigger the firing of a script? Simple example - moving A causes B to follow it by a fixed offset.
You can accomplish the goal using a slightly different approach: use a plain old ticking script. For example, if "follower" and "smile" are two objects in your current project, you could use the following script (transliterated from the tiles):
follower's x <- smile's x - 200 follower's y <- smile's y
For this to look nice, you should set the ticking speed of the script to 100 times per second. Do this by holding the mouse down on the circular clock-looking button at the top of the script. By default, the script runs less frequently and the animation will look jerky as you drag the smile around.
In general, EToys (and the Morphic engine it is built in) is very friendly to these "polling" approaches to animation. A person trained in computer science at a university might instinctively avoid this approach, but actually it fits very nicely with the rest of Squeak. While polling can cause problems in principle, EToys has the advantages that (1) there are usually only a moderate number of objects involved (hundreds or fewer), and (2) updating 100 times per second is easy for a modern CPU but plenty fast that a human will not be able to perceive the lag times between an event . To really rub in this last point, consider that mouse events themselves are only processed 100 times per second in Morphic, but you still can't detect the lag. And even if you could, a typical CRT updates *less* frequently than 100 times per second, and so you couldn't actually display your updates more quickly than 100 per second....
The main downside to watch out for is that the *order* that morphs are polled cannot be predicted. An event-driven approach could guarantee that morphs update after whatever they are depending on updates. If the order of updates matters, then polling solutions are still possible but they are trickier. For simple things like morph A is following morph B, however, the order is not critical.
And there are advantages to polling instead of events, such as avoiding infinite loops, but this email is already too long for the original tiny question so I'll shut up.
Lex
squeakland@lists.squeakfoundation.org