An example of what I'm trying to do: One sprite with two scripts:
script 1:
when greenFlag clicked
point in direction 0
broadcast 'go' and wait
point in direction 90
script 2:
when I receive 'go'
forever if not direction=-150
turn left 15 degrees
Problem: The last line of script 1 doesn't ever get executed.
Workaround to get this going:
script 2:
when I receive 'go'
forever
if not direction=-150
turn left 15 degrees
else
stop script
I tend to consider this a bug.
Markus
Offline
The "forever if" block is equivalent to having an "if" block inside of a "forever" block. As shown in your workaround, only the "stop script" block will get you out of the forever loop.
Last edited by paulmedwal (2007-03-27 23:15:44)
Offline
I must say I find the "forever if" block a bit confusing and useless. I first thought too it was a "do while" block, which ends when the condition isn't true anymore.
Like you say it is easy assembled of only two other blocks, so I would propose to get rid of this block in Scratch. (and add a "repeat until" block, which is usable as "do while" by adding a "not", but that's already planned for version 1.1)
Offline
If "forever if" is implemented right, it should be the equivalent of
forever
wait until <condition>
action
rather than
forever
if <condition>
action
The difference is a subtle one: wait should only be executed when the variables that are involved in the condition change, while "if" has to be continuously evaluated (though the forever-if construct can be optimized to forever-wait.
Offline
<forever if>
The above block is obsolete
Offline
Forever if is not obsolete. However, I tend to use
forever
if
because it is much more flexible.
Offline
As far as I'm concerned the forever if block is worthless. I would much rather have a block that evaluates at the bottom, forcing the code to execute at least once before exiting the loop.
kevin_karplus said:
The difference is a subtle one: wait should only be executed when the variables that are involved in the condition change, while "if" has to be continuously evaluated.
And how does the computer know the variables have changed? Well, it isn't magic! Event driven programming only hides the evaluation process in order to make things easier on the human programmer. Trust me when I tell you that your microprocessor is still continuously evaluating every condition capable of triggering an event. Furthermore, just because a given evaluation is not associated with an event does not mean that it has not been optimized by branch prediction. And so even an if statement can wait for the values to change before doing a full reevaluation.
Last edited by axorion (2010-11-18 13:09:35)
Offline
This topic's from 2007... I think it's time to close it.
Offline