Scratch

EdnaC wrote:

I think that a receive sensing block would just be confusing, as it is very easy to implement with the basic commands that exist.  Instead of sending a broadcast, you could just change a variable when you want the paused script to continue (or whatever it is that you want). 

"Wait until I receive" could be done like this:

|-Forever
|  If Variable = 0
|  Wait 0.05
|  Stop Script   (this will just make the script keep waiting)
|       
|  Do the stuff you were waiting for....  (This will execute when the variable changes)
|  Varible = 0 (To keep the script from running again)

It seems just as easy to switch the value of a variable as to send a broadcast (to me).

Mr Ed

yes but variables sometimes mess up the script if ur doing an rpg game for example, you know when you have like so many number scripts and too many variables, (the ones you already have) it gets kind of glitchey  or buggy. that why things like the next costume trick wont work when you have that. belive me, if anything, scratch needs to be able to hold more data.

Heybrian wrote:

funkymonkey wrote:

Heybrian wrote:

not if you have like ten scripts and ur doing an rpg game. that is one script. imagine a 1 week long rpg game to make. it will not work .same with     
            <when I receive[ shoot
              <repeat until> <( costume # <=> 4 )>
                  <next costume>

what is that script working for? once you know that, then you can decide if it will work.

huh?

nevermind. my point is, both of the scripts you pointed out will work

funkymonkey wrote:

Heybrian wrote:

funkymonkey wrote:

what is that script working for? once you know that, then you can decide if it will work.

huh?

nevermind. my point is, both of the scripts you pointed out will work

not with big scripts

Heybrian wrote:

funkymonkey wrote:

Heybrian wrote:

huh?

nevermind. my point is, both of the scripts you pointed out will work

not with big scripts

so have it with a lot of small scripts. it will still work the same way, only maybe a little slower.

Heybrian wrote:

yes but with a message fafter it.     /i recive "message"\
                                                  \                        /

like this?

funkymonkey wrote:

Heybrian wrote:

yes but with a message fafter it.     /i recive "message"\
                                                  \                        /

like this?
http://i243.photobucket.com/albums/ff67 … ecieve.jpg

Yes thats perfect.

and also if you need to end a script by broadcasting something you cant recive after the scripts going, so the sensing bloc would really help for that.

funkymonkey wrote:

Heybrian wrote:

funkymonkey wrote:

nevermind. my point is, both of the scripts you pointed out will work

not with big scripts

so have it with a lot of small scripts. it will still work the same way, only maybe a little slower.

very slower

Heybrian wrote:

[yes but variables sometimes mess up the script if ur doing an rpg game for example, you know when you have like so many number scripts and too many variables, (the ones you already have) it gets kind of glitchey  or buggy. that why things like the next costume trick wont work when you have that. belive me, if anything, scratch needs to be able to hold more data.

You are probably having "glitches" because you have global variables (variables for all sprites) that are being changed by differents scripts.  If a script is waiting for a variable to change, and several other sprites could be running scripts that modify that variable, you will really have a hard time tracking down the "bug".

You should try to limit variables to be "for this sprite only" whenever possible.  The new ability to "sense" the value of another sprite's variables (but not change that sprite's variables) really helps with this.  Keeping variables "for this sprite only" also helps a lot with managing the big list of variables that a large project needs.

When planning a project, it's a good idea to start on paper with a list of the sprites that you'll need, the variables and broadcasts that will do the control, and put some thought into which sprites need to be able to change variables, as opposed to just being able to "know" what the variable's value is.  Having fewer "global" variables will really help you to avoid problems.

-Mr Ed

Heybrian wrote:

funkymonkey wrote:

Heybrian wrote:

yes but with a message fafter it.     /i recive "message"\
                                                  \                        /

like this?

But soon after that peaple are going to be complaining about needing broadcast sensing blocks.

that would be good too

EdnaC wrote:

Heybrian wrote:

[yes but variables sometimes mess up the script if ur doing an rpg game for example, you know when you have like so many number scripts and too many variables, (the ones you already have) it gets kind of glitchey  or buggy. that why things like the next costume trick wont work when you have that. belive me, if anything, scratch needs to be able to hold more data.

You are probably having "glitches" because you have global variables (variables for all sprites) that are being changed by differents scripts.  If a script is waiting for a variable to change, and several other sprites could be running scripts that modify that variable, you will really have a hard time tracking down the "bug".

You should try to limit variables to be "for this sprite only" whenever possible.  The new ability to "sense" the value of another sprite's variables (but not change that sprite's variables) really helps with this.  Keeping variables "for this sprite only" also helps a lot with managing the big list of variables that a large project needs.

When planning a project, it's a good idea to start on paper with a list of the sprites that you'll need, the variables and broadcasts that will do the control, and put some thought into which sprites need to be able to change variables, as opposed to just being able to "know" what the variable's value is.  Having fewer "global" variables will really help you to avoid problems.

-Mr Ed

ohhhhhhhh. i always used global variables just in case id need them for everybody. ok i'll try that

funkymonkey wrote:

Heybrian wrote:

Okay heres something every scratch RPGer hates. one word. LAG! It makes the game so laggy if you have small scripts. My point is,  with this block a bunch of reasons AND you wont have to start more scripts.

i hate lag too. but, small scripts do not affect the speed of a project. Like Kevin said, its the amount of small scripts. anyways, dont long scripts make it laggy? they have so many commands in them that wouldnt it be harder to read for Scratch?

thats exactly what i said. long scripts are ussaly fine in scratch (downloaded) but only sometimes, and are even worse online

Heybrian wrote:

ohhhhhhhh. i always used global variables just in case id need them for everybody. ok i'll try that

lol, me too. i never thought it would make a difference