Deadworks Field Manual

Concrete answers for building Deadlock gamemodes with Deadworks. Names that exist, calls that compile, defaults that are real, and the specific ways each thing fails quietly. Written from the two gamemodes running on this server and from the game's own files.

The rule this whole manual follows

Nothing here is from memory. Every modifier name was read out of the game's own localisation or a string scan of the install. Every cvar default came from a dump taken off a live server. Every API signature came from the official Deadworks docs or from code that is currently compiled and running. Where something is not proven, it says so in those words, because a confident guess in a document like this costs a whole evening later.

How the stack fits together

deadworks.exe loads the same game DLLs as deadlock.exe -dedicated, then installs function hooks by scanning for byte signatures. There are four layers, and knowing which one you are on tells you immediately whether a thing is possible:

LayerWhat it isWhat that means for you
Game DLLsValve's server.dll, client.dll You do not touch these. When Valve rebuilds them your server has to move too, or every player's client crashes on specific abilities.
Native DeadworksC++ hooks found by signature Signatures survive small patches; an edit to a hooked function breaks one and you get "signature not found" until a new Deadworks release lands.
DeadworksManaged.Api.NET 10 managed surface This is the API you call. Everything in this manual lives here.
Your pluginOne DLL in managed/plugins/ Exactly one gamemode is loaded at a time. Two would fight over the same hooks and the same HTTP port.
The server / client line, and it is absolute

A plugin runs on the server. The HUD, Panorama, the camera, rendering, particle rendering and user input are client-side and unreachable. There are exactly three ways across that line:

  • Net messages, for the handful the game already defines (a game announcement, camera angles, a chat message).
  • The launcher's UI channel, which is how every custom panel in Custom UI works.
  • Content addons, files the client downloads before it connects.

If something you want needs the client to compute or draw something no entity can express, the honest answer is that it needs a content addon, not a cleverer server call.

The five things that cost us the most time

  1. A saved config overrides every default in your code. Once a plugin has run, configs/<Plugin>/<Plugin>.jsonc exists, and a key in that file beats the C# default at every load, forever. Three fixes were "reverted" by this before anyone noticed. Compare GET /api/config against the file before believing either.
  2. Resources must be precached at map load or they silently do nothing. Spawning an un-precached particle does not error. It just never appears. Worse, a missing precache on some resources is a hard hang of the game thread, not a missing effect. See Precaching.
  3. Entities are bandwidth. Creating roughly 45 entities in a single tick jammed one player's connection outright while the server itself stayed perfectly healthy. Beams are entities. Rings are many beams. Stagger anything you build in bulk.
  4. A world text's string cannot be changed in place. There is no setter. Changing a label means destroying the entity and spawning a new one, so a label that counts down once a second is an entity churning once a second.
  5. Setting a live player's team through TeamNum does not network. The server-side number changes, every server-side check behaves, and the clients are never told, so bullets pass straight through enemies. See Move a live player's team.

The manual

Where the underlying notes live

This site is the readable version. The raw material behind it:

PathWhat is in it
04_scripting/deadworks_official_docs.mdThe transcribed official docs from docs.deadworks.net. Authoritative; read it before building anything UI or plugin shaped.
04_scripting/deadworks_patterns.mdEvery API pattern we have confirmed, with the Discord message that confirmed it.
04_scripting/modifiers_list.mdThe 125 modifier names and what each group is for.
04_scripting/runtime_entity_manipulation.mdent_create, ent_fire, output routing, and the community footguns.
06_server/cvars_dump_raw.txt3,030 cvars with types and real defaults, dumped off a live server.
16_project_design/BATTLEBOX/BattleBox: round-based, two arenas, engine teams 2 and 3. The cleaner of the two plugins to read.
16_project_design/BEDWARS/Bedwars: one team per player, teams 5 to 16, and every workaround that architecture forced.
09_research_log/github_clones/GameTracking-Deadlock/The game's own extracted files. The last word on any name.