[etoys-dev] Future Release feature: A slide/glide tile

[Steve Thomas]

On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

>
> On 27.02.2012, at 05:58, Steve Thomas wrote:The execution models of Etoys
> and Scratch are fundamentally different. In Etoys, all tiles in a script
> are executed in the same time step. You cannot have an individual tile take
> time. That's why there is no "wait" tile. That's why you can't do animation
> with the "repeat" tile. Etc.
>
Unless/until someone adds that capability, you can't have a slide tile
> either. (The single-stepping mechanism might be a step (pun intended) in
> that direction)
>


Okay, eventually I will get my head around this execution model (then I'll
try tackling the one for Kedama ;)  But, I think I get your point and I was
not asking for a wait tile (well perhaps I don't get it, but I plunge on
blissfully ignorant of my own ignorance...)

So before I sent this request I did create glide/slide functionality with
simple Etoys scripts.  So I assumed if it could be done with existing
tiles. I thought we could create a tile which in effect sends a message
with arguments to more generic version of my scripts. Thus the individual
tile does not "take time", it simple sends sends a message with the
arguments in my earlier email.

The I read Markus' nice idea of using a player with variables and created this
project<http://www.squeakland.org/launcher?http://tracker.squeakland.org/secure/attachment/15270/Glide+NoWait.017.pr>
 in an attempt to solve the problem without waiting (pun intended)
The "Glide Tile" which is a playfield, with a start script and a doIt
script makes a copy of itself then that copy does the gliding and erases
itself when done.  It has one script with a player variable, so in effect
you have a scripting tile, which can Glide multiple objects at the same
time and doesn't wait.
The gliding algorithm is very basic and can definitely be improved.

The one potential problem I see is what happens if we have two "glides"
going on at the same time for a particular attribute.  I guess there is no
way of "queuing" events.  Scratch solves this by ignoring the second event
if it is in the middle of the first one (at least that's the way it seems
from some simple tests I ran), but you can still screw things up if you two
scripts that execute on the same event and modify the same attribute.  Well
I guess I can't be protected from all my silly mistakes.


There are some other improvement wishes in what you describe above though,
> and those might be easier, and possibly more powerful too. One is to have
> more than one argument to a user script. Another is to be able to easily
> copy behavior from one object to another. You might want to create separate
> tickets for these.
>

Done create SQ-1024 <http://tracker.squeakland.org/browse/SQ-1024> and
SQ-1025 <http://tracker.squeakland.org/browse/SQ-1025>, Note I added the
ability to link a script to another object as opposed to copying it.
 Basically something similar to sibling behavior, so that when I change the
script it changes for all linked objects.


Thanks,
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20120228/8c2eec2c/attachment.html>