I decided to try out ragdolls again after some time trying to get them work before and... I know this time it's not me. I ensured the model had a collision box for each bone, the bones have constraints and $jointconstraint is checked, the collision mesh seems fine and is marked in yellow, etc.

When I put it into hammer and turn on the collision mesh visibility, the collision mesh appeared to have either collapsed to the root bone or all the others except the one on the root bone vanished. This holds true when I test the model in-game with the model passing partway into the floor. 

I also tested your ragdoll example and a similar scenario occurs. I have tested this using the latest version of Wall Worm to date on two computers using Source SDK 2007 and 2013 respectively.

[wallworm]

I'll look into it. I've never had a problem with it... but haven't exported ragdolls specifically in a bit. It's possible I've broken something.

[wallworm]

So I downloaded those scenes and indeed there were some problems. Some of them had to do with the fact that I've updated the way WW exports some things.

While looking into it, I decided to make a change to the process of making ragdolls... so there is an updated version of WWMT. You no longer need to use Bone On for unskinned models to make a ragdoll.

I've also updated the Ragdoll docs to reflect these changes. The page includes an updated Ragdoll example scene that works with the latest versions of WW. (The older scenes had some problems because some updates to WW changed the way some things exported; for example, one of the older sample scenes had a model that used Skin and it had the Rotate Origin option checked... which is no longer something you should ever do--when using Skin, turn off Rotate Origin!).

Note that if you download and use those scenes, make sure to use the WWMT SMD Exporter in your global settings... as I no longer test anything using the Wunderboy and Cannonfodder exporters.

Let me know how this works for you.

It looks like it's an issue with the SDKs themselves as some other ragdoll props are not working correctly such as the mattress from hl2... maybe that's why it's not working. I tried everything that I know of to get this to work and got nothing.

I guess I'm stuck with physics entities for now.

[wallworm]

So did you try the updated scene file with the updated version of WW? The original scene did not work correctly. SO I updated it... and I also changed the ragdoll procedure slightly in the last version of WW. I am not seeing such a problem with the ragdoll.

Please also make sure that you have the Wall Worm SMD Exporter selected in the global settings as the SMD Exporter; if not, re-export after changing the setting.

I never needed to change the SMD exporter to anything else so I know that isn't a problem.

Here's a set of images of what is happening.


In both HLMV and the model browser inside hammer show the collision model just fine...


...but that's not the case once you drop it into the map and run it.

I tried checking if the bones or mesh was causing it but I still get the same result regardless. I have no clue what's causing this issue.

It also just started to do this to rigid physics objects as well though if you set it to be $staticprop with physics properties, it'll still use it as a prop_physics and the collision mesh is actually fine. Not that simple for ragdolls though.

Oh, and your example is still broken on my end. Out of curiosity, what game did you test your ragdolls on? It is clearly not working for 2007 and 2013 SDKs for me... or it could be studiomdl. I have no idea.

[wallworm]

I've tested the ragdoll in CS:Source and CS:Global Offensive. Are you certain that you downloaded the new scene and recompiled all of the models in it before re-exporting the level?

In the newer example file here, you will notice that I've added some XForm modifiers to one of the models (the one using bones). Notice that the xform gizmo is aligned to the root bone position... perhaps that can help?

Also, perhaps the problem is that your model has the Rotate Origin command. I suggest never using that if there is a skin modifier being used.

PS. The main thing that example file shows is how you handle a ragdoll that uses a skinned collision model (the one with circle targets) vs one that doesn't use a skinned model (the model with a rectangular target).

Rotate Origin off... nope. Xform modifier.... no. Both model and CMs pivot at origin and aligned to world... nope. Tried combining the CMs thinking it just keeps the root CM... it still gets rid of the other ones so this may be bone related... so why does it look fine in HLMV?

That's the thing, the model looks fine in HLMV and it's equivalent in Hammer but once it's in the level, it ditches all but the root CM and turns it 90 degrees. It does the same thing with animated models intended to be prop_dynamic. The model is animating beautifully right in front of my eyes in HLMV and in Hammer but the CM just keeps being destroyed.

However, Hammer did leave it alone 3 days ago before if there is only one single CM hull in the model and only skinned to one bone... which it doesn't do anymore.

Maybe I'm looking in the wrong place if this is a Hammer issue.

[wallworm]

I'm at a loss as I haven't had any problems. And for me, the updated ragdoll scene exports all of the models correctly then exports a level that runs just fine.

Have you installed all the latest service packs for your version of Max?

Sorry about not responding for awhile, got rather tied up with something.

Anyway, I'm using 3ds Max 2013 with the latest product update which is 6 I think. They don't seem to have barely any service packs at least by name so yeah. This is the version that the bug is being tested on... but I don't think it's actually Max's fault. It's Hammer.

While this may not be a good lead, I notice that when I turn on collision model visibility in Hammer, it tints it a different color depending on what prop it is. For static, it's red and for physics it's purple. As you seen from the screenshots, it's a physics prop with the collision tinted red.

What I think Hammer is doing is trying to treat it as a static prop when it isn't and tosses out all except the collision hull skinned to the root bone. This also occurs with a dynamic prop that has animation on it but the animation is perfectly fine. It is the collision hulls it is apparently tossing out. 

I probably have to blow Hammer away and reinstall it to see if that solves the issue. If that don't work, I'll put the models in using another game such as Counter Strike and then open the map up in the game I'm mapping for.

Again, the model and collision appears perfectly fine in both the stand-alone model viewer and Hammer's model browser. When it is put into the level is where the problem appears to start. There may not be anything you can do in this regard so... yeah. I'll let you know if that fixes it.

[wallworm]

How the collision appears in Hammer is inconsequential as long as it runs fine in game. Have you just ran the model in game to see if it collides as expected?

If it were only that easy... no, it behaves exactly as it appears in Hammer. I believe I showed a screenshot of this already... though maybe I should upload a video instead since it is physics we're talking about.

I'll probably add that to this post but for the moment, I'll say this is in need of a fresh install of Hammer. I'll post again once I tried it there.

Edit:

...okay, this is embarrassing. I just found out that there is a particular entity known as prop_ragdoll that does exactly what I was looking for. I was under the assumption that prop_physics handled ragdolls but it turns out it only handles RIGID AKA NON-JOINTED objects.

So... yeah. The whole collision collapsing thing was because I was trying to force a ragdoll onto an entity that didn't support it and forcefully ditched the joints and collisions to make it compatible. I can't believe it took me this long to find that out.

...I guess I was being more stubborn then stupid in this case and I apologize if I wasted your time on this... twice if you remember. So, I suppose the bug here is human error XD.