heron icon indicating copy to clipboard operation
heron copied to clipboard

Event CollisionEvent::Stopped is not emitted in some cases

Open Shatur opened this issue 3 years ago • 6 comments

Event CollisionEvent::Stopped is not emitted when:

  • You are deleting the colliding entity.
  • You are changing/adding CollisionLayers which should disable collision between colliding objects.

Shatur avatar Mar 09 '22 11:03 Shatur

I also opened an issue in rapier: https://github.com/dimforge/rapier/issues/299

I mark this issue as "upstream" for now until we know if rapier agrees to address it. If rapier rejects the proposal, we'll try to figure out a way to solve it in heron.

jcornaz avatar Mar 09 '22 11:03 jcornaz

You are changing/adding CollisionLayers which should disable collision between colliding objects.

I think this one is also could be resolved in Rapier. Is it worth mentioning this issue as well?

Shatur avatar Mar 09 '22 12:03 Shatur

I think this one is also could be resolved in Rapier. Is it worth mentioning this issue as well?

that is kind of a different issue to me. But if the problem is indeed in rapier then we could open another issue there.

jcornaz avatar Mar 09 '22 12:03 jcornaz

that is kind of a different issue to me.

Sure, the cause is different. I just assumed that grouping this two issues together may result in a better designed solution for events.

Shatur avatar Mar 09 '22 12:03 Shatur

Sure, the cause is different. I just assumed that grouping this two issues together may result in a better designed solution for events.

I understand, and surely it is important to consider both problems to help design a good solution.

But that may still be two different issues. Eventually mentioning the other issue in each of them can be enough to make sure the two problems are considered when designing solutions. If there are enough related problems, the maintainer may group them via an epic/umbrella issue, a milestone or a dedicated tag.

Having multiple different problems (even related) in the same issue on the other hand may lead to an awkward situation when we have a fix ready for only part of the issue, but cannot close it. Or worse we close it by mistake and forget there is another part still waiting for a fix. It may also make prioritization more difficult because it's either all or nothing. One of the problems may be more problematic/urgent than the another. We may even decide to fix one problem but not the other. Finally, it also increase the perceived cost of solving the issue, and reduce the likelihood that someone start working on it.

I usually find that splitting too much in different issues is less problematic than aggregating too much into a single issue (the same applies to PRs by the way)

jcornaz avatar Mar 09 '22 13:03 jcornaz

Agree, opened a separate issue in Rapier: https://github.com/dimforge/rapier/issues/300 I will split this issue later based on upstream response.

Shatur avatar Mar 09 '22 18:03 Shatur