Death Ragdolls - Proper server-side ragdolls for players AND npcs!

[release]Death Ragdolls


Adds server-side death ragdolls for players and NPCs.

[li]Networked Ragdoll Entities[/li][li]“mp_keepragdoll” Control over Server-Side Player Ragdolls[/li][li]NPC Server-Side Death Ragdolls[/li][li]“ai_keepragdoll” Multiplayer Usage for Server-Side NPC Ragdolls[/li][li]Clean Non-Conflicting Code[/li][li]CRC32 File Name, File Collision Prevention[/li][/ul]

So it’s been done before, yes, and poorly too, I might add. This flavor of its predecessor “Death Fix”, properly addresses problems with the player’s networked ragdoll entity, and addons which deal with the death ragdoll entity will, as a result, be compatible with this addon. Control the usage using the new “mp_keepragdolls” command to reenable client-side ragdolls if desired; enabled will generate server-side ragdolls.

A bonus? Indeed. What else would you expect from me?

Just like in single player, when a player kills an NPC, now the victim can be physically interacted with, rather than no longer having any interaction with it due to a client side ragdoll generation. When “ai_keepragdolls” is enabled, now in multi-player you can undo your dead NPCs. Don’t worry about ragdoll overflow, as the ragdolls are capped to “sbox_maxnpcs”, and the last ragdoll will be removed on generation of the next.

The addon features clean, non-conflicting code, usage of the duplicator library, and on top, to avoid file collisions, all of the scripts hold the name of their CRC32 value. Nifty.


There is kind of a reason ragdolls are clientside.
They lag most servers to shit.

I guess most servers are ran on cardboard boxes then. I run servers for about eight people on decent systems, nothing that’s Crysis-capable or awestricken. If you’re allowing NPCs in the first place, rag dolls are a slightly heighten issue. Other than that, even 16 individual ragdolls for players (which wouldn’t all be active at once, most likely) isn’t a big problem.

Nice. I might give this a try soon. Also if someone’s worried about lag the ragdolls would cause try the “NPCBattleCleanup” addon which, when enabled and settings set to your liking, removes ragdolls and weapons they drop (except custom named obviosly).

I’m going to reupload the just-revised code right now, as it didn’t seem to properly limit the NPC ragdolls to “sbox_maxnpcs”, the issue is fixed now, however.



I love you. Deathfix/FeignDeath/RagMod are all good but hopefully this’ll prove to the best for serverside ragdolls. They’re great for pissing about. You can’t beat building a giant water slide with the stacker tool, setting the physical property to ‘Super Ice’ and flinging yourself down it as a ragdoll. Any complaints about the ragdolls being laggy are pretty much unfounded. I’ve never had any problems with the previous mods when playing with friends so I can’t envisage any such issue with this one.

Gonna test this later.

Let’s face it, if you own a server, it’s your fault if it’s not good enough to handle a little bit of networking.

I found this error when messing around with the JetPack addon by CapsAdmin.

autorun/client/b6280df3.lua:14: attempt to index upvalue 'mp_keepragdolls' (a nil value)

I get that when using the jetpack (spacebar to fly) and it spams the console until I stop using it.

I’m aware that the jetpack won’t be attached to the ragdolls body, but how would I go about fixing this?

EDIT: Also, the jetpack isn’t even showing up on the players back.

If I may ask, why would you do this?

Correct me if I’m wrong but I think “file collision” is prevented if you make it an addon. It wouldn’t matter what you name the file, it won’t override any other file cause of the way gmod mounts the addons.

But I might be wrong.

If I am, you shouldn’t be calling your files “c301280ckoRICJAS.lua” anyway. Just put dr_ or something in front of the filenames. You could come up with something better than this.


bad code or something on andrew’s side I guess

Thanks for the conformation Caps, I removed this addon (and put ragmod back on) and the jetpack works fine.

It is prevented. If you couldn’t do that, we couldn’t have things like init.lua everywhere.

Ah, I just tested this and it doesn’t work.

But he could at least be creative with the names.

The init.luas are always in their own folder. You can not have lua files with the same name in the same location, even if some are packaged as addons.

Exactly, it doesn’t work. The reason why I didn’t do that do though, Caps, and I know it seems boring, but I did it specifically because my addons usually feature some files repeatedly, one or two addons may have the same file which contains generic function stuff I’ve written (such as my HL2 HUD work), or library work.

By having the same exact CRC32-based file name, you can have three of my addons with the same file, and it only gets sent once! :smile: Nifty don’tcha think?

For the record, my previous addons will show traces of a system like this:

client/<prefix>cl_filename = client-side
server/<prefix>sv_filename = server-side
<prefix>_filename = shared

Example (when I was working on GMEX, or GMod Extensions):


And this system is adapted from the module architecture, you may have noticed.

The problem here is the same as stated above, I reuse custom library additions, and functions for certain features. It saves the end-user download time, and other developers’ work wouldn’t conflict as easily. (Theoretically.)