Unity command-line checks¶
Use this page for the basic process. The other-PC setup lists the required Editor and machine-specific details. The Unity stabilization skill has the full workflow for game fixes and test troubleshooting.
Before a check¶
- Inspect the working tree and check whether Unity already has this project open. Do not run two Editors on the same project.
- Use the Editor version in
ProjectSettings/ProjectVersion.txt. The separateunitycommand is a wrapper and may not be installed on every machine. - Capture the package and settings files that Unity may change, as well as the relevant profile and preference files. Use an isolated test profile and avoid real saves and external services.
- Choose a focused check for the change. Follow the owner's direction: agent tests use short configurations, not real stages; further ability behavior testing is manual for now.
Run and record¶
Use the matching Editor or installed wrapper and the relevant check's documented entry point. Some asynchronous Play Mode checks need the Editor launched directly without an immediate -quit; let the check finish and exit. Check the process result and the log, not just a single success message.
After the Editor exits, inspect generated changes and restore only those caused by the run. Record what was checked, its result, and its limits in the relevant test list and task. Compilation does not prove normal gameplay or physical input.
Runtime diagnostics¶
The game has an optional local trace in GameDiagnostics. A build containing this code can enable it with -tinyChaosTrace; messages begin with [TCTrace]. The trace is off by default and stops after 512 ordinary events. It does not cover every ability, enemy or controller event.
For an investigation, record the build, action, approximate time and what happened. A last trace event can help narrow the problem; it does not prove the next operation caused it. Review logs before sharing them, since other log messages can contain sensitive information. See the detailed historical notes for the earlier tracing checks and their limits.
Linux player build and startup probe¶
The historical build and startup record includes an earlier Linux command and its limits. Check current tooling and the intended platform before reusing it. A Linux test build does not establish Windows or Steam behavior.
Earlier checks¶
The full earlier Unity CLI record and numbered stabilization reports are preserved as history. They describe the project at the time and do not establish that the current version passes the same checks.