[etoys-dev] Future Release feature: A slide/glide tile
karlramberg at gmail.com
Tue Feb 28 03:19:45 EST 2012
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>
>> 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
> 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
> etoys-dev mailing list
> etoys-dev at squeakland.org
I found out you could use a instance variable named speed with the
moveToward reads the speed variable 'under the hood' and you can do
various ease in etc. together with the distanceTo tile.
More information about the etoys-dev