Resized circle falsely touches another circle

Use this template to make awesome bug reports:

Your username: anisotr0py

What kind of device are you using?:
iPad Pro (4th gen) (HS says "“iPad8,11”)
iOS 14.5.1
HS version 3.46.6
Player version: 1.5.14

1 sentence description of the problem: I was trying to do some physics based on when two objects were touching, but then I saw that there were false touches between objects happening.

Steps that the Hopscotch team can take to reproduce my problem every time:
I don’t know about every time (the last time I found a bug (still there!) with touching, it was sometimes evident but sometimes not), but for this bug I did this:

  1. Create two circles, one big one small, the bigger one was resized by “Set Size” when game starts.
  2. As the little circle is moved around by dragging, assess when the two circles touch by changing the color and width of a drawn trail.

I expected this to happen: circles should “touch” according to HS when they actually touch according to Geometry

But instead this happened: The circles touch in an extra area to the lower right of the bigger circle.

Here’s a sweet screenshot: This project demonstrates the bug and it’s thumbnail tells the story:

I’m very curious if others can reproduce this behavior in this project.

Also, have others seen this before? When I searched HSF for “bug touch” I didn’t find something like this; sorry if I missed something.


I wonder if something is wrong with the circle model itself, though I have pretty much no knowledge of the “collision factory” in the webplayer.

I say that because flipping (movement block) the larger circle causes that region to be on the left.

Just figured I’d add this finding

Also, can you find any other shapes this happens with? I only got that to work with the Circle shape so far, nothing else.

And yeah I was able to reproduce by just playing the project


Interesting! I’m glad the project worked for you; I may have procrastinated a BIT too much by making it and then trying to make the perfect thumbnail…

And I see a goof in my write up above; it is the presence of a “set width, height” block that triggers the bug; if you manually resize the circle to have similar size and shape in the object editor view (what is it officially called?!) and remove the “set width, height” block: no bug.

My previous text clone touching bug is kind of subtle, but, um, circles? What the heck?


Yeah I know it is dependent on set width/size (or at least I figured it would be) but like I said I am no expert on collisions.

At some point I’ve just migrated to conditional collisions – and yeah I agree it shouldn’t have to be everyone’s main method of reliable collisions – that in a sense does prove your point.

If I have the time and will to figure this out, maybe I can fix it and probably bundle this with the other small (but important) fixes in an upcoming webplayer update. Not sure though, since again I lack the experience in debugging HS collisions, and my main thing is the Web Explorer.


I just noticed that to a smaller extent, the “squished box” object also shows this bug (but not donut or flower; though haven’t been thorough)

I don’t know what this means, can you explain more? Is there a different but equally fast way I could be doing the touch detection with the circles in my project?

(I certainly don’t want to reimplement circle overlap tests myself; that will be cumbersome and slow for the game I’m trying to write)


For circles it’s just distance formula. Just some math stuff but it gets more complicated once you want collisions past basic shapes.

well if you want circle overlaps then I’d use distance formula as detailed in part of that post. That’s fast & consistent in the player but more tedious when coding

Have we really just tested the same shapes :joy:


ok. But I’m sad that I have to code around HS bugs; mainly because even though conceptually it is clear to us how to do it, it necessarily makes the code bigger and uglier (if not slower), which risks undermining HS being good for intro-to-coding. “Touching” is transparent (my 7-year-old gets that), math formulae are not.


Totally agree – I did mention on this thread already how that essentially already proves your point if that was needed.

Best to give the team a little bit of leeway though; there’s a lot of focus on growth and engagement right now (lots being behind the scenes) – there’s some advertising going around on FB as you know. It’s hard with a small team, and sooner or later I’m sure collisions will be addressed (again).

For me personally, this collision bug isn’t too bad, especially compared to the previous issue, which was significant performance drops even when there were less than 100 objects on stage while one of them had a bumps rule. Doesn’t make it less of an issue, but having used different platforms before as well (notably Tynker for a group project since HS wasn’t accessible on a chromebook), Hopscotch’s is still pretty good for me.


That being said, I do still understand the desire for (and want) Hopscotch’s collision system to be free of these quirks as it really shouldn’t be necessary to jump past these hurdles when learning the language.


ah - I didn’t understand what you meant till now; sorry and thanks for explaining it again.

I really hope it helps secure the long-term health of HS. I do love HS and hope that my projects (and bug reports) reflect that.


Something I noticed is that when I used my modifed webplayer from this post:

which sets CollisionManagerDebug.ENABLED to true,
it works as expected for a bit, then the big circle changes slightly and it seems like it only checks if the orange squares overlap. This seems to be the exact opposite of what happens in the post I linked.


Do you have any ideas on why using the Set width,height block elicits the bug, but manually (in the object editor viewer) setting the circle size does not do so? Or, do you know of any work-arounds?

1 Like

It may have something to do with the way that collision code is setup
It may be that the code is set using the image instead of a custom circular collider and it probably has something to do with the fact that a circle has has no edges or you could say a infinite number of edges and so hopscotch seems to simplify the collision which end up making it buggy, i haven’t tested this theory yet but I’m guessing if I used a image of a circle with a transparent background then A-the performance would drop and B-the collisions would appear correctly.
It also might be because hopscotch may not have pixel perfect collisions…

1 Like

Although a easy fix for this, which most kids probably wont understand is to use
When ( ( ( Self x - Objects x ) to the second power) + ( ( Self Y - Objects Y ) to the second power ) Square root ) is less then radius of circle + radius of other circle) this collision code works much faster also
And if you use spy guys method of next x and next y you can have almost perfect collisions.
See previous post first


ok; you’re describing the same thing as what Awesome_E posted above (“conditional collisions”), which is a way of coding around the bug. HS’s own touch detection seems to work correctly for nearly all other shapes, including ones curves (try remixing my project from first post to see), for which re-implementing touch detection in code would be impractical.

Code legibility, and using built-in functionality as much as possible (vs reimplementing in own code) are things I’ve learned are important for software development. I work on these bug reports with the hope that HS can have fewer bugs, and be a better way to learn software development.


Following some discussion with @/rod, a work-around is:
precede the “set width/height block” with a “set image” block; that seems to work for me.

1 Like