heron
heron copied to clipboard
Event CollisionEvent::Stopped is not emitted in some cases
Event CollisionEvent::Stopped is not emitted when:
- You are deleting the colliding entity.
- You are changing/adding
CollisionLayerswhich should disable collision between colliding objects.
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.
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?
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.
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.
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)
Agree, opened a separate issue in Rapier: https://github.com/dimforge/rapier/issues/300 I will split this issue later based on upstream response.