I really want a block that is JUST like the "if touching edge, bounce" block that is able to work when you touch ANY sprite, to make it simpler for more basic users to have things bounce on each other.

How would the sprite determine which direction it will bounce? What if the sprite where it bounces off to doesn't have a smooth surface? Or that it's a circle, surrounding the bouncing sprite?

Sorry, but no support.

ScratchJahd2011 wrote:

How would the sprite determine which direction it will bounce? What if the sprite where it bounces off to doesn't have a smooth surface? Or that it's a circle, surrounding the bouncing sprite?

Sorry, but no support.

So, you're telling me that there is no physical way in scratch that a ball can bounce off of another ball? Or, for that matter, that NOTHING can bounce off of a ball? Because that's what you're telling me is that there is no way in scratch that it can detect the angle of a surface and use the directions of each object with said angle to change one of the objects directions.

I remember this being suggested and I remember a good rebuke, uh…I don't think this is the right post but it still explains why this would be hard to implement, albeit in terms that are a bit technical for me to follow easily!

Starman99 wrote:

ScratchJahd2011 wrote:

How would the sprite determine which direction it will bounce? What if the sprite where it bounces off to doesn't have a smooth surface? Or that it's a circle, surrounding the bouncing sprite?

Sorry, but no support.

So, you're telling me that there is no physical way in scratch that a ball can bounce off of another ball? Or, for that matter, that NOTHING can bounce off of a ball? Because that's what you're telling me is that there is no way in scratch that it can detect the angle of a surface and use the directions of each object with said angle to change one of the objects directions.

No.

I'm telling you Scratch can't determine how a sprite bounces off, say, a sprite that is completely surrounding it, and touching it from every direction?

Wow, I can't even properly explain…

Sorry, but I think someone knows these stuff better than me, and can inform you why your suggestion can't happen.

You can bounce off a straight line or circle quite easily, but only in a few cases (off a straight line of a known angle, or a circle with a known centre). The reason this block wouldn't work is that it would be too intensive to actually calculate the angle of the surface, especially for bitmaps.

By the way, the basic script to bounce off a line is

turn right (((angle :: grey) - (direction)) * (2)) degrees

where (angle) is the angle of the line.

Scratch is not a gravity/velocity simulator so it would not be able to simulate bouncing off the ball/object without having to do TONS of math like: possible directions, the applied force of the ball, distance it should bounce, etc. This block doesn't really have a good USE and would be almost impossible to produce, there is a workaround that makes a ball bounce always in a certain direction though! Most blocks that have too specific use or are VERY vague, like your block, are really hard to implement so no support.

I would support but it can be work-arounded with

when green flag clicked
forever
    
if <touching [ v] ?> then
    point in direction (-90 v)
    move (10) steps
end

end

I support! (It looks like this, right?) (I changed my mind and it can still be workarounded )

if touching [ v], bounce // category=motion

It would be handy although there are a lot of reasons why it might not work.

Zro716 wrote:

~image clipped~

it is possible to bounce off an object given multiple contact points.

you find the “center of mass” of both images, whether by just taking costume center, logical center (based on image dimensions), or some convoluted calculus expression. then you calculate all the vectors from the “center of mass” to the contact points and average them. the negative of this resultant vector will point in the right direction.

obviously some images will result in counterintuitive behavior (for example, concave things and hollow images), so it should not be added. but it is possible nonetheless, if added into the scratch source code.

now to the point, I actualy think this “if on edge, bounce” is not necessary for many reasons. 1) it performs a very specific task that is not useful in general, 2) it interferes with learning real problem-solving by providing a too-easy solution.

Wes64 wrote:

Zro716 wrote:

~image clipped~

it is possible to bounce off an object given multiple contact points.

you find the “center of mass” of both images, whether by just taking costume center, logical center (based on image dimensions), or some convoluted calculus expression. then you calculate all the vectors from the “center of mass” to the contact points and average them. the negative of this resultant vector will point in the right direction.

obviously some images will result in counterintuitive behavior (for example, concave things and hollow images), so it should not be added. but it is possible nonetheless, if added into the scratch source code.

now to the point, I actualy think this “if on edge, bounce” is not necessary for many reasons. 1) it performs a very specific task that is not useful in general, 2) it interferes with learning real problem-solving by providing a too-easy solution.

I agree. That block is a little cheaty.

PaganoLeo10 wrote:

I would support but it can be work-arounded with

when green flag clicked
forever
    
if <touching [ v] ?> then
    point in direction (-90 v)
    move (10) steps
end

end

No it cannot. Eventually you will figure out why.

Zro716 wrote:

This is one problem. But this is the *slightly* bigger one:

If you have a 1 pixel dot moving horizontally towards a surface, no matter which direction the surface points in the little dot will always bounce 180 degrees and beginners will have no idea why.

Yeah, basically the smaller the objects are the harder it is to accurately bounce off stuff, rendering the entire world useless.

Yes, I'm talking about bitmap mode.

I can see how this can help.
We wouldn't have to use this long script:

when green flag clicked
forever
    
move (10) steps
if <touching [some random sprite v] ?> then
    
turn ccw (90) degrees
end

end

Instead, we could do this:

when green flag clicked
forever
    
move (10) steps
if on [some random sprite v], bounce
end

But then again,

Zro716 wrote:

So, both support and no support.

.

Semi support, I like the idea, but it is workaroundable.

Actual workaround is:

if <touching [... v]?> then
broadcast [flip v] and wait
move (10) steps    
end

when I receive [flip v]
point in direction ((direction) + (180)

{{}{]}

DaSpudLord wrote:

Flatoutj wrote:

.

Please don't necropost.

I don't support as per everybody else above.

Sorry, my friend was messing around an I couldn't undo the action. my bad

Flatoutj wrote:

{{}{]}

DaSpudLord wrote:

Flatoutj wrote:

.

Please don't necropost.

I don't support as per everybody else above.

Sorry, my friend was messing around an I couldn't undo the action. my bad

That's okay, just please make sure it doesn't happen again- Necroposting on the Suggestions forum is only okay if you're contributing to the discussion.