Hi everyone,
I have a situation where a sprite is placed somewhere on the stage, then the script is executed and the sprite is moved. If the script is stopped during execution, the sprites are not reset, so when it is restarted the sprites continue from where they stopped.
Is there a way to reset them to the starting position everytime the script is run, other than hard coding a start X and Y into each sprite as variables?
I have tried capturing the starting X and Y on script execution, but this is always the location that they are when the script is started, not where they were originally placed by the program designer.
Offline
I would like to point out that as a good software development practice, you need to "initialize" each variable before they are used. What you are doing here is just one more example about why this is an issue.... and why software bugs often show up.
In addition to the x and y position of the sprite, you also should initialize the direction, pen color, costume, and other properties of sprites as well as assigning values to ordinary variables as well each time you restart the script with the green flag.
The best way that I've seen to reset the x and y position is to use the "go to x: y:" block immediately after the "When (green flag) clicked" block on the script of the sprite.
One thing you might want to remember is that the x and y values on this block don't change automatically if you are moving the sprite around. One way to keep from having to guess these numbers is to click on another type of blocks on the design interface and then click on the "Motion" type of blocks. When this is done, the "go to x: y:" block shows the current coordinates of the sprite.
I've created a (very small) demo of this idea here using the default "kitten" sprite:
http://scratch.mit.edu/projects/Roberth/5052
I would like to suggest to the Scratch development team that perhaps these coordinates ought to be automatically set to the current sprite coordinates whenever this block is dropped onto the script of a sprite. There may be good reasons to keep the current behavior, but it seems to be to be far more confusing for exactly this reason listed by the parent poster.
Last edited by Roberth (2007-05-20 00:25:34)
Offline
Thanks for the response Roberth.
The issues that I have is that I might attach some particular behaviour to a sprite, so that I can reuse it in many projects (Object Oriented style), so building in a specific "Move to X, Y" is not very useful because if the object is duplicated for use in the same or another project, the start point would be different.
It seems very fiddly to have to reset manually some parameters in the code each time an object is reused.
So, what I am proposing (if no one know how this can be done now), is that either:
1) Objects reset to where they were placed in the "design" of the application when the application is restarted or "reset", or
2) You are able to capture into relevant variables the original location that a sprite was placed during design, and then force a reset to there using "go to X, Y"
Offline
One of the ways that this is dealt with in most other GUI/RAD development environments (aka Visual Studio/Delphi/etc.) is that each graphical "object" has a set of initial "properties" that are always reset to these values each time the software is started. If you copy/paste one of these graphical objects, and then manipulate them by moving the object around the screen, these properties are automatically adjusted by the development environment. You can also adjust other aspects of the object initial conditions... usually with some sort of property editor.
This property editor seems to be something that the Scratch team has deliberately left out of the design process for some reason. It does seem to simplify the development environment in terms of having one less thing to get in the way, where the language syntax (aka the blocks) is instead taking up the screen space normally used by such a property editor. This is one of the design compromises that went into making Scratch what it is right now.
So the short answer to your question.... can you have the sprites "reset" to their original starting position each time you start the program (aka with the green flag)? No. That isn't even good software design philosophy. Even if you have some sort of property editor, this is just a way to "hide" the process that would have to happen anyway that would initialize these values. All you are talking about is a different method of setting these initial x and y values for each sprite.
Many C# editors, to use an example, actually manipulate the code (aka the "script") directly when you move the graphical objects, in addition to changing the values in the property editor. In other words the property editor is just a tool to help you build this "initialization" section. And you can also change the position of the object by directly editing the code as well in most of these editors. Having Scratch to perform this task, while easy to describe, is hardly a trivial thing to accomplish. Perhaps I'm mistaken, but this seems like one of those tasks that takes 1 minute to describe and 1 month to code and another 2 months to debug for unwanted side behavior.
For the current version of Scratch, the only method of setting up some sort of initial state for a sprite is to explicitly set those properties (such as the x and y coordinates) at the beginning of the script.
BTW, there is some hidden strength to allowing you to incrementally modify objects from their current state, allowing you to experiment. As a learning environment, this allows you to try different options and "play" with these concepts, throw out some blocks and add new blocks, and then see what will happen from that point.
And keep in mind that in a certain sense, there is no real "program start" for any Scratch project. It is always "running". The "green flag" is just one more trigger like a key press or mouse click to manipulate the behavior of the software. That quite often it is used to reset the software to some initial state is true (and a recommended behavior), but this does not have to be the only behavior for this kind of "event". You shouldn't ascribe any mystical or unique properties to the green flag that are forced on it by the Scratch environment, other than it is something that is always displayed on every project.
Offline
Hi Roberth,
In the end I fixed this by linking two sprites, one as the starting point, and one as the moving object. See here: http://scratch.mit.edu/projects/leaskn/5153
Works OK, but it is a little hard to explain to others how to use. Which makes me wish that there was a "Comments" block so allow documentation of code and logic.
Offline
The green flag *does* have special properties on the web site---it always gets clicked for you automatically. This is yet another difference from the squeak implementation.
It is probably a good thing to do, but does mean that you can't use the return key freely in your code, as it will always have the additional effect of being pressed at the beginning of a web-based presentation.
Offline
Hi, all.
A handy (but non-obvious) trick is that when you click on the "Motion" category the x and y parameters of the "go to" and "glide" blocks get filled in with the sprite's current position. This saves time when creating scripts to initialize the positions of your sprites. Just select the sprite, click on the "Motion" category, drag out the "go to" block, and put it under a green-flag hat. Presto! Your sprite now starts at the right initial position when you press the green flag hat.
This trick is also handy for making a sprite glide through a sequence of positions. Move the sprite to each position, click the "Motion" category, drag out a "glide" block and add it to your script. You can then go back and adjust the glide times to get the speed that you want.
-- John
Last edited by johnm (2007-05-20 14:40:40)
Offline