[blocks]When I first came across scratch, I DID think that it was like
<if>
<forever>
<end>
<end>
but now I know whit it really is for, and I use it a TON in my projects, and if it was removed most of my project won't work.
<when green flag clicked>
<forever if><( <{pauseed }> <=> 0 )>
<move( <{ speed }> )steps>
<next costume>
<play sound[ some sound ]and waits>
<pen down>
<change x by( 6
<wait( 1 )secsc>
<pen up>
<stamp>
<if><touching color[ white
<stop script>
<end>
<change{ loops }by(1
<broadcast[ check if project should be paused ]and wait c>
<end>
[/blocks]
Because of forever if, I could build a pause thing in my pjoject. I could have used forever and if, but forever if is quicker and actually reduces lag a bit.
EDIT: I hate the forum blocks
Last edited by joefarebrother (2011-07-29 11:01:14)
Offline
06dknibbs wrote:
There may be a problem with this, if the block is removed now that so many projects use it, some of the older projects may become unplayable as Scratch won't support that block.
Actually, if you see there's some projects of Scratch like http://scratch.mit.edu/projects/RHY3756547/1059859 in which it includes an old block (Stretch), and works online. And this would be for Scratch 2.0-All Scratch 1.4 block games would be playable, as we can play older Scratch games. The player supports all of the blocks of new and old versions-Scratch, on the other hand, doesn't. So the project would work online yet not offline.
Offline
Death_Wish wrote:
06dknibbs wrote:
There may be a problem with this, if the block is removed now that so many projects use it, some of the older projects may become unplayable as Scratch won't support that block.
Actually, if you see there's some projects of Scratch like http://scratch.mit.edu/projects/RHY3756547/1059859 in which it includes an old block (Stretch), and works online. And this would be for Scratch 2.0-All Scratch 1.4 block games would be playable, as we can play older Scratch games. The player supports all of the blocks of new and old versions-Scratch, on the other hand, doesn't. So the project would work online yet not offline.
Obsolete blocks WORK OFFLINE!!! As far as I can tell, they aren't saying to delete it completely, but to make it obsolete. That means it will appear and it will work, but you can't create new versions of it from the Control block palette.
Offline
jslomba wrote:
EdnaC wrote:
Delete "forever if" ?
Not going to happen.Why?
The ForeverIf block is Scratch's "while loop", common in most computer languages.
From Wikipedia:
"In most computer programming languages, a while loop is a control flow statement that allows code to be executed repeatedly based on a given boolean condition."
*This block is used by Scratchers more than the (very common) "If-Else" block.
*It replicates a syntax that is common in other languages. (Part of the idea of Scratch is to let people learn programming.)
*It's more sensible than using a "Forever" loop, because it can be used to turn off a loop that isn't needed - speeding up the project.
Yes, you could do the same thing with an "If" inside of a "Forever" loop, but there are lots of blocks you could do without by combining other blocks.
ForeverIf is here to stay (IMHO).
Offline
JTxt wrote:
Yes, if it behaved like "while loop", it would make sense and be more useful, but it does not.
Instead it is a "if, loop forever" and causes confusion.
You are incorrect. It is a "pre-test" while loop. If the boolean is true the loop runs, if the boolean is false, looping stops. The loop will restart if the boolean becomes true again. According to the Scratch Wiki, this block is also somewhat faster than the "workaround".
Offline
JTxt wrote:
it is a "if, loop forever" and causes confusion.
JTxt is an experienced scratcher and even he doesn't know how the block works.
This is exactly what I'm talking about. The block is not clear on what it does.
06dknibbs wrote:
There may be a problem with this, if the block is removed now that so many projects use it, some of the older projects may become unplayable as Scratch won't support that block.
Not at all!
I propose that whenever a project is opened, if it contains a
<forever if>
<end>
it would be silently replaced with
<forever>
<if>
<end>
<end>
Offline
BoltBait wrote:
Not at all!
I propose that whenever a project is opened, if it contains a
<forever if>
<end>
it would be silently replaced with
<forever>
<if>
<end>
<end>
I'd propose to quietly replace
<forever> with <forever if> (1 = 1)
Offline
As I haven't bothered to read the entirety of this thread, I'm just going to state that the block should not be removed but hidden, like motor blocks.
Offline
It seems to reduce lag, because rather than running a forever, it just runs an if. Right?
With an if inside a forever, the program has to keep running a forever, but this way it is only checking to see if the boolean is true before making any actions.
Am I right, or am I missing something?
IMO I think it should be kept. (If what I've stated above is true)
Offline
oh man. i rembered it backwards. sorry.
i see uses for it now but i also think it's confusing and not needed.
But i tend to put multiple ifs and other blocks nested in a loop...
(i havn't tested forever if yet for speed, but i think doing confusing tricks to apease the interpreter is backwards. including all the 1 sprite 1 script scripting which i do for speed.. but one frame per loop is how they designed this learning language. go byob and atomic blocks!)
Offline
Delete. Too confusing and stupid and stuff.
Offline
TimeFreeze wrote:
It seems to reduce lag, because rather than running a forever, it just runs an if. Right?
With an if inside a forever, the program has to keep running a forever, but this way it is only checking to see if the boolean is true before making any actions.
Am I right, or am I missing something?
IMO I think it should be kept. (If what I've stated above is true)
*According to the Scratch Wiki, Forever If is faster than an If inside a Forever.
*Forever If replicates the "While (boolean is true) Do" loop of other computer languages.
*It is used more by Scratchers than the "If Else" block (according to the Stats).
*It reduces the width of scripts (which can become a problem on small screens).
*It won't be deleted from Scratch.
If the ST deleted stuff that is confusing to people, Broadcasts would be on the chopping block - Look at all of the suggestions to put 'receive' blocks inside scripts, if you understand that a broadcast is an event, this obviously doesn't make sense, ergo, many users don't understand broadcasts.
Offline
EdnaC wrote:
If the ST deleted stuff that is confusing to people, Broadcasts would be on the chopping block
Actually, less people understand the forever if block--they believe it is (if < >, forever { do something}). Actually, for this precise reason, it was a long time before I used forever if--I used if inside forever. The advantage of if inside forever is that you can run multiple ifs at once--you can do if <this arrow key pressed>, if <another arrow key is pressed>, etc. in a single script, whereas with forever if you need 4 scripts.
At the very least, they should rename it to something less confusing. Maybe the "while" loop you mentioned? Personally, I think they should make it obsolete.
Offline
I put multiple "Ifs" and "If Else" statements inside a "Forever If". The first condition makes it easy to turn off the script (useful if you wanted to pause, or if the sprite isn't active).
The idea of an unconditional "Forever" statement is pretty odd; In some environments, this would be like stating "lockup my computer, until I use CTRL-ALT-DEL to kill this game". Scratch protects users from the lockup - but if you are looking at a program in another language, you'd likely see "while (1=1) do". (Somewhere inside the loop, there would have to be a way to break or exit the loop.)
Early in my projects, I'll use "Forever If (1=1)" for something (like keyboard input) that I always want running. If I later decide that loop can (or needs to) stop under certain conditions, the change is as easy as putting a "real" condition into the Forever If, otherwise, I just leave the (1=1).
Think about how easy it is to really screw up a script by tearing it out to make a change and accidentally dropping it where another script sucks it in...
In any case, this block isn't going away - You could work around not having it (but suffer a small performance hit), but this is true of a lot of blocks. I'd say this entire thread just points out a need to clarify the function of Forever If in the getting started guide and perhaps to use it in some of the sample projects.
Offline
EdnaC wrote:
In any case, this block isn't going away - You could work around not having it (but suffer a small performance hit), but this is true of a lot of blocks.
Consider the following two obsolete blocks:
rewind sound
say nothing
These were removed because they could easily be done with other blocks, were glitchy, or weren't necessary. For example, although I haven't used the rewind sound before, I believe it works like this:
stop all sounds
play sound
And say nothing could be done by ending the script.
So--the Scratch Team believed that since both of these blocks could be easily accomplished with other blocks, they should be removed.
So why is it even vaguely necessary to use forever if? Because of a slight increase in speed? Is that worth confusing many new Scratchers, and clogging up the block palette?
I don't think so.
Offline
Take it off! It's such a waste.
Offline
If they're not going to remove this, at least add
forever if <>
else
Offline
[blocks]It isn't like a while loop. A while loop ends once the condition becomes false, basically like
<repeat until><< <not> >> [/blocks]
It should be renamed to something like
|From now on, whenever <> do|
{a script}
Last edited by joefarebrother (2011-08-08 01:54:34)
Offline
I, actually thought it was
If <>
| forever
| |(stuff)
| /forever
/if
stop script
Support.
Last edited by scratchisthebest (2011-08-08 09:38:43)
Offline