Stack composer

Started from [GER] Der Neuanfang: the 21 mods it publishes to the Steam server browser (as of 2026-10-22), put back into load order — servers publish the list last-loaded first. Mods loaded with -servermod= are never published, so they are not here; add them if you know them.

Add a mod

Start from a live server

Your stack in load order, earliest first. Drag a row, or use the arrows, to reorder.

1 CF
2 BasicSpawnSelect
3 SQUAD MSF-C
4 BuilderItems
5 Server_Information_Panel
6 Radio not analyzed
7 BulletStacksPlusPlus
8 Mass'sManyItemOverhaul
9 COCAs_NoVehicleDamageMOD
10 UsefulSuppressors not analyzed
11 RaG_Core
12 BuildEverywhere not analyzed
13 RaG_BaseItems
14 WornRepair
15 Disable Stamina not analyzed
16 VanillaPlusPlusMap
17 All Vanilla Item Crafting Recipes not analyzed
18 Dabs Framework
19 VPPAdminTools
20 RUSForma_vehicles
21 HK416 not analyzed

6 of 21 mods not analyzed yet — left out of the composition below. Open a mod's page to request its analysis.

Stall risks

5 in hot hooks

File I/O on hot paths, timers created per event, and per-player-per-frame hooks across the stack. These can stall a frame regardless of the load figure. See all 5 below.

Mods silencing mods

1 conflict

Across 29 server-side methods hooked by two or more mods. 2 more on client-only UI classes, listed separately.

Structural load

0.36% of a frame at 100 players

3.640 ms per second, all 15 mods combined. Hook dispatch and timers only — not what the hooks do inside. Methodology.

Who silences whom#

A later-loaded mod overrides a method without super(), so the earlier mod's code on that method — and vanilla's — never runs. Whether that is a bug or the whole point of the mod is the author's call; this shows the structure, not intent.

The one pair#

BasicSpawnSelectsilencesCF1 method

MissionServer.OnClientNewEvent value · T3 Vanilla spawn setup and earlier mods' spawn logic are skipped. BasicSpawnSelect.pbo::scripts\5_Mission\mission\missionserver.c:4

2 conflicts on client-only classes (menus, HUD, notifications) — no server effect

NotificationSystem.GetNotificationData — Dabs Framework silences CF
MissionGameplay.OnKeyRelease — VPPAdminTools silences BasicSpawnSelect

Hot hooks shared across the stack#

The engine calls the last-loaded mod first; each super() hands on to the mod before it, ending at vanilla. Badges show what each mod's override calls inside — that body work, not the chain itself, is what costs frame time.

DayZGame.OnUpdate

every server frame

VPPAdminTools then CF then vanilla

MissionServer.OnUpdate

every server frame

Server_Information_Panel then CF then vanilla

DayZGame.OnRPC

per event

VPPAdminTools sometimes stops here then Dabs Framework then CF sometimes stops here then vanilla

Hammer.SetActions

per event

RUSForma_vehicles then RaG_BaseItems then RaG_Core then vanilla

PlayerBase.OnRPC

per event

VPPAdminTools then RaG_Core then vanilla

PlayerBase.SetActions

per event

VPPAdminTools then RaG_BaseItems then vanilla

Screwdriver.SetActions

per event

RUSForma_vehicles then RaG_Core then vanilla

TentBase.CanReceiveItemIntoCargo

per event

RaG_Core then Mass'sManyItemOverhaul sometimes stops here then vanilla

Stall risks#

5 places where one mod's code can hold up a frame by itself, whatever the load figure says. Each is a pattern found in the code, not a measurement: how much it costs depends on what the hook does inside. Most severe first, then in load order.

Per-player, per-frame hook. Runs for every player on every tick, so whatever it does inside is multiplied by the population.

Server_Information_Panel

DayZPlayerImplement.CommandHandler

about 30× per player per second