Skip to content

Logging

Purpose

Owns editor support logging, diagnostics visibility, log routing, and support-report generation.

This territory provides the custom diagnostics console used by Snap Studio Pro and acts as the primary support investigation surface.

Owns

  • Custom diagnostics window
  • Category-based logging
  • Log routing
  • Log persistence
  • Log export workflows
  • Clipboard diagnostics export
  • Support-focused logging controls

Does NOT Own

  • Runtime logging
  • Gameplay diagnostics
  • Rendering diagnostics
  • Preview ownership
  • Export execution

Allowed Dependencies

Logging may depend on:

  • Environment diagnostics
  • Unity editor APIs
  • Shared diagnostics systems

Logging should avoid depending directly on:

  • Rendering systems
  • Preview systems
  • Export workflows
  • Feature implementations

Notes

Logging exists to improve support quality and issue reporting.

The system intentionally captures:

  • categorized logs
  • environment information
  • exported support reports
  • diagnostics screenshots

This territory should remain focused on support tooling rather than becoming a general-purpose logging framework.

Usage & Boundaries

Editor-tool code logs through MyLogger.Log/LogWarning/LogError("<Category>", message). Logging is category-gated and quiet by default — a message only reaches the Console + diagnostics window when its category is enabled, so a shipped asset stays silent until support turns categories on. Categories must come from the MyLogger dictionary (unknown categories are logged once and dropped); ForceLog bypasses gating for critical always-visible breadcrumbs.

Prefer MyLogger over raw UnityEngine.Debug.* throughout the editor tool. Three areas are hard exceptions that must stay on Debug and never call MyLogger:

  • RuntimeKit — runtime gameplay code; it must not reference this editor-only assembly at all (there is no valid asmdef path, and it would ship editor logging into a runtime build).
  • Core and UI assemblies — Diagnostics depends on them, so a back-reference would create an assembly-definition cycle.
  • MyLogger / LoggingWindow themselves — they are the sink; their internal Debug.* calls are how output actually reaches the Console.

Future Candidates

  • Log filtering improvements
  • Support bundles
  • Diagnostic snapshots
  • Exported diagnostics archives