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.
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:
| Layer | What it is | What that means for you |
|---|---|---|
| Game DLLs | Valve'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 Deadworks | C++ 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 plugin | One DLL in managed/plugins/ |
Exactly one gamemode is loaded at a time. Two would fight over the same hooks and the same HTTP port. |
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
- A saved config overrides every default in your code. Once a plugin has run,
configs/<Plugin>/<Plugin>.jsoncexists, and a key in that file beats the C# default at every load, forever. Three fixes were "reverted" by this before anyone noticed. CompareGET /api/configagainst the file before believing either. - 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.
- 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.
- 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.
- Setting a live player's team through
TeamNumdoes 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:
| Path | What is in it |
|---|---|
04_scripting/deadworks_official_docs.md | The transcribed official docs from docs.deadworks.net. Authoritative; read it before building anything UI or plugin shaped. |
04_scripting/deadworks_patterns.md | Every API pattern we have confirmed, with the Discord message that confirmed it. |
04_scripting/modifiers_list.md | The 125 modifier names and what each group is for. |
04_scripting/runtime_entity_manipulation.md | ent_create, ent_fire, output routing, and the community footguns. |
06_server/cvars_dump_raw.txt | 3,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. |