How do I get overlapping to detect correctly

Not sure if this is a bug, or me doing something stupid.

Probably the latter.

I have an overlay object, and I want to detect whether it's overlapping any member of a family.

The members of the family are always moving layers in the project, however the overlay is always on a single layer above all the rest.

But its weird, If I have three members of the family, each spaced out around the layout. It will sometimes detect the overlap, and sometimes not. On one object it NEVER does. On one it ALWAYS does, and on the other it depends whether my Y value is greater or lower than the Objects Y...

Heres the very simple code I'm using:

And here you can see the result (Click for full size):

The green circle is clearly over the goblin.

Things I have checked:

Collisions enabled / disabled

In family /not in family

same layer / different layer

visible/invisible

100% Opacity / 50% Opacity

My entire combat system is hanging on this overlapping, I narrowed all my bugs down to this one thing. And even supersimplified as you saw above with just a single Event-Action ... Still. Not. Working.

The last 2 days of my life have been trying to work this out.. please someone help me before I go crazy.

There were 2 posts here recently with similar problems, in both cases the issue was caused by wrong instances been picked up for overlapping/collision checks.

How many playerMeleeRange instances do you have? Have you tried removing all instances of Enemies except the one that never detects overlapping?

Have you tried testing each enemy (one by one in a loop) for overlapping with the playerMeleeRange?

Also, I have never used "Log in console" myself, are you sure it works reliably?

If nothing helps, could you share your CAPX? You can remove everything unrelated to the problem from it.

I might be able to share the CAPX privately with you, I can't remove enough stuff to make it shareable here.

I know the two threads you mentioned, I read both.

There is only one playerMeleeRange in the world. And as said I tried removing the goblin (the one that always has issues) from the family and just checking overlap against that (again only one instance). Nada.

Ok dop2000 , small update. It's to do with the "Collision" Property of the Goblin (or anything in the family)

The overlapping only detects when collision is TRUE.

Never if it's FALSE.

Made a very small CAPX to demonstrate this. https://drive.google.com/open?id=0B5cW0 ... G5iNDdwbXM

In my opinion this is a bug, Overlapping should be a simple pixel calculation nothing to do with collisions.. thats what the "On collision" event is for.

Ashley can you confirm if this is the expected behavior? If it is, what is the suggestion to do what I want, detect overlap regardless of "Collsion" Property?

This is likely a feature, not a bug

It has been discussed before:

Overlapping check uses collision polygons and when you disable collisions for a sprite, I think the collision polygon is just ignored. And that's why the check doesn't work.

*insert expletive here*

Guess I need to find a workaround, or a plugin that does the same thing minus the need for collision enabled. I can feel my game grinding to a halt already...

Overlap is a collision check, so if you turn off collision checks, all collision checks are ignored and return false. That is by design.

Construct has a really well optimised collision engine, generally it's not necessary to disable collisions to improve performance.

Ashley appreciate the response! (p.s happy birthday)

I'm disabling collisions due to the isometric display, have to be able to walk behind things. The performance is not an issue, trust me I love the perfomance of this engine. I have a terrible 2GHZ Cpu and 4GB Ram laptop.. even with 1000 entities being sorted every tick I get 45 FPS.

Unfortunately I need a way to detect overlapping of objects while the collision is off on one of them. Is there anyway to do this natively? Or will I need to write my own plugin to handle it?

I'm sure you can find a workaround. If your playerMeleeRange and Enemies objects are close to a circle shape, then instead of the overlapping check you can do something like this:

Enemies pick nearest to playerMeleeRange.x, playerMeleeRange.y
  distance(playerMeleeRange.x, playerMeleeRange.y, Enemies.x, Enemies.y)<=(playerMeleeRange.width/2 + Enemies.width/2)
[/code:xqrpl94t]

Or you can pin an invisible sprite with collision:enabled to your Enemies and check overlapping with that sprite.

I'm sure you can find a workaround. If your playerMeleeRange and Enemies objects are close to a circle shape, then instead of the overlapping check you can do something like this:

> Enemies pick nearest to playerMeleeRange.x, playerMeleeRange.y
  distance(playerMeleeRange.x, playerMeleeRange.y, Enemies.x, Enemies.y)<=(playerMeleeRange.width/2 + Enemies.width/2)
[/code:3d1sy4x5]

Or you can pin an invisible sprite with collision:enabled to your Enemies and check overlapping with that sprite.

I think I'll have to go with the first solution.. use some maths. Your example would work for testing one.. But I'll need to come up with a solution that checks multiple. Thinking a For Each and Is On Screen might do the trick. Will update this thread when I find a solution.

You should be able to pick all Enemies by evaluating distance (that formula above=true).

System-> Pick by evaluate or Pick by comparison

It should pick all Enemies in melee range. And then you can do For Each for the picked enemies.

dop2000 I'll have to experiment with using the pick all by evaluate, and compare it to how I've now got it. See which performance is better.

I've got a demo CAPX (LINK) working with the following code, will now port to my actual game and test performance.

Thanks for all your help.

Why not just implement the collision flag yourself in a boolean instance variable? Ignore the condition if the boolean is false, and you have a per-instance, per-event way to handle collisions.

Because Ashley, that would be super smart and a simple way to fix my problem.

And I'm not super smart, and always go for the complex methods!

But that is a good idea, I'll look into maybe using that in the future. Particularly if I run into performance issues with this.

Yeah, C2 offers so many different ways to solve each problem that the most efficient and simple one often gets overlooked.