server_start
Start the DayZ test server and wait until it is ready. Clears stale bridge state, refuses to boot if the game port is held, and returns a job ID.
Instructions
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".
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | ||
| extra_args | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | ||
| data | No | ||
| hint | No | ||
| error | No |