Sorry but I don't support. The 'bounce' blocks are just too convenient. I actually deleted the block from my copy of Scratch because of that. Besides, it can be replicated by:
[point in direction: (180 - (direction) )]
Offline
ScratchReallyROCKS wrote:
Sorry but I don't support. The 'bounce' blocks are just too convenient. I actually deleted the block from my copy of Scratch because of that. Besides, it can be replicated by:
[point in direction: (180 - (direction) )]
I honestly don't see why you feel the bounce block is "too convenient." It's helpful for inexperienced Scratchers that wouldn't be able to figure out how to make it otherwise. I can understand not supporting a bunch of easy-made scripts, but what's the big deal about this one block?
Offline
Harakou wrote:
ScratchReallyROCKS wrote:
Sorry but I don't support. The 'bounce' blocks are just too convenient. I actually deleted the block from my copy of Scratch because of that. Besides, it can be replicated by:
[point in direction: (180 - (direction) )]I honestly don't see why you feel the bounce block is "too convenient." It's helpful for inexperienced Scratchers that wouldn't be able to figure out how to make it otherwise. I can understand not supporting a bunch of easy-made scripts, but what's the big deal about this one block?
I understand how it could help inexperienced scratchers, but I think that a 'bounce' block that inverts the sprite's direction by itself would be sufficient. That way you could put in into an [if <touching edge>] block to replicate the [if on edge, bounce] block. The problem is, the [if on edge, bounce] block is clearly 3 blocks in one: if, on edge, and bounce. It teaches bad programming habits, because people aren't always going to be able to rely on heavily pre-programmed methods implemented into the API. Also, why make only one block like that? If they are going to follow that model, they could easily make a [if on edge, change <variable> by 1] block. See what I mean by too convenient now? I guess I over exaggerated what I meant before, The [if on edge, bounce] teaches bad programming habits, but a [bounce] block wouldn't.
Offline
Shouldn't Scratchers be programming physics themselves instead of having it all done for them? I can understand that some people want to get new blocks to make things easier, but there has to be a limit.
Offline
The reason we don't have the bounce block is because it would be to confusing for Squeak. See what Paddle2See wrote about it.
Offline
ScratchReallyROCKS wrote:
Harakou wrote:
ScratchReallyROCKS wrote:
Sorry but I don't support. The 'bounce' blocks are just too convenient. I actually deleted the block from my copy of Scratch because of that. Besides, it can be replicated by:
[point in direction: (180 - (direction) )]I honestly don't see why you feel the bounce block is "too convenient." It's helpful for inexperienced Scratchers that wouldn't be able to figure out how to make it otherwise. I can understand not supporting a bunch of easy-made scripts, but what's the big deal about this one block?
I understand how it could help inexperienced scratchers, but I think that a 'bounce' block that inverts the sprite's direction by itself would be sufficient. That way you could put in into an [if <touching edge>] block to replicate the [if on edge, bounce] block. The problem is, the [if on edge, bounce] block is clearly 3 blocks in one: if, on edge, and bounce. It teaches bad programming habits, because people aren't always going to be able to rely on heavily pre-programmed methods implemented into the API. Also, why make only one block like that? If they are going to follow that model, they could easily make a [if on edge, change <variable> by 1] block. See what I mean by too convenient now? I guess I over exaggerated what I meant before, The [if on edge, bounce] teaches bad programming habits, but a [bounce] block wouldn't.
Actually, no. Try what you just said yourself; it doesn't work.
Offline