Hi dorkbot, first of all, this is kind of a duplicate entry to that topic, I can't merge them but in the future avoid that please.
Secondly, I understand the complaint even though I do not agree with it.
You should think of Hero and Enemy as example implementations of Box2DPhysicsObject/NapePhysicsObject.
even though this request makes complete sense, I will not agree to add to them a full spectrum of everything everyone needs as for obvious performance reasons this would be awful, and also since this IS here mostly for educational purposes in my opinion (opinion that may not be shared by Aymeric) it should not be considered as a base object (even though for small to medium projects of course, they can do the job perfectly, I use them myself).
See it like that : its very likely that as your games grows, you will need so many features that in the end it would be less efficient to use Hero as a base object than to use the related REAL base physics object we provide.
By not adding all possible features everywhere inside the platformer kit's object, I actually encourage everyone to extend the real base object for their own needs, and this also lets you learn a bit more about how CitrusEngine works and in the end will let you debug more easily and work even more rapidly because you'll know a bit more about what happens with the base objects that are the super classes of those example classes. (again, this does not reflect the main author's opinion - aymeric)
SO I admit, that this signal may by default send the b2contact, or nape's interaction callback so you would be able to 'query' what the collider is and so on.
But even then, its more logical to put your collision logic and everything inside your custom Hero itself, for clarity purposes, you will end up with a massive state class if you end up putting all your game logic there, where you could save on signal dispatches (so on performance) and gain clarity by putting only state related logic (global logic) in your state - of course in case you can't move such code, keep it there, its your code, I can't force you to move things around and change your workflow , these are only suggestions.
I hope you guys understand,
If the majority decides those signals should send b2contact/interaction callback, I'll gladly do so myself, I'm not using these signals so It will not brake my code anyway, I leave the decision to the community and in the end, to the boss/master Aymeric (hello Aymeric )