I must admit I haven’t anticipated such mechanics. As I wrote in the first post and in the pdf, this code is patchwork and was never meant to handle everything, and what you’re asking about will expose a number of it’s limitations. Including such that I’ve never thought about.
Still, it all depends on how sophisticated the behavior you need.
If all you need is a single shape that sticks to walls, then it’s very simple. All you need to do is use a callback to know when the geom hit something, and then clear the object, leaving just the visible geometry (you can obviously make it selective too). At the same time, once you cleared it so it doesn’t move, you can set up something new around the collision point to make use of the new stuck-to-something state, for instance: an area trigger to make a mine.
For something that can stick to generic kinematic objects (not the KCC), you would probably want to do the same, but keeping the update method, so you can update the position of the visible geometry and the stuff you set up around it. That way your dynamic object would change into a kinematic-ish object on the fly.
That should work for the simplest scenarios, i.e. a singular object. If you want the thing you throw/shoot to be more complex, for instance having something hanging on a joint (or a set of joints) off the back of it (i.e. something like a meteor hammer), then that will be more problematic or even impossible with the current code.
For sticking to static geometry it shouldn’t be a problem. You would just need to remove the joint connecting the chain with the grenade, replace it with a joint connecting the chain to the environment, and you’re good to go. That way, with some work, you could even make a cannon shooting Half Life’s Barnacles that attach themselves to the ceiling with physically accurate “tongues”.
Note, though, that in such case you would need to use the discreet, instead of continuous, collision detection dynamics variant. My CCD implementation is meant for simple singular objects – compound shapes and joints don’t work there ATM.
However, if you wanted to have a meteor hammer sticking to kinematic (animated) objects, then that’s not possible out of the box. My kinematic stuff was made with animation, collisions and moving-platforms in mind, but not joints; because that’s all I needed. That’s why you can’t attach joints to them (contact joints are a different thing).
In fact, I’ve tried to make that in the past and it should be possible using a body with zero mass, but for some reason this always results in instability, nans, crashes and other bad things happening. Maybe I was just doing something wrong, dunno. My game did not depend on that and I have limited time so I left it out.
I can see that the new version of ODE supports apparently full-featured kinematic bodies OOTB, but it seems like Panda depends on an older version, or just doesn’t expose that functionality. Interestingly, PyODE’s newest snapshot seems to support it, though. That makes me wonder about porting my stuff to it, but even if I do some day, it will sure not be anytime soon. By which I mean probably not this year.
Ok, back to the original point. I’m currently occupied with other stuff so I can’t really tinker with the framework much. However, you could experiment with the old way of making “jointable” kinematics and maybe you can find out how to use that zero mass approach. Unfortunately, that’s currently your only option if you want to have behavior as complex “as stuff with other stuff hanging off of it sticking to script-animated geoms”.
As far as the KCC goes everything written so far about kinematics applies, but there’s yet another layer of complexity. I.e. you would need to make the sticky objects attach themselves to the actual character, and not the capsule. That means the more accurate representation of the character, possibly the one you could also use for hit boxes. Obviously, the capsule stays there for environment collisions, but sticking the grenades to the capsule would look wrong.