Okay ...
I would likely do it with two new components (probably tied to a single manager and in a single dll), InventoryComponent and ItemComponent. Whatever has an item component would have a physics component as well as the item will listen to collision events. When the item receives an event it would do checkEvent to the other entity for some new event type (e.g. PickupItemEvent), the checkEvent handler of the other entity in the InventoryComponent would see if it's allowed to pick the item up. If the item finds out that it's accepted than it will executeEvent on the other entity. Assumably the inventory component would receive a pointer to the item or increment an ammo counter or something, after which the item would disable its physics and graphic components (it'll only need to worry about them when responding to a DropItem event.
Dropping the item is more complicated.
Recap step-by-step:
- 2 new components (both of which should be made to be useable for all sorts of item 'types', so you can have an inventory for a character, a crate, etc)
- new events and event data classes
- Process
- checkEvent on the entity who may have an InventoryComponent on collision
- if ok then executeEvent on the entity who has the InventoryComponent, and disable graphics and physics for the pickup item
Obviously this is kind of cumbersome for simple cases (e.g. ammo counts), but its flexible, though I implemented a PropertyMap (binds existing variables) and DynamicDataSet (on the fly data) for the simple cases where you just need to do a "Does the entity have? Ok, set it to ____." At some point in the not so distant future I'll end up pushing out all my changes, too busy on tool dev to do the necessary initial-debugging.
NOTE: Just use the BulletPhysics component, the collision component doesn't really do too much.