You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
onComponentTypeCheck was only supported for components but not for hitboxes, because ShapeHitbox implements GenericCollisionCallbacks instead CollisionCallbacks.
Specifying onComponentTypeCheck for individual hitboxes might be useful in cases where Component have hitboxes for collisions and also some utility hitboxes (for example, to check available directions for pathfinding). Colliding between this two types of hitboxes should not lead to movement restrictions and so on. But without onComponentTypeCheck in ShapeHitbox we can not to perform such check.
Checklist
The title of my PR starts with a [Conventional Commit] prefix (fix:, feat:, docs: etc).
I have followed the [Contributor Guide] when preparing my PR.
I have updated/added tests for ALL new/updated/fixed functionality.
I have updated/added relevant documentation in docs and added dartdoc comments with ///.
I have updated/added relevant examples in examples or docs.
@spydon I also implemented onComponentTypeCheck for Sweep algorithm. But after performing a benchmark I decided that it absolutely not worth in performance, it only makes code more complicated. Maybe we should to document this somewhere? To avoid new "issues" after years, when everithing will be forgotten 😉
@spydon I also implemented onComponentTypeCheck for Sweep algorithm. But after performing a benchmark I decided that it absolutely not worth in performance, it only makes code more complicated. Maybe we should to document this somewhere? To avoid new "issues" after years, when everithing will be forgotten wink
It is probably worth having it just for consistency, because it will also avoid callbacks being called for collisions that the user doesn't care about, even though the performance gain isn't that high?
Ok, I pushed what I have for now: #1996
Let's to discuss realization there. This code does not looks good for me but fixing it in right way will lead to breaking changes, I think
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
onComponentTypeCheckwas only supported for components but not for hitboxes, because ShapeHitbox implementsGenericCollisionCallbacksinsteadCollisionCallbacks.Specifying
onComponentTypeCheckfor individual hitboxes might be useful in cases whereComponenthave hitboxes for collisions and also some utility hitboxes (for example, to check available directions for pathfinding). Colliding between this two types of hitboxes should not lead to movement restrictions and so on. But withoutonComponentTypeCheckinShapeHitboxwe can not to perform such check.Checklist
fix:,feat:,docs:etc).docsand added dartdoc comments with///.examplesordocs.Breaking Change?