Pack this project's mods. Returns a job_id.

Runs mod_lint first and refuses on what it refuses. That check costs milliseconds and the boot it replaces costs a minute -- and two of the defects it names would not appear in that boot's log at all, because a modded class that modifies nothing loads and reports success.

skip_lint=True packs anyway. It exists because a refusal that cannot be overridden is a refusal that gets worked around by not using the tool.

Start the test server and wait for it to be ready. Returns a job id.

Two things worth knowing before calling, both observable:

It CLEARS THE BRIDGE TRANSPORT first -- the command mailbox and the state file in the -profiles directory are removed before the server is spawned, so no world ever starts against a command or a state document left by an earlier one. Script logs are deliberately left alone; see clear_bridge_transport for why the two are treated differently. A file that could not be removed is reported in bridge_transport_left and on the job, and never fails the boot.

It REFUSES if the game port is already held, naming the pids holding it. A stand is shared -- one machine, one port, one profile directory -- and booting into a held port produces a server that dies during world load with nothing in its own log to say why. If the holder is a server this session started, the hint says to stop it with server_stop. If it is anyone else's, the refusal identifies it (pid and -mod= tail) and offers stopping it as the caller's own act -- the owner authorised stopping a neighbouring stand that blocks a live run -- but this tool never auto-stops a process it did not start.

extra_args appends launch arguments after the fixed ones -- an explicit one-run opt-in, the same pattern as attaching the bridge, not profile surgery. A list of strings, never one string to re-split. Arguments the tool itself owns (-config, -profiles, -port, -mod, -serverMod) are refused: the profile is where those are decided. The extras are recorded in the boot job's summary, so a later reader can see the boot was non-standard. The known use is the engine's action log (-doScriptLogs=1 -logToFile=1), which writes to scriptExt.log -- a file log_verdict never reads, so these flags cannot poison a verdict.

Readiness has two independent signals, and the summary always names which one answered. expect.ready_line appearing in a log written by THIS run says the MOD finished loading. The game port being bound by the pid we spawned says the ENGINE is up and listening -- which needs neither a mod nor a declared line, and is the readiness verdict for a project that declares none (measured on a real stand: bound 16.9s after spawn). With a ready line declared it remains the verdict, since a bound port cannot say a mod loaded; the port is then what tells "the boot failed" apart from "the server is listening and it is the mod's line that never appeared".

A quick health read: is the process alive, and is its log actually growing.

A hung boot and a slow one both look "alive, no ready line yet" from the outside -- this project has hit a genuine post-compile server hang before -- so this samples the newest log's size twice, pulse_seconds apart, and also reports how long it has been since the log last changed at all.

Stop a server this session is responsible for.

With no pid, stops the session's own currently tracked server (the original behaviour). With pid, stops that specific process instead -- but only if this session started it at some point, or it was reported as orphaned_server_pid by project_open after a project switch (see session.known_pid). Any other pid is refused: this is the only way an orphaned server can be reached at all, and it must not become a general process killer.

Either way, the pid is checked against the recorded image name before it is handed to stop() (which calls taskkill): a recycled Windows pid can belong to an unrelated process by the time this runs, and killing that process instead would be a worse outcome than the stale bookkeeping this guards against.

Compile the CLIENT half of the scripts and judge the result. Returns a job id.

A server boot never compiles anything behind the client-only guard, so a broken menu, a broken widget or a broken client-side action passes every server check and then breaks in front of a player. This runs the diagnostic client for wait_seconds, stops it, and judges what it wrote -- and the verdict does not accept a clean log on its own: the game's own "Module: Mission" line has to appear, otherwise "no errors" only means "not that far yet" and the job says so.

The client runs against a THROWAWAY -profiles directory inside this job's artifacts, so it never reads or writes the test stand. It also joins nothing: this is a compile pass, not a session. For the live client that connects to the stand -- and for looking at it, acting through it, and judging its .RPT -- the tools are client_start and its siblings, and log_verdict(source="client") reads THIS job's log while client_verdict reads the live client's.

extra_mods appends to the -mod list for this run only, for checking that a mod still compiles alongside another one.

Judge the newest log for source.

since ties the verdict to a specific run (typically the value server_start returned): a log last modified before since cannot belong to the run being judged -- it is a leftover from an earlier boot (possibly one still holding the file open on Windows) -- so it is refused as a reason, not silently judged.

Wait for a job to finish, or until timeout seconds pass.

timeout is clamped to at most MAX_WAIT_SECONDS (600s) regardless of what is requested.

Pack the bridge mod from this repository's own sources.

The bridge is the server's own mod, not the project's: one copy serves every project, and it is built UNSIGNED -- no project's signing key is used, and the output folder is kept free of signatures and keys.

Building it does not load it. Attaching it stays a profile decision (the job summary prints the two lines to add), because the bridge is an extra pbo in the stand and a run without it has to remain possible.

Is the bridge inside the running game still ticking?

Blocks for up to window seconds (default 2, clamped to STATUS_WINDOW_MAX) because that is what it costs to see a tick MOVE. window=0 returns at once and then usually cannot tell -- it reports "unknown", never "frozen".

A stand with no state file at all now costs the FULL window too (measured: 2.07s at the default, 10.05s at the cap), because the reader retries to the deadline rather than giving up on the first miss. If the question is only "is the bridge publishing anything yet" -- the usual one while wiring it up -- pass window=0 and get the same answer in a tenth of a second; a window buys movement, and nothing else.

The answers, told apart in this order:

no_server nothing is running, so there is nothing to ask. Checked FIRST and on the process, not on the file: the state file outlives the server that wrote it, and reading a leftover snapshot as a live bridge is precisely the lie this ordering prevents. stale_command the same, but with a command still sitting in the mailbox. Its own answer because the remedy is its own: the command does not expire, it blocks every send, and a stand booted OUTSIDE these tools would pick it up. (server_start clears the transport before every boot, so a server started through these tools will not.) no_state_file / the server is up but nothing readable came back. Four outdated_bridge / fixes, so four answers: the mod is not loaded; the mod invalid_state / predates this server's protocol (no session_id at all); unreadable_state the document is valid JSON but a named field is wrong (the answer says which field, what was expected and what was seen, and it is checked twice a publish interval apart so a mangled write is never reported as a schema bug); or it does not parse at all. alive / restarted a comparison was made. alive means the tick moved; / frozen / restarted means a new world came up mid-sample (also unknown alive, and NOT frozen); frozen means the same world was seen twice without moving; unknown means no comparison could be made. Only the first two return ok.

Discard whatever command is sitting in the mailbox.

The remedy for bridge_status's stale_command. Inside the game, claiming a command IS deleting the file, so a command sent while the stand was down, or before the bridge was wired into -serverMod, is never claimed and never expires on its own: it blocks every later send until something removes it. Two things on this side do -- this tool, and server_start, which clears the transport before every boot. A stand booted outside these tools would run the command instead.

Its own tool, and never a side effect of asking for status: throwing away a queued command is a decision, and bridge_status reporting the wedge must not be the thing that silently resolves it.

Refuses when anything suggests the bridge is alive, because a running mod could claim that command at any moment and destroying live in-flight work is worse than leaving the wedge. FIRST on the plain fact that a server this session started is running -- whatever its bridge is or is not publishing, which matters most for a mod that has not started writing state yet -- and that refusal costs no probe at all. Otherwise the channel probes for probe_window seconds and refuses on a tick that moved, on a world that restarted, AND on a readable first sample followed by an unreadable second one -- that last is proof something was alive moments ago, which a downed stand never produces. force=True overrides all of it, and what it overrode is reported either way.

Wait until the bridge inside the game is actually ticking.

Call this once after server_start's boot job finishes and before the first world command. The bridge publishes its first state during mission init but does not start reading commands until tens of seconds AFTER the server reports ready -- 18-38 s in the boots measured so far. A command sent in that window is claimed eventually and completes normally, long after the caller gave up.

Blocks, with a ceiling, because there is nothing else to do with the answer: the alternative is handing back "not yet" and having the caller poll, which is the same wait with more round trips.

What the world looks like right now.

With NO class_name this costs nothing and waits for nothing: the mod republishes the player's position, health and what is in their hands every tick, so the answer is already on disk. That is deliberate -- a snapshot a caller has to pay a full command round trip for (a second to be claimed, two more of terminal dwell) would make the cheapest question the most expensive one.

With a class_name it also sends a query command to count objects of that class within radius, because a count needs arguments only a command carries. The count comes back in world.query_count as well as in the detail, so it stays readable on later snapshots too -- which is how "is the item I spawned a minute ago still there?" gets answered.

Create an item: on the ground, in the player's hands, or in their inventory.

where is "ground" (default), "hands" or "inventory". A ground spawn takes pos as "x y z" and falls back to the player's own position when it is omitted; with neither a position nor a player, the mod says so in words rather than doing nothing.

Ground spawns are created with ECE_PLACE_ON_SURFACE and ECE_NOLIFETIME. Without the second flag the item lives by the lifetime in its own config and the central economy is free to remove it partway through a check -- which turns "my test item vanished" into a hunt through the mod under test. The flag is the mod's, not this tool's; it is named here because it is the reason a spawned item can be trusted to still be there a minute later.

Move the player to pos, given as "x y z".

The same format world_state reports positions in, so a position read out of a snapshot can be handed straight back. With nobody connected the mod refuses by name -- an absent player is a distinct, stated reason, never a silent no-op.

Set health or quantity.

target is "player" or "hands"; left empty it defaults per what -- health on the player, quantity on the held item -- because a single default for both would make one of the two combinations a trap (a player has no quantity, and empty hands have no health).

Delete every object of class_name within radius of pos (or of the player, when pos is omitted).

The class is required: the mod will not delete everything nearby regardless of class, and the radius is clamped on its side. Players are never deleted, whatever the class filter says.

Run a mod's own action through the engine's gate, on the server.

action_class is the action's script class name. There is deliberately no verb dictionary: the same word means different things in a mod depending on context, so applicability is decided by the ACTION'S OWN Can() -- and its refusal is a meaningful test result, not a tool failure. The distinguishable refusals, classified in the mod before the engine is touched: the manager is busy; the player is already acting; the player is sprinting; the action class is unknown; and "the action's own Can() said no" -- the last one being the answer this tool exists to produce.

target_class names the config class of the object to aim at (resolved to the first match near the player); many actions take no target and it can be omitted. subject optionally names a Man-derived entity class to act AS instead of the connected player -- a diagnostic escape hatch, because a spawned survivor owns an action manager while not being counted as a player.

"Accepted" is not success: the engine can drop an accepted action one frame later without clearing it. The mod therefore holds the command running until the manager actually releases the action, and any failure path releases it too -- otherwise that player could never act again for the rest of the session. Expect an answer only after the action has genuinely ended; a stuck action fails by the mod's own 20s watchdog, with the release noted in the detail.

Send an arbitrary verb through the bridge -- the debugging escape hatch, not a testing path.

This server does not know the verb, does not validate its arguments beyond stringifying them, and does not answer for what the mod does with it; every answer is marked non_standard to say so. Anything a mod's behaviour can express as an ACTION should go through world_action instead, where the mod's own Can() gives the refusal meaning.

A verb this bridge build does not know comes back as a failure listing the verbs it does -- that is the mod answering, not this tool guessing. A project that needs its own verb adds it to ITS OWN copy of the bridge's dispatcher (IsKnownVerb, the routing, and a handler); this server ships no registration machinery on purpose, because a verb the server typed and validated would be a verb the server answers for.

The verb must be lowercase ASCII (letters, digits, underscore, up to 41 chars): the mod recovers a command's id by a raw string search when a parse fails, and the id embeds the verb -- characters outside that set can make a failure impossible to correlate, which is the silence this product exists to remove.

Start the game client and connect it to the test stand. Returns a job id.

Three things worth knowing before calling, all of them observable:

IT LAUNCHES WINDOWED, always. A fullscreen D3D window does not yield the foreground -- an attempt to cover one simply hung -- so a fullscreen client can be neither typed into nor left behind while the owner works. The window size itself is the client profile's business (DayZ.cfg), not this server's.

IT REFUSES WHEN THERE IS NO STAND TO JOIN. The client connects, it does not listen, so there is no port of its own to pre-flight; what there must be is something already on the stand's port. Without that the client sits at the server browser forever and every later tool answers about a client that never joined anything.

IT READS pauseMode AND WARNS. That setting (GAME -> UPDATE IN BACKGROUND, stored in the client's own profile) is why the screenshot is a live frame and why the gamepad moves the character while another window has the foreground. At another value both stop working with nothing said anywhere, so the value is reported on every start and a warning is attached when it is not the one measured here. It is never rewritten: it belongs to the person who owns this machine and is changed from inside the game.

READINESS IS THE PLAYER COUNT IN THE BRIDGE STATE, NOT A TIMER. Connecting took about 50 s when it was measured and it varies; a timer would call a still-loading client ready and a never-connecting client a success. The job finishes when the bridge publishes players >= 1, and if that never happens the failure says which of the two things went wrong -- the bridge was never readable (the signal was unavailable) or it was readable and nobody joined (the client itself did not get in).

extra_args appends launch arguments after the fixed ones, an explicit one-run opt-in. Arguments this tool computes (-connect, -port, -mod, -profiles, -window, -nolauncher) are refused rather than allowed to displace its own.

Everything about the client that decides whether the other tools can work.

Four questions in one answer, because each of them has silently broken a run before: is the process alive; is its window in a state the eyes can capture (a MINIMIZED window cannot be captured at all -- its client area is 0x0); is UPDATE IN BACKGROUND still at the value that keeps the frame live and the gamepad effective while unfocused; and has the client actually joined the stand (the player count the bridge publishes).

Stop the client this session started, and unplug the virtual controller.

The pad goes with it deliberately. Nothing else in this tool set closes it, and a controller left attached is visible inside any game running on this machine -- DayZ switches its on-screen hints to controller mode as soon as one appears. Stopping the client is the end of the input session, so it is where the device is given back.

Takes no pid on purpose: the client runs the same executable as the server, so a pid argument could not be checked against the image the way server_stop's is, and "stop this pid" would become a general process killer.

Capture the client's window to a PNG. NO FOCUS NEEDED.

Measured rather than assumed: the frame is live with the client at the very bottom of the z-order and live when it is in front. The one state it cannot survive is MINIMIZED -- the client area collapses to 0x0 and there is nothing to copy -- and that is refused with a hint saying to restore the window, not reported as an empty picture.

lit_fraction in the answer is the honest half: a black capture is exactly the failure that otherwise reports success, so the fraction of non-black pixels comes back with every shot. A dark frame is never failed -- night is dark -- but a caller reading 0.0 knows the eyes were shut.

With no path the file lands in this project's own .dayz-mcp/shots.

Walk the character with the left stick. NO FOCUS NEEDED.

x is positive to the right, y positive forward, both in [-1, 1] and clamped (and reported as clamped) beyond that. client_move(0, 1, 6) is the measured 24 m walk. The stick is back at rest when this returns, on every path including a failure -- a stick left engaged is a character running forever with nobody watching.

This is the only tract that moves the character at all: keyboard emulation was measured at 0 m over 25 s with the foreground verified. It is also the only one that is ANALOG, so "walking rather than sprinting" is testable here and nowhere else.

The first call attaches a virtual controller to this machine, which the game can see -- DayZ switches its on-screen hints to controller mode -- and the answer says so. client_stop unplugs it.

Turn the camera with the right stick. NO FOCUS NEEDED.

Same units and the same guarantees as client_move: x positive right, y positive up, clamped to [-1, 1], released on every exit path.

Press one gamepad button. NO FOCUS NEEDED -- this drives the INTERFACE too.

Measured with a third-party application holding the foreground the whole time: right_shoulder moved between options tabs, back opened and closed the inventory, b left the menu. So menus and inventory are reachable without ever taking the screen from the person at the machine, and that is why this module offers no window messages and no mouse: window messages were measured to do nothing at all.

What a pad cannot do is type -- DayZ has no on-screen keyboard. Text in chat goes through client_chat (server-side, no focus); text in a mod's own input field goes through client_type (real input, foreground).

Buttons: a b x y back start left_shoulder right_shoulder left_thumb right_thumb dpad_up dpad_down dpad_left dpad_right.

Put a line in the connected player's chat. FOCUS IS NOT NEEDED.

Said plainly because the general rule about typing does not apply here. Chat is a SERVER-SIDE MESSAGE: the engine hands the mod a call that delivers text to a player, so the bridge sends it as data -- no keyboard, no window, no foreground, and nothing taken away from whoever is at the machine. It is also more trustworthy than real typing, because the command carries an id and comes back with the mod's own confirmation instead of "typed it and hoped".

This is NOT the tool for a mod's own input field -- a PDA, a terminal, a form. Those exist only on the client and are filled by client_type, which does need the foreground.

The line goes to EVERY connected player, and the answer says how many got it: the engine's call names one recipient, so a verb that quietly took the first player would put the line on one screen and leave it missing from the one the caller was watching.

color is one of colorStatusChannel (the default), colorAction, colorFriendly or colorImportant. Anything else is refused BY THE MOD rather than passed on, because the client turns a colour class it does not know into plain white and says nothing about it. Long lines are refused too, rather than cut somewhere the caller cannot see.

What success promises is that the engine accepted the call for each named recipient -- not that the line was visible. A client drops whole chat channels according to the player's own profile options, so an accepted line that nobody can see is a client setting, not a fault in the bridge.

Requires the bridge to be loaded and ticking, like every other world command, and requires the stand to be running a bridge build that knows the verb; if it is not, the mod says so and the hint says what to do.

Type into a CLIENT-SIDE INPUT FIELD -- a mod's PDA, terminal or form. REQUIRES THE ACTIVE WINDOW, and takes it.

This is not chat. Chat is a server-side message and client_chat delivers it with no focus at all; use that unless the point of the test IS the typing. What this tool is for is the case the bridge cannot reach: a field that exists only on the client, which can only be filled the way a person fills it -- the input line opening, the characters landing in the field, the keyboard layout behaving.

So it brings the client window to the front and VERIFIES that it got there before sending a single keystroke. If Windows refuses -- which it does to a background process -- nothing is typed and the refusal says so, rather than keystrokes going into whatever window the person at the machine is using. That accident happened here once and is why the verification is not optional.

A successful call reports that the foreground was taken, because that is a side effect on a human, not an implementation detail.

The text is typed as US-layout scancodes, because the client starts on another layout and a virtual-key code would produce different characters. Anything with no scancode is refused by name BEFORE the screen is taken -- an underscore that arrived as a hyphen once failed a run as if the mod were at fault.

submit presses Enter afterwards, so filling a field and confirming it does not need a second tool that takes the foreground all over again. With submit=True and EMPTY text it sends Enter and nothing else, which is the only way anything in this tool set can confirm or open something. Measured on a live client: the game binds its chat line to Enter alone, and the virtual gamepad's A button -- the obvious candidate for a confirm -- moved nothing in the pause menu at 0.1 s or 0.5 s, while B (back) dismissed it at the default. So dismissing is a gamepad job and confirming is this one. Empty text WITHOUT submit is still refused: it would take the foreground to do nothing at all.

Judge the running (or last) client by its own .RPT.

The .RPT and not a script log, and that is a finding rather than a preference: in the Steam DIAG build the script log receivers are compiled out, so -logToFile / -logToScript / -logToRpt inject nothing and no script_*.log is produced for a client at all. Whatever the mod printed to the RPT is here; whatever it wrote only to the script log does not exist, and this says so instead of returning a clean verdict over an empty file.

Not to be confused with log_verdict(source="client"), which judges the throwaway profile a client_compile_check job produced. This one judges the LIVE client -- the one client_start launched, against the stand.

since ties the verdict to a run (pass the value client_start returned): a report last modified before it belongs to an earlier client and is refused as a reason rather than silently judged.

Build or refresh a knowledge layer. Returns a job_id immediately.

Layers, and how often each one needs this:

project the mod's own sources, read where they lie. Goes stale on every edit -- rebuild it whenever you want to ask about code you just wrote. Measured: 0.11 s for 41 files. deps the archives of the mods this project declares as dependencies, read without unpacking them. Stale when a dependency is updated or the declared set changes. Measured: 150 s for 36 mods. core the game itself: scripts.pbo for the API, Addons/*.pbo for the item classes. Stale when the game updates. Measured: 3.9 s for the scripts alone, 69 s with the configs. all (the default) every layer that applies to this project. Layers that cannot be built here -- no game installed, no dependencies declared -- are named with the reason instead of failing the call.

Nothing here blocks: wait with job_wait(job_id, timeout=...) and read the per-layer numbers in the job's summary and its knowledge-build.json artifact.

only=[path, ...] is the fast route for the project layer when you already know what changed. It re-reads exactly those files and skips the directory walk entirely -- and it therefore does NOT notice a file created or deleted anywhere else. A named path that no longer exists is dropped from the index, so a delete you name is handled; one you do not name is not. Without only, every build is incremental anyway: unchanged sources are skipped by size and modification time, and full=True forces the whole layer to be re-read.

What each knowledge layer holds, how old it is, and whether it still matches what is on disk.

Staleness is a measurement, never a guess: each layer records the size and modification time of every source it read, and this compares them against the files as they are now. A layer reports what changed, what appeared and what is gone -- so "the project was edited" is a different fact from "the game was updated", which is the whole reason there are three layers.

Two counts that must not be confused, and both are here: sources is everything the build walked, and empty_sources is how many of those gave no declarations at all -- an archive that could not be read, or a file that genuinely declares nothing. Which of the two is in last_build: skipped is what the LAST build could not read, and outstanding is every source the layer still holds nothing from, including ones an earlier build found. The second exists because the first is correctly empty after an incremental build that re-read nothing, which left empty_sources standing with no explanation at all.

Find declarations by name: classes, methods, constants, enums, configs.

Matching is case-insensitive and exact unless prefix=True. Answers come nearest-layer-first -- the project's own declaration before its dependencies', and those before the game's.

kind separates two namespaces that share a name space:

'class' a class declared in Enforce Script 'method' a function, with its owning class and full signature 'constant' / 'enum' what flags like ECE_* are found through 'config' a class declared in a config.cpp or a binarised config.bin -- this is how you ask "does the game have an item class called X". Kept apart because the game alone holds 88 102 of them against 43 595 script declarations, and mixed together they bury every script answer.

Every answer names the layers it used and how old each one is -- and an answer with no results names every layer it searched, because "not found" is worth exactly as much as the layers behind it are current. The project layer's staleness is measured on every call, so an answer taken from an index built before your last edit says so instead of describing code that no longer exists. A search that finds nothing while a layer that could have held it was never built is refused, not answered: "not found" and "not looked" are different facts.

Narrowing has the same trap one level down, so an empty narrowed answer checks whether the name exists outside the narrowing and says where in elsewhere -- asking for kind='class' about a name the game declares only in a config gets a true "no" that reads as "the game has no such class".

Every search runs under a hard time ceiling and a result limit; neither can be removed.

Everything the index holds about one declaration.

Where knowledge_find lists matches, this expands them: the full signature, the file and line, what the declaration inherits from all the way up, and -- for a class -- what is declared inside it.

body=True reads the declaration back out of the source it was indexed from, up to max_lines lines, including out of an archive that was never unpacked. A binarised config has no readable source to return and says so rather than returning nothing.

Matches come nearest-layer-first, so a class a dependency reopens with modded class is shown before the game's own declaration of it: pass layer='core' to ask the game specifically.

Like every answer here, it names the layer each declaration came from and how old that layer is -- and when it finds nothing, every layer it looked in.

Who overrides this class or this method -- the question a text sweep answers worst.

For a method: every declaration of it marked override, and every one declared inside a modded class, which routinely replaces a method without writing override at all. The original declaration is not an answer.

For a class: everyone who extends it, and every modded class that reopens it.

Both readings are answered at once, because a caller asking "who overrides X" usually does not yet know which X it is. The answer names the layer each hit came from and how old that layer is; a search over a layer that was never built is refused rather than answered emptily.

Who CALLS this -- every place a method is invoked or a class is built.

A different question from knowledge_overrides, and one no search over declarations can answer: an override is a declaration, a call is not. This is the question asked before changing a signature, before removing something, and when working out how a piece of the game is actually used.

kind narrows to call or new. owner narrows to calls made from one class. Each hit names the class and method it was made from, the file and line, and the layer -- with that layer's age, like every other answer here.

What it does NOT see, so that an empty answer is not read as proof: a call reached through a variable whose type the index does not track is recorded under the method's own name, not the variable's, and new array<string>() has no identifier before its parenthesis to record at all.

Check a mod's Enforce Script without packing or booting anything.

mod limits the check to one of the project's mods; empty checks them all. strict makes warnings count as failure too -- off by default, because a warning is something to read, not something to stop for.

Refusals: a class that extends itself (modded class X extends X loads and applies nothing), an exception statement (try/catch/finally are not Enforce), and a modded class whose target nothing declares.

Warnings: a statement continued onto the next line with a leading +, which Enforce drops silently.

The modded class check needs the knowledge index, and says so when the index cannot answer: an unbuilt layer makes it warn rather than accuse, because "no such class" and "I have not read the game yet" are different answers and only one of them is the mod's fault.

Read -- or deliberately change -- the stand's signature policy.

With no argument this only reports. With value it writes verifySignatures into the config the profile names as this stand's, and reads it back.

WHY THIS IS ITS OWN TOOL. verifySignatures = 2 makes a stand refuse every client with code 118 and "missing dtain.pbo" -- a vanilla file name that says nothing about signatures, and that has already cost one session a long hunt through byte-identical files. On a local stand the honest fix is usually to turn the check off rather than to sign a throwaway bridge mod, and doing that by hand in somebody's config is worse than doing it here, where the previous value is reported, the file is read back, and nothing else in it is touched.

WHAT KEEPS IT SAFE. It edits exactly one file: machine.stand_root / machine.config, the stand this project already boots, and it refuses a path that resolves outside that root. It refuses while a server is running against that config, because a change the running server will never read is a success message about nothing. And it says which way the setting moved: 0 is off, and the answer says so in words rather than leaving a number.

WHICH objects are nearby, not how many.

world_state(class_name=...) counts; this one names them, with each object's class, position, distance and health. An empty class_name lists everything found rather than nothing.

The list is a page: the mod caps it at 200 entries and reports the true total separately, so total larger than count means there is more out there -- never a shorter list quietly standing in for the world.

distance is HORIZONTAL, because the engine's own radius test ignores height: at the centre of Chernarus the terrain is 300 m up, so a straight-line distance from a position written as "7500 0 7500" reads 320 m for objects the engine returned inside a 150 m radius. A number that contradicts the filter that produced it is worse than no number.

Players are not in it. The mod's own gather step skips them, which is what keeps a delete of everything nearby from reaching the person standing in it, and this tool shares that step deliberately rather than growing a second notion of what is in the world.

Move the world clock.

Every field left at -1 keeps the value the world already has, read back from the engine before the change. That matters because the engine sets a date as five numbers at once: a tool that filled in the missing ones would move the date every time somebody set the hour.

Ranges are the engine's own documented ones -- month 1-12, day 1-31, hour 0-23, minute 0-59 -- and are checked in the mod, before a native call that would otherwise be handed a value it does not define behaviour for.

The answer carries the world's clock as it stands after the change, from the mod's own snapshot rather than from what was asked for.

Move one weather phenomenon towards a value.

what is "overcast", "rain", "fog", "snowfall" or "wind". The first four take a value between 0 and 1; wind takes a speed in metres per second. seconds is how long the change takes (0 is immediate) and duration is how long the value is held before the engine's own simulation may move it again.

THIS IS A NUDGE, NOT A LOCK. The engine keeps simulating weather, so a value set here drifts afterwards -- said here and in the mod's own answer, because the alternative is a caller who sets rain, looks up two minutes later and concludes the tool did nothing.

What the client's interface is doing right now.

Free: the client half republishes the open menu's class, whether the cursor is visible and whether a modal dialog is up on every tick, so this answer is already on disk and costs no command round trip -- the same bargain world_state makes with no arguments.

The client's widget tree: what is on screen, as the engine holds it.

root is "menu" (the open scripted menu, the default) or "screen" (the whole workspace). Each node comes back with its path, class, name, visibility, screen rectangle, depth and -- where the engine allows it to be read -- its text.

The answer is A PAGE: total is how many nodes the walk visited and count is how many it listed, and truncated says when they differ. A shorter list that did not say so would read as the whole interface.

Find widgets by name, class or text, without fetching the whole tree.

name and class_name match exactly; text matches as a substring, because a label's exact string is the one thing a caller rarely knows in advance. At least one of the three is required -- with none of them this would be ui_tree, and answering it as such would hide which question was actually asked.

Filtering happens in the client, not here: sending the whole tree back so it could be filtered locally is exactly what the page limit exists to avoid.

Press a widget, by path, having checked it is still the one meant.

expect_name and expect_class are how a path stops being a loaded gun. A tree walked a minute ago is not the tree in front of the mouse now, and pressing "whatever is at 0.3.1 today" is how an automated run presses the wrong button and reports success. Both are optional -- sometimes the caller genuinely means "whatever is there" -- but then that is the caller's own decision, taken in the open.

TWO TRACTS, and the answer always says which one was used:

• via="script" delivers the click to the open menu's own handler. Works with the client in the background, no focus taken. Reaches ONLY the open scripted menu: Widget has no GetHandler, so a HUD widget's own handler is not reachable from script at all.

• via="cursor" puts the real mouse on the widget's rectangle and clicks. Reaches anything the player could click -- and TAKES THE FOREGROUND, like client_type, because a real click goes wherever the real cursor is.

A handler that returns false is reported as what it is: the click was delivered and the menu did not act on it. That is a fact about the mod, not a failure of this tool, and the answer says so rather than inventing a verdict.

Write into an edit box, and read it back.

Only a field the player could type into may be written. A plain TextWidget has SetText too, but writing a mod's label from outside would change what the player sees without changing anything the mod believes -- a lie drawn on the screen -- so it is refused rather than quietly allowed.

The value is read back out of the widget before the answer is returned: SetText is native and returns nothing, so "it was set" would otherwise be this tool's own claim about itself.

Declare, inspect or clear the active mod set.

With no arguments it reports the set in force and every mod folder the dependency layer holds, so a caller can see what there is to choose from.

mods=[...] narrows every knowledge answer to those mod folders. The game and the project's own code always answer -- the game is the substrate a DayZ mod is written against, and the project layer is the code being written, so narrowing either would report "no such class" about code you are looking at.

Nothing is hidden by the narrowing. A search whose answer lies in a mod outside the set does not come back empty: it comes back naming the mod that holds it, and it comes back as a refusal, so it cannot be read as "no such thing". That is the whole point of the feature -- an invisible narrowing is the same silent lie as an answer from a stale layer.

source is free text saying where the set came from ("the server at

clear=True returns the index to answering from every mod it holds. An empty mods=[] is refused rather than read as "narrow to nothing": those are different requests and only one of them is ever meant.

The set is stored beside the index and survives a restart. It is NOT changed by server_mods, which only proposes one.

Ask a running server which mods it runs, and PROPOSE an active set.

address is "host" or "host:port"; query_port overrides an embedded one. It must be the QUERY port, not the game port. The game port never answers a Source query -- measured on six live servers, silent on all six, while the query port answered on all six. The two are not related by a fixed offset (252 distinct offsets in a live sample): a server browser shows it, and for a local stand it is steamQueryPort in the server config.

The answer is three buckets, matched by Workshop id and never by name:

matched the server runs it and it is installed here on_server_not_installed the server runs it and this machine has not installed_not_on_server installed here, the server does not run it

Nothing is applied. proposed_scope and apply are a suggestion and the exact call that would take it; running that call is a separate, deliberate act. A query that silently rescoped the index would make a mismatch an invisible action rather than something the caller read.

Three things this cannot see, and it says so in notes rather than letting the answer read as complete: server-only mods (reasoned, not tested), the BUILD of a mod behind an id, and mods downloaded but not linked into the modpack.

Export a model out of a .blend into the project's model root.

Returns a job_id; wait for it with job_wait(job_id, timeout=...). One five-LOD model measured 2.1 s warm and about 8 s cold, but the ceiling is minutes, because how long an export takes is a property of the model.

This is the pipeline's OPTIONAL first step. It produces the MLOD; the binarized model that the game loads is what asset_build makes from it, and that is a separate call on purpose -- each half has its own verdict, and a mod whose .p3d came from somewhere else skips this entirely.

The project root declared as build.project_root is pushed into the exporting add-on for the duration of the run, so what the add-on has stored decides nothing. That matters: an add-on preference is remembered from whatever was open last, and against the wrong root every texture path comes out with the drive letter stripped and the rest kept -- valid-looking, resolving to nothing, reported as a success.

The verdict is read off the file: it must be an MLOD, this run must be what wrote it, all of the source's LODs must have reached it, and none of its references may leave the mod. Measured on a real model: with the exporter's own default arguments, 2 LODs of 5 came out as a valid MLOD with correct paths, FINISHED, exit 0, and no mention of it in 169 lines of log.

blend is absolute, or relative to the repository, or relative to build.project_root. source is the directory the model should land in, relative to the mod's own folder under that root (e.g. "data/models"); with exactly one such directory already holding models it can be omitted. name is the file to write, defaulting to the source file's own name with a .p3d extension.

Nothing else is touched: an export that produces nothing leaves the model that is already there exactly as it was, and Blender's user preferences are never written back.

Build a mod's models from their MLOD sources and put them in the mod.

Returns a job_id immediately: ONE small model measured 75.6 to 78.7 seconds across four runs, so this can never be a blocking call. Wait for it with job_wait(job_id, timeout=...) -- give it minutes, not seconds -- and read the numbers in the job's summary and its asset-build.json artifact.

What it does, in order: run binarize with its working directory set to the project root declared as build.project_root, judge the ARTIFACT that came out (never the tool's exit code -- three separate broken outcomes were measured exiting 0, one of them leaving a zero-length file), and only then copy the models into the mod. A refused build deploys nothing and leaves the artifact the mod already ships exactly as it was.

mod names one of build.mods; with a single declared mod it can be omitted. source is the model directory relative to the mod's own folder under the root (e.g. "data/models"); left out, the only directory holding .p3d files is used and two candidates are a refusal rather than a guess. deploy=False builds and judges without writing into the mod.

The source is the MLOD export and the ODOL is the build's output (decision D3). Handed an ODOL, binarize dies with 0xC0000005 and leaves a zero-length file behind, so that is refused before the process starts.

Model.cfg is never copied for you: it is what the artifact was built from, and a mismatch between the copy under the root and the copy in the mod is reported by C11 with what to do about it. Rebuilds are not byte-stable and are not expected to be -- what a rebuild is compared against is structural.

Judge the models and textures a mod already ships. Builds nothing.

Needs no DayZ Tools and no build: every check reads a file that is already on the disk, because the tools that produce these files are structurally unable to report failure. Answers in milliseconds.

Twelve checks (C1-C12). Four of them refuse, and this call fails when one does: a built model is there and is an ODOL, no reference escapes the mod, a material was actually inlined, and nothing already binarized is offered back to binarize. The rest warn -- dangling references, an rvmat pointing into another mod, a transparency lost to DXT1 (C7), an animation that never reached the artifact, a model.cfg that is not the one the artifact was built from, and a structural fingerprint that no longer matches what the last build deployed. Every finding says what to DO about it.

model narrows it to one file, relative to the mod's directory. Files the packer will drop (build.exclude) are not judged: a refusal about a file that never enters the pbo is a refusal about nothing.

A texture is judged against the PNG it came from -- beside it or at the same place under build.project_root -- because a legitimately opaque texture and one whose transparency was destroyed are identical in the output alone.

Convert one texture between .png and .paa, and judge the result.

Which compression ImageToPAA writes is decided by the SOURCE FILE'S NAME, and nothing says so at the time: a name ending in _co produces DXT1, which keeps ONE BIT of alpha. A source measured 6 distinct alpha levels going in and 2 coming out. So this measures the source's alpha before converting, warns before the loss and again after it (C7), and says what to do -- rename the source to end in _ca, because the output itself cannot be repaired once the levels are gone.

source is absolute, or relative to the repository, or relative to build.project_root. output defaults to the same name with the other extension, beside the source; a relative output also lands beside it.

The verdict is read off the file that was written, never off the exit code.