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

[karl ramberg]

On Tue, Feb 28, 2012 at 8:09 AM, Steve Thomas <sthomas1 at gosargon.com> wrote:
> 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 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 and 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
>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>

I found out you could use a instance variable named speed with the
moveToward tile.
moveToward reads the speed variable 'under the hood' and you can do
various ease in etc. together with the distanceTo tile.

Karl