But enough Kerbal Space Program.
I spent most of the day putting trigger volume support into the game engine. Integrating it into Bullet was a little troublesome. Bullet has callbacks for contact added/destroyed... but they don't actually seem to do what you would expect from the names. Actually, the Add only works if you set special flags, and I have no idea what's up with the Destroy - it doesn't even take the objects in question as arguments, and only gets called... well, never as far as I can tell.
No worries, the Hacker Within shall prevail. Without modifying 3rd party code if at all possible.
It looks like the collision callback happens every frame if two objects are touching, so I just set up the TriggerVolumeComponent to track if anything was touching it last physics tick, and if anything is touching it this tick. In the post-physics update, if the flags don't match, the appropriate notification function is called.
This kind of limits the options for passing around which objects were actually causing the trigger, but ultimately I don't think that's too important. Mostly I want to know the on/off state of the trigger. The collision filtering takes care of most of that (only objects of the correct type affects a trigger) and each object can handle the regular collision callback if it cares that it's touching a trigger.
This opens the door to some other fairly useful components for building a level.
An EnableOnTriggerComponent can mediate between a trigger volume and any other game object to enable or disable it. If, for instance, a SpawnComponent is created disabled, it can be activated when the player enters a specific area.
For puzzle-type things, it could also be used to detect when the player has placed an object in the right location.
Basically, it enables the actual Game bit to work in the game. :)