← modperf · analyzed mods

Dogtags

Description Chernarus can be a very cold and unforgiving land, let's make it a bit more bearable by being able to identify your threats. Survivors are tagged when entering the nation of Chernarus, only their name and the date they were tagged can be viewed, and blood type if you have been tested. Collect the tags of your enemies or of the fallen allies, bring them forth for trade or as trophy pieces. Features -… (more)

Description Chernarus can be a very cold and unforgiving land, let's make it a bit more bearable by being able to identify your threats. Survivors are tagged when entering the nation of Chernarus, only their name and the date they were tagged can be viewed, and blood type if you have been tested. Collect the tags of your enemies or of the fallen allies, bring them forth for trade or as trophy pieces. Features - Name, tagged date, and blood type (if known by test) are stored on the tag - Dogtags can only be taken off of dead players - Hero, bandit, and survivor variants (distinguished by color) - Dogtags can be view on dead or restrained players - Survivors are tagged upon character spawn, existing players will also be tagged upon login - Names on dogtags are updated when changing your name Configuration You can configure if and when dogtags can be removed from dead players, with the dogtagsPlaytimeRequired config value in serverDZ.cfg. This is the required time the dead player had to be alive in order for their dogtag to be able to be collected. You can also control if dogtags worn by AI can be removed once dead with dogtagsCanTakeFromAI. This is NOT necessary to added to your serverDZ.cfg file, only if you wanting to change the behavior of removing dogtags. PLEASE MAKE SURE YOU ONLY HAVE THE VARIABLE DEFINED ONCE, DO NOT COPY AND PASTE THE ENTIRE CODE BLOCK BELOW AND COMMENT ON WHY YOUR SERVER IS NOT STARTING. dogtagsPlaytimeRequired = -1; // dogtags can NOT be removed from dead players dogtagsPlaytimeRequired = 0; // dogtags can always be removed from dead players, even fresh spawns dogtagsPlaytimeRequired = 600; // dogtags can only be removed from dead players that have played more than 10 minutes dogtagsCanTakeFromAI = 1; // allow dogtags to be taken off of AI dogtagsCanTakeFromAI = 0; // disallow dogtags to be taken off of AI - default There's really only one way to configure how tags are spawned currently on the server, you can add this method to your server's init.c file to edit what type of dogtags you're going to be giving your players. There are three dogtag variants, their class names are as follows: Dogtag_Survivor, Dogtag_Hero, Dogtag_Bandit, Dogtag_Silver, Dogtag_Granite, Dogtag_Cobalt I'd only edit this if you know what you're doing, or if someone in the community has made a good example to be used freely. This method isn't necessary to add to your init.c as it's already in the base mod and works as functioned below. There are some starter examples in the "Server" folder of the mod, along with the types.xml. This method is NOT necessary to added to your init.c file, only if you want to change which dogtags spawn on the player when the character is created. override Dogtag_Base EquipDogtag(PlayerBase player) { if (!player.HasDogtag()) // check if the player has a tag already { // create a new tag is the player doesn't have one int slotId = InventorySlots.GetSlotIdFromString("Dogtag"); return Dogtag_Base.Cast(player.GetInventory().CreateAttachmentEx("Dogtag_Survivor", slotId)); } return null; } Update player's dogtag based on time played for their specific character, by adding this to your init.c override void UpdatePlayersStats() { super.UpdatePlayersStats(); array<Man> players = {}; GetGame().GetPlayers(players); for (int i = 0; i < players.Count(); i++) { PlayerBase player; if (!PlayerBase.CastTo(player, players.Get(i))) continue; // update player's dogtag base on time float playtime = player.StatGet("playtime"); if (playtime >= 21600 && playtime < 43200) { player.ReplaceDogtag("Dogtag_Granite"); } else if (playtime >= 43200) { player.ReplaceDogtag("Dogtag_Cobalt"); } } } Mod Integrations GraveCross - dogtags spawn on grave crosses, load Dogtags after this mod DayZ Expansion - dogtags spawn on grave crosses, load Dogtags after this mod TransferItemsToCrateWhenDying - dogtags spawn on boxes, load Dogtags after this mod Planned Features - More modding support and examples - Additional meta stats for tags (i.e. killed by and death date); configurable - Better PVE support Known Issues - Incompatibilities with other mods that modify Trader's has item check logic and item removal logic Special Thanks Levent - modeling and texturing Cashewsan - model importing and material configuration (original mod idea) DayZBlackout - getting me the best contact for modeling and texturing Jacob_Mango - helping solve the UI issue with tooltips InclementDad - continue Usage & Terms This item is NOT authorized (strictly forbidden) for any of these conditions: - posting on Steam, except under the Steam account officialwardog. - hosting on any download server other than Dogtags' current workshop download. - hosting on any launcher for distribution other than Dogtags' current workshop download. - to be packaged in any form other than Dogtags' current workshop download. - to create derivative works. PERMISSION IS NOT GRANTED FOR THIS MOD TO BE INCLUDED IN A "SERVER PACK" or "MOD PACK" or "REPACK". Use a Collection if you want to include this mod on your server for your users. Monetization while using this mod is approved. Copyright 2019-2024 Wardog All rights reserved

Workshop 2303554682 · mod updated 2024-06-10 · analyzed 2026-10-03 10:27 UTC · history · 14 script files

Stall risks
None found

No file I/O on hot paths, no timers created per event, no per-player-per-frame hooks.

Compatibility
2 to review

2 chain breaks on base classes or persisted data.

Structural footprint 1.1
A
2 to review
Heavier than 20% of 328 scripted mods analyzed.

less than 0.001% of each server frame at 100 players (0.000 ms/s). Counts hook dispatch and timers only, not what the hooks do inside. Methodology.

Where this mod sits

Structural load of the 328 scripted mods analyzed, lightest on the left. This mod's bar is lit; 36 others share it. Ranked list.

20
40
60
  • 24 mods
    0.0000022 to 0.0000046 ms/s · grade A
  • 7 mods
    0.0000046 to 0.00001 ms/s · grade A
  • 1 mod
    0.00001 to 0.000022 ms/s · grade A
  • 1 mod
    0.000022 to 0.000046 ms/s · grade A
  • This mod
  • 26 mods
    0.00022 to 0.00046 ms/s · grade A
  • 33 mods
    0.00046 to 0.001 ms/s · grade A
  • 22 mods
    0.001 to 0.0022 ms/s · grade A
  • 13 mods
    0.0022 to 0.0046 ms/s · grade A
  • 10 mods
    0.0046 to 0.01 ms/s · grade A
  • 5 mods
    0.01 to 0.022 ms/s · grade A
  • 18 mods
    0.022 to 0.046 ms/s · grade A
  • 17 mods
    0.046 to 0.1 ms/s · grade A
  • 41 mods
    0.1 to 0.22 ms/s · grade A
  • 26 mods
    0.22 to 0.46 ms/s · grade A
  • 28 mods
    0.46 to 1 ms/s · grade A
  • 8 mods
    1 to 2.2 ms/s · grade A to B
  • 10 mods
    2.2 to 4.6 ms/s · grade B
  • 1 mod
    4.6 to 10 ms/s · grade B to C
A316
B11
C1
D0
E0
ms/s, log scale: each labelled step is ten times the one before. Letter grade and mods holding it below the axis.
Where the load comes from

Event hooks carry 97% of this mod's structural load. 0.000 ms/s in all.

97%Event hooks · 97%
1 hook · 0.0002 ms/s
Lifecycle hooks · 2.0%
2 hooks · 0.000004 ms/s
Event hooksrun when something happens: an inventory move, a hit, an action 1 hook 0.0002 ms/s 97% DayZPlayerImplement.CanReleaseAttachment
Lifecycle hooksrun when an entity is created, loaded or deleted 2 hooks 0.000004 ms/s 2.0% DayZPlayerImplement.EEKilled, MissionServer.InvokeOnConnect

Counts how often each hook is dispatched and how many timers stay alive, not what the code inside does. Some rates are order-of-magnitude estimates; the methodology lists which.

Chain breaks, by consequence

2 overrides that skip super(), ranked by how much they can affect. On any server a break replaces vanilla's behaviour on that method and silences every earlier-loaded mod hooking it.

Review
Base class · every PlayerBase (2 vanilla subclasses)
PlayerBase.ClearInventory

Vanilla's work on this method, and any earlier-loaded mod's, never runs for any PlayerBase.

Scripts.pbo::4_World\Dogtags\Entities\ManBase\PlayerBase.c:4
Review
Base class · every PlayerBase (2 vanilla subclasses)
PlayerBase.RemoveAllItems

Vanilla's work on this method, and any earlier-loaded mod's, never runs for any PlayerBase.

Scripts.pbo::4_World\Dogtags\Entities\ManBase\PlayerBase.c:28

Where this mod runs often

Hooks on per-frame and high-rate surfaces, with what their bodies call. Body work, not the hook itself, is what costs frame time.

CanReleaseAttachment on DayZPlayerImplement
per event
no I/O, timers or RPC
What this report can tell you

Which vanilla methods the mod hooks, which of them drop the chain, how often each hook fires, and which risky calls sit inside hot hooks.

What it cannot

How long hook bodies take, network cost, or engine-side load. Measured across live fleets, most server lag comes from the engine and world state, not mod script chains — a light footprint does not clear a mod of lag, and a heavy one does not convict it. Methodology.

Everything else

All 11 overrides

Surface is the dispatch tier the rubric can price (— = unpriced); server is whether the override exists on a dedicated server; super() shows whether the vanilla chain is preserved on a server.

methodsurfaceserversuper()where
DayZPlayerImplement.EEKilled T3 yes ✓ Scripts.pbo::4_World\Dogtags\Entities\DayZPlayerImplement.c:6
DayZPlayerImplement.CanReleaseAttachment T2 yes ✓ Scripts.pbo::4_World\Dogtags\Entities\DayZPlayerImplement.c:22
InspectMenuNew.SetItem — yes ✓ Scripts.pbo::5_Mission\Dogtags\GUI\InspectMenuNew.c:13
ItemManager.PrepareTooltip — yes ✓ Scripts.pbo::5_Mission\Dogtags\GUI\InventoryNew\ItemManager.c:13
MissionServer.EquipCharacter — yes ✓ Scripts.pbo::5_Mission\Dogtags\Mission\MissionServer.c:3
MissionServer.InvokeOnConnect T3 yes ✓ Scripts.pbo::5_Mission\Dogtags\Mission\MissionServer.c:10
ModItemRegisterCallbacks.RegisterOneHanded — yes ✓ Scripts.pbo::4_World\Dogtags\Entities\ManBase\DayZPlayer\DayZPlayerCfgBase.c:3
PlayerBase.ClearInventory — yes ✗ none Scripts.pbo::4_World\Dogtags\Entities\ManBase\PlayerBase.c:4
PlayerBase.RemoveAllItems — yes ✗ none Scripts.pbo::4_World\Dogtags\Entities\ManBase\PlayerBase.c:28
PlayerBase.OnSelectPlayer — yes ✓ Scripts.pbo::4_World\Dogtags\Entities\ManBase\PlayerBase.c:41
PluginLifespan.UpdateBloodTypeVisibility — yes ✓ Scripts.pbo::4_World\Dogtags\Classes\Plugins\PluginBase\PluginLifespan.c:4
Dispatch surfaces and timers the grade prices
surfacetierrate (Hz)rate sourcems/s
DayZPlayerImplement.CanReleaseAttachmentT2 8.0placeholder0.0002
DayZPlayerImplement.EEKilledT3 0.1placeholder0.0000
MissionServer.InvokeOnConnectT3 0.1placeholder0.0000

Includes 0.000 ms/s from placeholder-rated surfaces.

Load-order constraints (CfgPatches)

What each PBO declares: its addon identity and the addons it requires to be loaded first (requiredAddons). A partial load-order signal from the mod's own metadata.

Characters.pbo

  • Dogtags_Characters — requires DZ_Characters

Defines.pbo

  • Dogtags_Defines — no requiredAddons

GUI.pbo

  • Dogtags_GUI — no requiredAddons

Gear.pbo

  • Dogtags_Gear — requires DZ_Data

Integrations.pbo

  • Dogtags_Integrations — requires DZ_Data, Dogtags_Scripts

LanguageCore.pbo

  • Dogtags_LanguageCore — no requiredAddons

Scripts.pbo

  • Dogtags_Scripts — no requiredAddons

census 1.1 · findings 1.1 · hash 04accbd889afe00f