Here are the blocks
and
so you can create the block
as well other combinations.
Here is a variation of the "on edge" block
that also allows for
and you can still use as
and
so you can create the block
as well other combinations.
that also allows for
and you can still use as
I like the idea of reimplementing primitives to show how they work!
But I think your BOUNCE block is buggy, and not just because you left out the number at the top. You're right that sometimes 360-direction is the right thing and sometimes 180-direction is. But what makes the difference is not the direction of the sprite but whether the edge it hit is vertical or horizontal. A vertical wall needs 360-direction; a horizontal wall (otherwise known as the ceiling or the floor) needs 180-direction.
Do some experiments. For example, put the sprite near the top of the stage and set its direction to 350, and see what your BOUNCE does.
Ok, could you show me the script pic of your new and improved bounce block?
I hadn't made one, but here one is. It's a little complicated because of the case in which the sprite hits an exact corner of the stage.
Quite good! nice!
Nice! You might want to generalize it for variable stage dimensions... 
Also, the actual if on edge, bounce block also works if the sprite has since turned.
Uh, I also like the idea!
Some minor details though... (sorry for the nitpicking ;))
-
It'd be way cooler, if the block worked for any stage size, meaning you should e.g. change the < > 179 to
-
The sprite bounces as soon as it touches the stage. In your version, the sprite can move its rotation center to the edge of the stage which means that half the costume is outside of the stage when your rotation center is at the center of the sprite (that's perfectly fine but not how the "if on edge bounce" block works).
-
Technically, you can even move your sprite's x-position outside of the stage boundaries if you set the rotation center somewhere off the costume's center:
But Brian is right. Cool idea to reimplement some of the primitives to see how they work. It's not that easy sometimes 
Cheers,
jadga
Yes, reimplement primitives is cool. And not only to see its way... also to find new ways and also to change behaviors (do what you want).
About "on edge"...
Really, "on edge" is just
but yes, current "on edge..." is really "on edge or outside". But then, it is just 
No sizes, no calculations...
Note: If you change "my rotation x/y", current "if on edge, bounce" is not running ok. But "touching" sensors are still fine!
Maybe it is laggier... but I like it!
Joan
Very nice!
How does the actual if on edge, bounce block work then?
Oh, it works mostly the same, but instead of checking the numeric position of the sprite it checks "touching edge" which checks whether any part of the sprite is on an edge. You can use 
(right, top, bottom) to compute the edges of the sprite if you want to simulate it. (Computing whether or not this sprite is touching another sprite, which is irregularly shaped, is much more complicated.)
What would a bounce block that uses sprites as walls look like? Would it be the block earlier in these replies but instead of the "if on edge" blocks it was "touching sprite" blocks or something else?
Some thoughts on bouncing against sprites:
- We may think of bouncing against a sprite’s perimeter as a way to stay on (or return to) the outside of the sprite, but in reality an object may as well be (and remain) on the inside.
- Ideally, the object having touched a sprite will change direction such that the new direction is a function of its original direction and the direction of the sprite’s local tangent to the perimeter. However it may be hard to tell where exactly the sprite first touched the sprite’s perimeter. A practical solution may be to assume the tangent to be perpendicular to the line from the bouncing object’s center to the sprite’s center - even though I can think of cases where this will occasionally produce strange results.
- When the object moves very fast, it may have passed through, and past, a sprite - and there is no obvious way to detect it.
- The object may get stuck bouncing back-and-forth between multiple sprites.
- According to the laws of mechanics, it’s not just the object, but also the sprite, that will change direction on impact. How much depends on the mass ratio.
- The object may also start to rotate as a result of a bounce.
Sorry for exposing dev version.
If you go to Snap! 10, and turn Blocks all the way in settings, then you edit the "if on edge, bounce" block, you get to see the full-fledged definition of the primitive!
The code looks complicated, I hope that you understand the code.
Wait... that was 3 year old and someone pushed it to the top with a necropost?