← modperf · analyzed mods

Preferred Respawn - Experimental

Since survivors can "respawn-cycle", that is, choosing a spawn location by repeatedly F11-ing, why not automate this process in a fair and elegant way? The goal is to make the time it takes to respawn at a specific location using the Preferred Respawn mod the same time one would spend manually F11-ing to respawn at that same location in the unmodified game. The advantage is that the process is automated, allowing… (more)

Since survivors can "respawn-cycle", that is, choosing a spawn location by repeatedly F11-ing, why not automate this process in a fair and elegant way? The goal is to make the time it takes to respawn at a specific location using the Preferred Respawn mod the same time one would spend manually F11-ing to respawn at that same location in the unmodified game. The advantage is that the process is automated, allowing players to make use of that waiting time to grab a coffee, stretch, or do whatever they feel like. Features Minimal and non-intrusive changes to the vanilla user interface. The option to select a location only appears during respawns; the spawn experience is unmodified. Optional: casual mode in which the respawn time is fixed, similar to other "spawn select" mods. How it works If a survivor opts in for a preferred respawn location on the countdown screen (as shown in the screenshot above), their character will not respawn until the preferred location is selected by the default DayZ randomization. This means that the countdown routine restarts every time the preferred location does not match the one chosen by the vanilla randomization, and players must wait through the countdown for each new attempt. If the survivor does not opt in (the default setting), they respawn after the first countdown at a random location, just as in vanilla. It is also worth mentioning that players are free to choose a new location between attempts. Optional: it is possible to add extra time to the countdown to account for the time a player would spend F11-ing. This extra time only takes effect from the second attempt onward, as players do not need to F11 if they get the desired location on the first attempt in the unmodified game. Setup Spawn locations Predefined JSON configuration files for Sakhal, Chernarus, Livonia, Namalsk, and Deer Isle are automatically generated. If the cfgplayerspawnpoints.xml file used differs from the default provided with these maps, adjustments will most likely be necessary. In all cases, it is recommended to disable the vanilla "spawning groups" feature to avoid long wait times. If you wish to modify the default configuration or create a setup for a different map, start the server once after installing the mod. This action will generate configuration files, which you can then use as reference for editing. These files can be found in the <profile\config directory>\PreferredRespawnTest. Please note that the coordinates defined in the .SpawnZones.json do not necessarilly map one-to-one with the spawn points listed in the cfgplayerspawnpoints.xml. Instead, each location entry in the .SpawnZones.json represents a general area on the map and defines an option in the "preferred respawn location" selector on the countdown screen. Although locations and spawn points are not exactly the same thing, the settings in these files should remain consistent. Typically, each location should represent either a cluster of related spawn points or a single spawn point. For example, a valid configuration could have a single location entry representing a village in the .SpawnZones.json, while the cfgplayerspawnpoints.xml includes two or more spawn points for that same village. When a player selects that village as their preferred respawn location, any of the spawn points situated near the chosen location's coordinates will be considered valid respawn positions for the selection. The more spawn points a location has, the fewer countdowns a player selecting that location will typically need to wait through. For example, if one location has a single spawn point while another has two, players respawning at the second location will, on average, experience fewer countdowns. Note: an overly unbalanced number of spawn points among locations can make some areas too difficult to respawn in. That said, this mechanic can also be used creatively to steer player populations toward specific areas of the map. Casual Mode (optional) When noRedraws is set to true in the .Settings.json, the vanilla mechanism for the selection of spawn points is replaced, and players spawn instantly in the selected location after the first countdown reaches zero in the countdown screen. In this mode, the settings in the cfgplayerspawnpoints.xml are ignored for respawns, and players originate within 30m (~= 100ft) radius from some point specified in the .SpawnZones.json. Additionally, when this mode is enabled, it is possible to append extra points to each location in the .SpawnZones.json. This means that when a player selects a location in the countdown screen, one of the points from the selected location is randomized as the final one where the player will respawn. Example of a .SpawnZones.json with two locations and three spawn points for each: [ { "name": "Location_1", "centralPoint": [1100.0, 1100.0, 1200.0, 1200.0, 1300.0, 1300.0], "excludeFromRandom": 0 }, { "name": "Location_2", "centralPoint": [2100.0, 2100.0, 2200.0, 2200.0, 2300.0, 2300.0], "excludeFromRandom": 0 }, ] Location_1 spawn points: <1100.0, 1100.0>, <1200.0, 1200.0>, <1300.0, 1300.0>; Location_2 spawn points: <2100.0, 2100.0>, <2200.0, 2200.0>, <2300.0, 2300.0>; Conditions Repacking this mod is prohibited. Redistributing parts or the entirety of the contents of this mod is prohibited. You can use this mod on monetized severs if you have BI approval and the contents of this mod are not part of the monetization. This item is not authorized for posting on Steam (i.e. reuploaded, repacked) or any other platform, except under the steam account Akol. Copyright 2023-2026 Akol. Coffee Donations are not expected, but they are greatly appreciated!

Workshop 3078048921 · mod updated 2025-02-01 · analyzed 2026-10-03 08:27 UTC · history · 7 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
Chain-safe

Every server-visible override preserves its chain.

Structural footprint 1.1
A
clean
Heavier than 9% 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; 6 others share it. Ranked list.

20
40
60
  • 24 mods
    0.0000022 to 0.0000046 ms/s · grade A
  • This mod
  • 1 mod
    0.00001 to 0.000022 ms/s · grade A
  • 1 mod
    0.000022 to 0.000046 ms/s · grade A
  • 37 mods
    0.0001 to 0.00022 ms/s · grade A
  • 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

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

81%Lifecycle hooks · 81%
4 hooks · 0.000008 ms/s
Lifecycle hooksrun when an entity is created, loaded or deleted 4 hooks 0.000008 ms/s 81% MissionServer.InvokeOnDisconnect, MissionServer.OnClientNewEvent, MissionServer.OnClientRespawnEvent and 1 more

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.

Other findings

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 24 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
DayZGame.OnInitialize — yes ✓ PreferredRespawnTest.pbo::scripts\3_Game\AK_DayZGame.c:12
DayZGame.OnRespawnEvent — yes ✓ PreferredRespawnTest.pbo::scripts\3_Game\AK_DayZGame.c:83
DayZGame.LoginTimeCountdown — yes ✓ PreferredRespawnTest.pbo::scripts\3_Game\AK_DayZGame.c:112
DayZGame.OnEvent — yes ✓ PreferredRespawnTest.pbo::scripts\3_Game\AK_DayZGame.c:129
DayZGame.OnEvent — yes ✓ PreferredRespawnTest.pbo::scripts\3_Game\AK_DayZGame.c:149
LoginTimeBase.Init — yes ✗ none PreferredRespawnTest.pbo::scripts\3_Game\AK_LoadingTimeBase.c:19
LoginTimeBase.IsHandlingPlayerDeathEvent — yes ✗ none PreferredRespawnTest.pbo::scripts\3_Game\AK_LoadingTimeBase.c:78
LoginTimeBase.SetStatus — yes ✗ none PreferredRespawnTest.pbo::scripts\3_Game\AK_LoadingTimeBase.c:193
LoginTimeBase.SetRespawn — yes ✓ PreferredRespawnTest.pbo::scripts\3_Game\AK_LoadingTimeBase.c:195
LoginTimeBase.OnMouseEnter — yes ✓ PreferredRespawnTest.pbo::scripts\3_Game\AK_LoadingTimeBase.c:202
LoginTimeBase.OnMouseLeave — yes ✓ PreferredRespawnTest.pbo::scripts\3_Game\AK_LoadingTimeBase.c:214
LoginTimeBase.CanChangeHintPage — yes conditional PreferredRespawnTest.pbo::scripts\3_Game\AK_LoadingTimeBase.c:241
MissionGameplay.OnPlayerRespawned — yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:330
MissionGameplay.SetPlayerRespawning — yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:336
MissionServer.OnInit T3 yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:7
MissionServer.OnClientRespawnEvent T3 yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:121
MissionServer.OnClientPrepareEvent — yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:129
MissionServer.InvokeOnDisconnect T3 yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:137
MissionServer.OnEvent — yes conditional PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:159
MissionServer.OnClientNewEvent T3 yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:196
MissionServer.SetVoNActive — yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:268
MissionServer.OnClientPrepareEvent — yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:274
MissionServer.OnEvent — yes ✓ PreferredRespawnTest.pbo::scripts\5_Mission\AK_missionServer.c:287
PlayerBase.SimulateDeath — yes ✓ PreferredRespawnTest.pbo::scripts\4_World\AK_PlayerBase.c:12
Dispatch surfaces and timers the grade prices
surfacetierrate (Hz)rate sourcems/s
MissionServer.OnInitT3 0.1placeholder0.0000
MissionServer.OnClientRespawnEventT3 0.1placeholder0.0000
MissionServer.InvokeOnDisconnectT3 0.1placeholder0.0000
MissionServer.OnClientNewEventT3 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.

PreferredRespawnTest.pbo

  • PreferredRespawnTest requiredVersion 0.1 — requires DZ_Data, DZ_Scripts, JM_CF_Scripts

census 1.1 · findings 1.1 · hash a80e8b73ed2c0196