Smalltalk › Frameworks & Tools › eToys Development

Future Release feature: A slide/glide tile

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Steve Thomas

Future Release feature: A slide/glide tile

So I created SQ-1021 where I am looking for something similar to Scratch's <glide [n} secs to x:[ ] y: [ ]> tile, but more generic.

A scripting tile that changed any numeric value incrementally over a period of time. Something like: <glide: <numeric Attribute> to: [new value] in [] secs.

Use Cases:

Change the width/length of a playfield, to create a Mouse Over drop down type menu
Glide to position X,Y in z seconds
Changing alpha to create fade in/fade out effects
Changing other color values (just for fun, and imagine if I could address each pixel in a graphic this way :D, okay Karl already imagined and implemented that the color reader/writer way, thanks Karl)

I tried doing this in the existing Etoys and it is possible, the problems (at least for me) are:

You have to re-create the same basic script each time for each attribute and player, first time cool, after that, boring and tedious (well that's another enhancement request)
You can't pass an attribute in as a parameter to a script (this I think would solve the problem, and if I could pass more than one variable to a script, I could pass:

player
numeric attribute
time
new value.

Cheers,

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Bert Freudenberg

Re: Future Release feature: A slide/glide tile

On 27.02.2012, at 05:58, Steve Thomas wrote:

So I created SQ-1021 where I am looking for something similar to Scratch's <glide [n} secs to x:[ ] y: [ ]> tile, but more generic.

A scripting tile that changed any numeric value incrementally over a period of time. Something like: <glide: <numeric Attribute> to: [new value] in [] secs.

Use Cases:

Change the width/length of a playfield, to create a Mouse Over drop down type menu
Glide to position X,Y in z seconds
Changing alpha to create fade in/fade out effects
Changing other color values (just for fun, and imagine if I could address each pixel in a graphic this way :D, okay Karl already imagined and implemented that the color reader/writer way, thanks Karl)

I tried doing this in the existing Etoys and it is possible, the problems (at least for me) are:
You have to re-create the same basic script each time for each attribute and player, first time cool, after that, boring and tedious (well that's another enhancement request)

You can't pass an attribute in as a parameter to a script (this I think would solve the problem, and if I could pass more than one variable to a script, I could pass:
player
numeric attribute

time
new value.
Cheers,
Stephen

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)

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.

- Bert -

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Markus Schlager-2

Re: Future Release feature: A slide/glide tile

On Mon, 27 Feb 2012, Bert Freudenberg wrote:

>> You can't pass an attribute in as a parameter to a script (this I think
>> would solve the problem, and if I could pass more than one variable to
>> a script, I could pass: player numeric attribute time new value.

you can pass more than one variable to a script by using a parameter of
type player. The player passed needs to have the appropriate variables.
Screenshot attached.

Markus
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

player-parameters.png (82K) Download Attachment

Karl Ramberg

Re: Future Release feature: A slide/glide tile

In reply to this post by Bert Freudenberg

On Mon, Feb 27, 2012 at 7:10 PM, Bert Freudenberg <[hidden email]> wrote:

>
> On 27.02.2012, at 05:58, Steve Thomas wrote:
>
> So I created SQ-1021 where I am looking for something similar to Scratch's
> <glide [n} secs to x:[ ] y: [ ]> tile, but more generic.
>
> A scripting tile that changed any numeric value incrementally over a period
> of time. Something like: <glide: <numeric Attribute> to: [new value] in []
> secs.
>
> Use Cases:
>
> Change the width/length of a playfield, to create a Mouse Over drop down
> type menu
> Glide to position X,Y in z seconds
> Changing alpha to create fade in/fade out effects
> Changing other color values (just for fun, and imagine if I could address
> each pixel in a graphic this way :D, okay Karl already imagined and
> implemented that the color reader/writer way, thanks Karl)
>
>
> I tried doing this in the existing Etoys and it is possible, the problems
> (at least for me) are:
>
> You have to re-create the same basic script each time for each attribute and
> player, first time cool, after that, boring and tedious (well that's another
> enhancement request)
> You can't pass an attribute in as a parameter to a script (this I think
> would solve the problem, and if I could pass more than one variable to a
> script, I could pass:
>
> player
> numeric attribute
> time
> new value.
>
> Cheers,
> Stephen
>
>
>
> 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)

Yes, to add access to the script trigger and trigger times would be nice.

Access to the single stepping would make waiting possible:
Go two steps, wait 2 seconds, go two more.

We could even have line numbers as early basic, and goto ;-)

Joke aside, this would be nice additions.

Karl

>
> 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.
>
> - Bert -
>
>
>
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Future Release feature: A slide/glide tile

In reply to this post by Markus Schlager-2

On Mon, Feb 27, 2012 at 7:52 PM, Markus Schlager <[hidden email]> wrote:

> On Mon, 27 Feb 2012, Bert Freudenberg wrote:
>
>>> You can't pass an attribute in as a parameter to a script (this I think
>>> would solve the problem, and if I could pass more than one variable to a
>>> script, I could pass: player numeric attribute time new value.
>
>
> you can pass more than one variable to a script by using a parameter of type
> player. The player passed needs to have the appropriate variables.
> Screenshot attached.
>
> Markus
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>

Nice example

Karl
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Future Release feature: A slide/glide tile

In reply to this post by Steve Thomas

On Mon, Feb 27, 2012 at 5:58 AM, Steve Thomas <[hidden email]> wrote:

> So I created SQ-1021 where I am looking for something similar to Scratch's
> <glide [n} secs to x:[ ] y: [ ]> tile, but more generic.
>
> A scripting tile that changed any numeric value incrementally over a period
> of time. Something like: <glide: <numeric Attribute> to: [new value] in []
> secs.
>
> Use Cases:
>
> Change the width/length of a playfield, to create a Mouse Over drop down
> type menu
> Glide to position X,Y in z seconds

I looked at the source for #moveToward: and it says:

If the object has an instance variable named 'speed', the speed of the
motion will be governed by that value.

I updated the balloon help for this entry to show this info.

Makes interesting effect if speed is negative !

Karl

> Changing alpha to create fade in/fade out effects
> Changing other color values (just for fun, and imagine if I could address
> each pixel in a graphic this way :D, okay Karl already imagined and
> implemented that the color reader/writer way, thanks Karl)
>
>
> I tried doing this in the existing Etoys and it is possible, the problems
> (at least for me) are:
>
> You have to re-create the same basic script each time for each attribute and
> player, first time cool, after that, boring and tedious (well that's another
> enhancement request)
> You can't pass an attribute in as a parameter to a script (this I think
> would solve the problem, and if I could pass more than one variable to a
> script, I could pass:
>
> player
> numeric attribute
> time
> new value.
>
> Cheers,
> Stephen
>
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Steve Thomas

Re: Future Release feature: A slide/glide tile

In reply to this post by Bert Freudenberg

On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg <[hidden email]> 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
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Future Release feature: A slide/glide tile

On Tue, Feb 28, 2012 at 8:09 AM, Steve Thomas <[hidden email]> wrote:

> On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg <[hidden email]>
> 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
> [hidden email]
> 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
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Bert Freudenberg

Re: Future Release feature: A slide/glide tile

In reply to this post by Steve Thomas

On 28.02.2012, at 08:09, Steve Thomas wrote:

> On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg <[hidden email]> 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...)

Your proposed glide tile would be equivalent to a wait tile, in that it takes time. The tile after the glide tile in the same script would only be executed after the glide tile finishes. That's how this kind of tiles work in Scratch. I agree it's convenient. You can easily script "stories" (glide there in 1 sec, say something for 1 sec, come back in 1 sec) or play melodies (note C for 0.5 secs, then a D for 0.5 s etc). In Etoys you don't "script" objects from the outside (do this, then that, then that) as much as provide "behavior" for them (in any given situation, here's what you do).

Or did I misunderstand your proposal?

- Bert -

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Steve Thomas

Re: Future Release feature: A slide/glide tile

On Tue, Feb 28, 2012 at 9:01 AM, Bert Freudenberg <[hidden email]> wrote:

On 28.02.2012, at 08:09, Steve Thomas wrote:

> On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg <[hidden email]> 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...)

Your proposed glide tile would be equivalent to a wait tile, in that it takes time. The tile after the glide tile in the same script would only be executed after the glide tile finishes. That's how this kind of tiles work in Scratch. I agree it's convenient. You can easily script "stories" (glide there in 1 sec, say something for 1 sec, come back in 1 sec) or play melodies (note C for 0.5 secs, then a D for 0.5 s etc). In Etoys you don't "script" objects from the outside (do this, then that, then that) as much as provide "behavior" for them (in any given situation, here's what you do).

Or did I misunderstand your proposal?

Correct I do not expect the script to "wait" mid execution, until the glide completes, the glide tile is more like a start tile (in fact thats what I used in my prototype).

Providing kids a method to synchronize events is a whole separate request, but I haven't figured out a good way to do that yet.

So I took the project I created (attached to SQ-1021) and added a tile to change the color of a Rectangle after my glide tiles.

oneGlide and twoGlide basically call a script to set my GlidePlayers variables (Player to glide, target value and #secs), then makes a copy of itself and execute the copies script to "glide".

When executed, the gliding starts and the Rectangle changes color in the same cycle/step.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Future Release feature: A slide/glide tile

In reply to this post by Karl Ramberg

On Tue, Feb 28, 2012 at 5:19 AM, karl ramberg <[hidden email]> wrote:

(...)

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.

Hi, this is very cool but I found the "move toward" tile is hidden in "etoyFriendly". Is there a reason for this? Could we make it visible?

Cheers,

Richo

Karl

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Future Release feature: A slide/glide tile

On Tue, Feb 28, 2012 at 7:39 PM, Ricardo Moran <[hidden email]> wrote:

> On Tue, Feb 28, 2012 at 5:19 AM, karl ramberg <[hidden email]> wrote:
> (...)
>
>>
>> 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.
>
>
> Hi, this is very cool but I found the "move toward" tile is hidden in
> "etoyFriendly". Is there a reason for this? Could we make it visible?
>
> Cheers,
> Richo

Also then make the speed slot explicit so a slot like moveTowardSpeed
or something

Karl

>
>>
>>
>> Karl
>> _______________________________________________
>> etoys-dev mailing list
>> [hidden email]
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Future Release feature: A slide/glide tile

On Tue, Feb 28, 2012 at 3:45 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 28, 2012 at 7:39 PM, Ricardo Moran <[hidden email]> wrote:
> On Tue, Feb 28, 2012 at 5:19 AM, karl ramberg <[hidden email]> wrote:
> (...)
>
>>
>> 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.
>
>
> Hi, this is very cool but I found the "move toward" tile is hidden in
> "etoyFriendly". Is there a reason for this? Could we make it visible?
>
> Cheers,
> Richo

Also then make the speed slot explicit so a slot like moveTowardSpeed
or something

Yes, that would be even cooler. But IMHO etoys' support for that kind of "special" tiles is too hacky (see my proposed "ask" tile, for example).

That needs to be fixed, I think.

Cheers,

Richo

Karl

>
>>
>>
>> Karl
>> _______________________________________________
>> etoys-dev mailing list
>> [hidden email]
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Future Release feature: A slide/glide tile

In reply to this post by Steve Thomas

On Tue, Feb 28, 2012 at 1:33 PM, Steve Thomas <[hidden email]> wrote:

On Tue, Feb 28, 2012 at 9:01 AM, Bert Freudenberg <[hidden email]> wrote:

On 28.02.2012, at 08:09, Steve Thomas wrote:

> On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg <[hidden email]> 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...)

Your proposed glide tile would be equivalent to a wait tile, in that it takes time. The tile after the glide tile in the same script would only be executed after the glide tile finishes. That's how this kind of tiles work in Scratch. I agree it's convenient. You can easily script "stories" (glide there in 1 sec, say something for 1 sec, come back in 1 sec) or play melodies (note C for 0.5 secs, then a D for 0.5 s etc). In Etoys you don't "script" objects from the outside (do this, then that, then that) as much as provide "behavior" for them (in any given situation, here's what you do).

Or did I misunderstand your proposal?
Correct I do not expect the script to "wait" mid execution, until the glide completes, the glide tile is more like a start tile (in fact thats what I used in my prototype).

Providing kids a method to synchronize events is a whole separate request, but I haven't figured out a good way to do that yet.

There was some work done to make the ScorePlayerMorph work as a playback trigger/ sequencer that would work like that.

Skeleton is also interesting to bring in as a tool to do in between calculation over time. Both in animation and general programming.

Karl

So I took the project I created (attached to SQ-1021) and added a tile to change the color of a Rectangle after my glide tiles.

oneGlide and twoGlide basically call a script to set my GlidePlayers variables (Player to glide, target value and #secs), then makes a copy of itself and execute the copies script to "glide".

When executed, the gliding starts and the Rectangle changes color in the same cycle/step.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev