Skip to content

Changelog

2.0.0

Upgrading from 1.1

This is a major version for one reason: if you have your own assembly definition that references LoggerPro, you must add LoggerPro.Runtime to its references. Until you do, it will not compile.

error CS0103: The name 'LoggerPro' does not exist in the current context

The logging API moved into a new runtime assembly so that game code can use it, and Unity assembly references are not transitive — an asmdef listing only LoggerPro no longer finds LoggerPro.Log. Adding the second reference is the whole fix.

Scripts without an assembly definition need no change at all. Both assemblies are auto-referenced, so ordinary scripts keep working untouched.

Everything else is automatic. Your categories and export settings are migrated to ProjectSettings/LoggerPro.json on first load, no namespaces changed, and no API was removed.

If your export or preset folders were still on the pre-2.0 defaults — inside LoggerPro's own folder, where an asset update would overwrite them — they are moved out and the console tells you where they went. Folders you chose yourself are left alone.

New

  • Log from game code. A MonoBehaviour can now call LoggerPro. Entries appear in the console during Play Mode, filtered by the same categories as your editor logs.

Note the change to LoggerPro's footprint that comes with this. Up to 1.1 the package was entirely Editor-only. It now ships a small runtime assembly, and in a player build a LoggerPro.Log call writes to the Unity player log and keeps the entry in a bounded in-memory buffer, capped at 500 entries. The console, diagnostics and exporters stay in the editor assembly and are not compiled into players, no configuration is read or written, and no files are created on the player's machine. Wrap calls in #if UNITY_EDITOR if you want it compiled out entirely. - Logs survive a recompile. Editing a script no longer empties the console, so the reproduce-then-tweak loop keeps its history. Cleared when the editor closes. - Unity's own console is mirrored in, categorised by where it came from — Unity.SomeAssetPack for a third-party folder, Unity.Compiler for build errors. Third-party output, unhandled exceptions and compiler errors are all visible here now. Switchable in Settings. - LoggerProLite, a rebrandable copy of the console you ship inside your own asset, so your users can send you a structured report instead of a screenshot. Reports carry the logs, their categories and timestamps, and the environment: Unity version, render pipeline, scripting backend, colour space, defines and installed packages. Lite needs no reference to LoggerPro and works whether or not the person using your asset has it installed. - Register your own export format. The buttons along the bottom of the console are built from a registry — implement ILogExportFormat, register it, and yours sits alongside the built-in ones. - Dismiss a detection-scanner finding and it stays dismissed, so a rescan before your next release shows what changed rather than everything you already triaged. Each scanner shows what it is hiding, with per-item and bulk restore. - In-editor documentation, as a Help tab in the console — quick start, categories, logging from game code, the report loop, custom exporters — with copyable snippets. - A trash folder. Anything a tool removes goes to _LoggerProTrash/ rather than being deleted, restorable from Tools ▸ LoggerPro ▸ Restore From Trash.

Improved

  • The log list is virtualised, so a full session of logs costs the same to draw as an empty one. Selecting an entry shows it in a details pane with clickable stack frames.
  • Stack traces start at the line you wrote instead of ten frames of LoggerPro's own plumbing.
  • Configuration lives in ProjectSettings/LoggerPro.json, outside Assets — an asset update can no longer overwrite your category list, and it is a readable diff you can commit so a team shares one set of categories.
  • Scanners report progress and can be cancelled, and say how much they examined, so an empty result reads as an answer rather than a failure. The runtime leak scanner and the reload cost estimator complete in a single pass and have no progress to report.
  • Diagnostics tools state what kind of codebase they assume, and warn before a fix writes into a folder you did not tell LoggerPro you own.
  • The unused-script scan no longer reads every asset once per script; a large project that previously appeared to hang now completes. Results are split into what can be proven unreachable and public API with no caller in this project, which for a library is normal.
  • The static memory scanner is folder-scoped and reports what it examined.

Fixed

  • Timestamps in exported reports serialised as year 0001, so every archive came back with no usable time. Now ISO-8601, and imported reports keep their categories.
  • Past roughly 60 categories, a band of them could not be seen or toggled.
  • The console issued a Resources.Load per visible row per frame.
  • An error wrote a screenshot into Assets/ and opened a file browser — every time. Now off by default, rate limited, play-mode only, and it never reveals anything uninvited.
  • Clearing screenshots deleted every .png in the export folder, including your own files. It now matches only the images LoggerPro wrote, and moves them to the trash.
  • Clearing logs left the per-category counters populated, so the caps mis-counted for the rest of the session.
  • The test assembly could not compile.