LoggerPro¶

A console for the tool you are building, and a way for the people using it to send you what went wrong.

Most of this is also in the editor, under Tools ▸ LoggerPro ▸ Console, in the Help tab. That version has buttons that do the things described here. This one is for reading on a screen that is not Unity.

Requirements¶

Unity 2022.3 LTS or newer. The package is built with Unity 2022 LTS, and verified to import with no errors and no warnings on both 2022.3 and Unity 6.

No third-party packages. Nothing here is pipeline-specific either — LoggerPro ships no shaders, materials or renderer components, so it does not care whether the project is Built-in, URP or HDRP.

Start here¶

There is no setup step. No asset to create, no prefab to drop in a scene, no scripting define.

using RevGaming.LoggerPro;

LoggerPro.Log("MyTool", "Import finished");
LoggerPro.LogWarning("MyTool", "character_armour.fbx has no UV2");
LoggerPro.LogError("MyTool", "Could not write to Assets/Generated/");

Open Tools ▸ LoggerPro ▸ Console. A MyTool category is already in the list on the left, already enabled. Untick it and those messages disappear.

Six severities are available: Log, LogWarning, LogError, LogSuccess, LogDebug, LogTrace. Each takes an optional UnityEngine.Object as a third argument, which the console can ping.

Categories¶

A category is a label you attach to a log so you can turn it off later. That is the whole idea, and it is the reason this is a console rather than a list.

You invent them. A category does not need to exist before you use it — the first log creates it, enabled.

Dots group related ones. There is no hierarchy; MyTool.Import is just a name. But sorting puts them together, and it reads well in a report someone sends you:

LoggerPro.Log("MyTool.Import", "Reading source/character_base.fbx");
LoggerPro.Log("MyTool.Export", "Wrote 12 assets");

Register up front when you want a category off by default, or listed before anything has been logged:

LoggerPro.RegisterCategory("MyTool.Verbose", enabled: false);
LoggerPro.RegisterCategories("MyTool.Import", "MyTool.Export");

Re-registering never overwrites a choice someone has already made. RegisterCategory on an existing category leaves its enabled state alone.

Where they are stored¶

ProjectSettings/LoggerPro.json — outside Assets, so updating LoggerPro cannot overwrite them, and outside player builds. It is a readable diff, so commit it and your whole team shares one set of categories.

Nothing about LoggerPro's configuration lives inside the package folder. That was true before 2.0 and it cost people their category lists on every asset update.

There is a second store, and it behaves differently. The capture switches, the per-category cap, screenshot-on-error, your search text, category filters and severity toggles live in Unity's EditorPrefs — which are per user and shared across every project on this machine. Changing them here changes them everywhere.

That is deliberate. Those are view preferences rather than project configuration, and one console that behaves the same way in every project is what most people want. But it does mean two projects on the same machine cannot disagree about them, so if you need a lower cap in one project than another, you cannot have it. The Settings tab says the same thing next to the controls themselves.

The exception is the version-change notice, which is keyed per project — switching between two projects on different LoggerPro versions does not announce a change every time.

Filters and presets¶

The left panel filters what the console shows: categories, severities, and a search box. A particular combination can be saved as a preset — Tools ▸ LoggerPro ▸ Presets.

Logging from game code¶

LoggerPro used to be editor-only, so a MonoBehaviour could not reference it. As of the runtime split it can:

using UnityEngine;
using RevGaming.LoggerPro;

public class Spawner : MonoBehaviour
{
    void Start()
    {
        LoggerPro.Log("Spawner", $"Spawning {count} enemies");
    }
}

These appear in the console during Play Mode, alongside your editor logs, filtered by the same categories.

What happens in a player build¶

The calls still work. LoggerPro.Log writes to the Unity player log and keeps the entry in a bounded in-memory buffer, capped at 500 entries across all categories.

What does not happen in a build: no console window, no configuration is read or written (ProjectSettings/ is an editor concept and is not consulted), no files are created anywhere on the player's machine, no screenshots, and none of the diagnostics or export code is present — it lives in the editor assembly, which is not compiled into players.

So the runtime cost is a small assembly and a capped list, not zero. If you want LoggerPro compiled out of a build entirely, wrap your calls:

#if UNITY_EDITOR
LoggerPro.Log("Spawner", $"Spawning {count} enemies");
#endif

Getting reports from people using your asset¶

This is what LoggerPro is actually for.

LoggerProLite is a small, rebrandable copy of the console that you ship inside your own asset. Your users get a console for your tool, and a Send Report button that produces one file describing what happened.

A report carries the logs with their categories and timestamps, plus the environment: Unity version, render pipeline, scripting backend, colour space, defines, and the installed package list. The questions a support thread normally opens with, answered before you reply.

Tools ▸ LoggerPro ▸ Lite Integration ▸ Prepare Lite For My Asset generates a copy branded for you — your namespace, your assembly name, your menu path — so two assets that both ship Lite cannot collide.

Lite does not need LoggerPro installed to work. If LoggerPro is present, Lite finds it at runtime and routes through it; if not, Lite stands alone. Your users never see a missing dependency.

To read a report someone sends you: Tools ▸ LoggerPro ▸ Import Report.

Adding your own export format¶

The export buttons along the bottom of the console are not hard-coded. Register a format and it appears alongside the built-in ones — which are registered exactly the same way, so anything they can do, yours can.

using System.Collections.Generic;
using UnityEditor;
using RevGaming.LoggerPro;
using RevGaming.LoggerPro.Interfaces;

[InitializeOnLoad]
static class JiraExportInstaller
{
    static JiraExportInstaller()
        => LoggerProExportFormats.Register(new JiraExport());
}

class JiraExport : ILogExportFormat
{
    public string Id => "mystudio.jira";       // namespace it: "mystudio.jira", not "jira"
    public string DisplayName => "Send to Jira";
    public bool IsAvailable => true;           // false hides the button

    public void Export(IReadOnlyList<LoggerProLogEntry> logs)
    {
        // the entries are handed to you; do whatever you like with them
    }
}

Registering the same Id twice replaces rather than duplicating, which is what makes [InitializeOnLoad] safe — it runs again on every recompile. It also means you can override a built-in format by claiming its id.

The older ILogExporter still works and is still wired to ILoggerProContext.Exporter, but ILogExportFormat is what to use for anything new.

The Diagnostics tab¶

Scanners that look for what breaks an editor tool once it is installed in somebody else's project: leaked statics, update hooks that never unsubscribe, asmdef mistakes, missing [Serializable], orphaned files. They were written to get LoggerPro itself fit to ship.

They will scan anything you point them at — other people's assets, your whole project, LoggerPro itself. Nothing is filtered out, and a scan that flags LoggerPro is reporting something real.

Two things worth knowing:

• Several checks are heuristics. A finding is a lead to confirm, not a defect proven. Aimed at gameplay code rather than an editor tool, some of them report normal code as a problem — statics reset on entering play mode, editor callbacks do not exist in a build, and a library's public API has no caller inside its own project. Each tool states what it assumes.
• Some tools modify files. Settings ▸ Folders I Own tells LoggerPro which folders hold your own code, so it can warn before a fix reaches into an asset you bought rather than one you wrote. Anything removed goes to _LoggerProTrash/ rather than being deleted, and can be restored from Tools ▸ LoggerPro ▸ Restore From Trash.

Things that are easy to miss¶

Your logs survive a recompile. Editing a script no longer empties the console, so the reproduce-then-tweak loop keeps its history — and a report sent after a recompile is not silently empty. Logs are discarded when the editor closes.

Unity's own console is mirrored in. Third-party asset output, unhandled exceptions and compiler errors are captured and categorised — Unity.SomeAssetPack for a third-party folder, Unity.Compiler for build errors. Switch it off in Settings if you would rather not.

Stack traces are clickable. Selecting a log shows its frames in the details pane with an Open button per frame. LoggerPro's own plumbing frames are trimmed, so the trace starts at the line you wrote.

Error screenshots are opt-in and off by default. When on, they are rate limited to one per ten seconds, play-mode only, and never reveal themselves in a file browser unless you ask.

Assemblies¶

Reference LoggerPro.Runtime from a runtime assembly definition to log from game code. Both are auto-referenced, so code without its own .asmdef needs no setup at all.