So I created SQ-1021 http://tracker.squeakland.org/browse/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:
1. Change the width/length of a playfield, to create a Mouse Over drop down type menu 2. Glide to position X,Y in z seconds 3. Changing alpha to create fade in/fade out effects 4. 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:
1. 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) 2. 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: 1. player 2. numeric attribute 3. time 4. new value.
Cheers, Stephen
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 -
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
On Mon, Feb 27, 2012 at 7:52 PM, Markus Schlager m.slg@gmx.de 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Nice example
Karl
On Mon, Feb 27, 2012 at 7:10 PM, Bert Freudenberg bert@freudenbergs.de 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg bert@freudenbergs.dewrote:
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 projecthttp://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
On Tue, Feb 28, 2012 at 8:09 AM, Steve Thomas sthomas1@gosargon.com wrote:
On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg bert@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@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
On Tue, Feb 28, 2012 at 5:19 AM, karl ramberg karlramberg@gmail.com 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Tue, Feb 28, 2012 at 7:39 PM, Ricardo Moran richi.moran@gmail.com wrote:
On Tue, Feb 28, 2012 at 5:19 AM, karl ramberg karlramberg@gmail.com 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Tue, Feb 28, 2012 at 3:45 PM, karl ramberg karlramberg@gmail.com wrote:
On Tue, Feb 28, 2012 at 7:39 PM, Ricardo Moran richi.moran@gmail.com wrote:
On Tue, Feb 28, 2012 at 5:19 AM, karl ramberg karlramberg@gmail.com
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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On 28.02.2012, at 08:09, Steve Thomas wrote:
On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg bert@freudenbergs.de 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 -
On Tue, Feb 28, 2012 at 9:01 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 28.02.2012, at 08:09, Steve Thomas wrote:
On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg bert@freudenbergs.de
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-1021http://tracker.squeakland.org/browse/SQ-1021) and added a tile to change the color of a Rectangle after my glide tiles. [image: Inline image 1] 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
On Tue, Feb 28, 2012 at 1:33 PM, Steve Thomas sthomas1@gosargon.com wrote:
On Tue, Feb 28, 2012 at 9:01 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 28.02.2012, at 08:09, Steve Thomas wrote:
On Mon, Feb 27, 2012 at 3:10 PM, Bert Freudenberg bert@freudenbergs.de
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-1021http://tracker.squeakland.org/browse/SQ-1021) and added a tile to change the color of a Rectangle after my glide tiles. [image: Inline image 1] 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Mon, Feb 27, 2012 at 5:58 AM, Steve Thomas sthomas1@gosargon.com 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
karl ramberg -
Markus Schlager -
Ricardo Moran -
Steve Thomas