If hitbox is in family and is contained with sprite, then the contained sprite will be picked whenever the hitbox is picked. Or so it works in theory.
According to my own experiments, not quite...
If you have two (or more) objects in a container, then you have to refer to one of the objects in that container directly in order to pick the others. Since you can't put a Family into the container, you might get weird results.
So you can do a lot of general stuff to your hitboxes by Family, such as setting the speed, angle, test collisions, or whatever... but if you want the Container picking ability you will need to define your condition by using an actual object that is in the container, and not by a Family that any of those objects might belong to.
Hope that makes sense. And of course, now that the subject has been broached I'm sure some dev will pop in and say "Fixed for next build"
This invisible hitbox and visible sprite method just seems like a hack.
I suppose I'm just used to it. I came to Construct through MMF, where it's common practice to do it that way.
At any rate, I read somewhere on the forum recently where one of the developers said they were planning a custom hitbox feature. So who knows, it might be here soon.
And honestly I don't think it's that hacky of a practice. While Game Maker allows you to manipulate the hitbox directly for the sprite, it's really just a matter of convenience (I'm not aware of any other game making software that has that feature). Defining the hitbox with a separate sprite in Construct is the same sort of practice... and has the same reasoning behind it. It's just that it's not as convenient because it happens to be a separate object. In traditional programming it's even more abstracted... you have to define your collision box based on math rather than a visual representation of a box. But essentially you're still making a box, even if that box is made of a few individual coordinate checks.