Suppose when I make a Ball and set
<when green flag clicked>
<forever>
<change x by( 10 )>
<when green flag clicked>
<forever if><touching color[ Red ] >
<stop script>
And make a red object in right .
So now when I play it the Ball goes little further in the red object and then stops.
What I am saying is scratch should improve its performance foe best results.
Offline
[Stop Script] stops the script it's in. What you could do is:
[blocks]
<when green flag clicked>
<forever if><< <not> <touching color[ Red ]> >>
<change x by( 10 )>
<end>
[/blocks]
Last edited by Magnie (2011-04-23 09:56:58)
Offline
This has nothing to do with Scratch's performance. It overlaps with the red a little because it only checks to see if it's touching red after it moves 10 steps. Therefore, it might be not touching red but be 4 steps away, so it moves 10 steps again, finds itself in red, and stops.
Offline
This gives the same performance with no overlap.
Scratch deals with following instructions to the letter, which does make it efficient, you just need to define your purpose correctly.
Last edited by Kileymeister (2011-04-23 19:21:33)
Offline
The "stop script" block only stops the script it is attached to. So the second script is stopped, but not the first.
Offline
First, make sure the ball or the red object is greater than 10 pixels big then:
<when green flag clicked>
<forever>
<if><touching color[ red ]>
<stop script>
<end>
<change x by( 10 )>
<end>
Offline
If it REALLY bothers you, once it touches the red, make the ball go in the opposite direction after it touches the red for one pixel until it's off.
The reason it goes in the red is because the sprite is moving ten pixels at a time, so unless it's 10, 20, 30, 40, etc. pixels away from the red (any number divisible by 10), it's going to go in the wall by the number of pixels in the last digit.
Let's say it's 36 pixels away, the sprite will go in 6 pixels.
Offline
One thing programming has taught me: it is always my fault, no matter how much I want it to be the computers
Offline