Manual

Unity projects

--project <folder> (the player) or scene_open (MCP) takes a Unity project folder as the Unity editor saved it. Nothing is exported from Unity: Tassix reads Unity's own files.

What is read

  • Scenes and prefabs: .unity and .prefab YAML, including prefab instances with their overrides, added and removed components, and nested prefabs. The player starts at the first scene in the build settings.
  • Assets by GUID from their .meta files: materials, textures and their import settings (filtering, wrapping, sprites, normal maps), audio, models (FBX, OBJ, glTF) with their meshes and materials, ScriptableObject .asset files, animator controllers and clips, input action assets, volume profiles.
  • ProjectSettings: build scenes (followed by GUID when a scene was moved or renamed), tags, layers and sorting layers, input axes, gravity, the layer collision matrix, the fixed timestep, the product and company names. A project with no build scenes (or none Tassix can read) plays one of its scenes, a menu or main scene if it has one, and logs which; Unity's editor would play the scene that was open last. --scene picks another.
  • Resources folders, for Resources.Load.

How scripts are compiled

The project's scripts (not those in Editor folders) are compiled with the .NET SDK against Tassix's UnityEngine, into the assemblies Unity would make: one per .asmdef (with .asmref folders and references by name or GUID; editor-only, test and unmet-constraint assemblies are left out), Assembly-CSharp-firstpass for Plugins folders, and Assembly-CSharp. The build lives in Library/Tassix/Scripts and is reused until a source, an assembly definition or the engine changes.

Packages: Tassix provides its own Input System, uGUI, TextMeshPro, AI Navigation, Mathematics, Collections, Burst's API, glTFast's runtime API, and URP's and Core RP's runtime API, so scripts that use them compile unchanged. TextMeshPro comes in two builds: projects made with a version before 3.2 (the com.unity.textmeshpro package's version, else Unity before 2023.2) get the one whose first UVs are Vector2s (TMP_MeshInfo.uvs0), as their scripts expect; later projects get Vector4s. The first project a process opens decides, so open another version's project in a new editor. Embedded packages (in the project's Packages folder) compile like the project's scripts; other registry packages aren't compiled.

Precompiled managed plugin DLLs load too. A plugin built against Unity's module assemblies (UnityEngine.PhysicsModule and so on) binds to Tassix through generated forwarding facades. Native plugins don't load.

For code completion against the API Tassix has, open Library/Tassix/Scripts/Scripts.slnx in an IDE after the first compile.

Porting checks

  1. Play the project (cargo xtask run -- --project <folder>) and read the log: compile errors name the APIs Tassix lacks, and warnings name scene content it skipped (an unknown component, an override it couldn't match).
  2. Look the area up in compatibility, and the type in API coverage.
  3. An agent connected over MCP has a port_check prompt that does the same and summarizes what would need changing.

Behavior that Tassix has is meant to match Unity's: callback order, physics and navigation results, numbers to float precision where Unity's are deterministic. The conformance suite records scenarios in Unity and checks Tassix against them; a difference there is a bug.

Saving back

Edits made through MCP save back into the .unity file with scene_save: the original text is patched, so unchanged objects keep their exact text, and edits to prefab instances become overrides that keep the instances linked.

From docs/unity-projects.md in the repository.