Scratch has finally evolved to the point where we can use the (distance to [Sprite]) and ([property] of [Sprite]) blocks with reporters as the sprite parameter. This is all fine and dandy, but two issues arise from it:
-It can reference a sprite that doesn't exist. Say you have a sprite called "banana" and you set the variable (sprite) to "bannana". Trying to access (distance to (sprite)) doesn't tell you anything about whether the sprite exists or not. If it instead returned "undefined" or a friendlier "unknown", it would help immensely with debugging.
-A sprite doesn't know what its name is. This could be remedied with a simple "my name" block in Sensing. It would take about five seconds to implement (four hours for me, but I could do it!) Think of the possibilities. Sprites could add their names to a list and dynamically get each others' properties. A [broadcast [Message] to [Sprite]] block would really make this awesome, but I'm not going to get into that.
Scratch team, please, consider these suggestions. They would make Scratch 1.4 so much easier to use.
Last edited by fullmoon (2009-06-07 13:52:18)
Offline
fullmoon wrote:
Scratch has finally evolved to the point where we can use the (distance to [Sprite]) and ([property] of [Sprite]) blocks with reporters as the sprite parameter. This is all fine and dandy, but two issues arise from it:
-It can reference a sprite that doesn't exist. Say you have a sprite called "banana" and you set the variable (sprite) to "bannana". Trying to access (distance to (sprite)) doesn't tell you anything about whether the sprite exists or not. If it instead returned "undefined" or a friendlier "unknown", it would help immensely with debugging.
Quite agreed. But if it doesn't work, the first thing I normally do is check to see if things like that are correctimisso.
-A sprite doesn't know what its name is. This could be remedied with a simple "my name" block in Sensing. It would take about five seconds to implement (four hours for me, but I could do it!) Think of the possibilities. Sprites could add their names to a list and dynamically get each others' properties. A [broadcast [Message] to [Sprite]] block would really make this awesome, but I'm not going to get into that.
Scratch team, please, consider these suggestions. They would make Scratch 1.4 so much easier to use.
THAT is a much-needed addition. Absolutely amazing. Add it NOW, Scratch Team! Shouldn't be too terribly hard!
These are great suggestions I never would have though of, seeing as I didn't tinker too much with 1.4.
Last edited by coolstuff (2009-06-07 21:24:28)
Offline
These are awesome idea fullmoon, and I look forward to see Scratch 1.4, hopefully with the ideas in it.
Last edited by Jonathanpb (2009-06-23 02:04:52)
Offline
Nice idea...
I'd also love to see blocks to turn strings to upper/lower-case. Like (upper-case [string]). Mainly because the new <[]=[]> block distinguishes (sp?) caps, so THIS =/= this (CORRECTION: No it doesn't. Both off and online. YAY).
Last edited by technoguyx (2009-06-08 10:19:59)
Offline
coolstuff wrote:
fullmoon wrote:
Scratch has finally evolved to the point where we can use the (distance to [Sprite]) and ([property] of [Sprite]) blocks with reporters as the sprite parameter. This is all fine and dandy, but two issues arise from it:
-It can reference a sprite that doesn't exist. Say you have a sprite called "banana" and you set the variable (sprite) to "bannana". Trying to access (distance to (sprite)) doesn't tell you anything about whether the sprite exists or not. If it instead returned "undefined" or a friendlier "unknown", it would help immensely with debugging.Quite agreed. But if it doesn't work, the first thing I normally do is check to see if things like that are correctimisso.
-A sprite doesn't know what its name is. This could be remedied with a simple "my name" block in Sensing. It would take about five seconds to implement (four hours for me, but I could do it!) Think of the possibilities. Sprites could add their names to a list and dynamically get each others' properties. A [broadcast [Message] to [Sprite]] block would really make this awesome, but I'm not going to get into that.
Scratch team, please, consider these suggestions. They would make Scratch 1.4 so much easier to use.THAT is a much-needed addition. Absolutely amazing. Add it NOW, Scratch Team! Shouldn't be too terribly hard!
These are great suggestions I never would have though of, seeing as I didn't tinker too much with 1.4.
I agree. So many times have I wished for this when making projects because it would save a lot of scripting just to have a block to do it for you.
Offline
Here's an example of why a "my name" block would be useful:
//Stage When Flag Clicked{ count=0 delete (all) of [masterSpriteList] broadcast [enumerateSprites] and wait broadcast [start] }
//On sprites When I receive [enumerateSprites]{ add (my name) to [masterSpriteList] } When I receive [start]{ i=0 repeat(length of [masterSpriteList]){ if <touching (item (i) of [masterSpriteList])>{ pointInDirection(180-direction) } i++ } }
In this way we could cycle through sprites and have much more efficient collision detection and such. It's a simple, yet powerful feature.
Last edited by fullmoon (2009-06-08 23:25:46)
Offline
fullmoon wrote:
Here's an example of why a "my name" block would be useful:
Code:
//Stage When Flag Clicked{ count=0 delete (all) of [masterSpriteList] broadcast [enumerateSprites] and wait broadcast [start] }Code:
//On sprites When I receive [enumerateSprites]{ add (my name) to [masterSpriteList] } When I receive [start]{ i=0 repeat(length of [masterSpriteList]){ if <touching (item (i) of [masterSpriteList])>{ pointInDirection(180-direction) } i++ } }In this way we could cycle through sprites and have much more efficient collision detection and such. It's a simple, yet powerful feature.
Man I wanted that since 1.2.1... I even made a project wishing for that...
Offline