LoggerPro — Runtime (the part that ships in your build)¶
Everything else in this package is editor-only. This assembly is not.
LoggerPro.Runtime.asmdef sets "includePlatforms": [] — no platform restriction — because this is the half your game code calls, and game code compiles into players. When you call LoggerPro.Log(...) from a MonoBehaviour, this is what answers.
That makes this folder the one with the sharpest constraints in the package.
What it means for 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 — that is the editor assembly
- No configuration read or written.
ProjectSettings/is an editor concept, and both the read and the write are gated onApplication.isEditor - No files created anywhere on the player's machine
- No screenshots, no diagnostics, no exporters
So the cost is a small assembly and a capped list, not zero. To remove it entirely, wrap your calls in #if UNITY_EDITOR.
The root README used to say "nothing ships in your build". It was wrong, and it is the reason this folder now documents itself: a buyer with a no-logging-in-release policy was getting a confidently incorrect answer from the first file they opened.
The rules this folder lives by¶
It cannot reference the editor assembly. Unity assembly references point one way, and pointing this one at the editor would drag the console, the diagnostics suite and the exporters into every player build. Anything genuinely editor-side is reached through LoggerProHooks, which the editor installs on load and which degrades to doing nothing when nobody has.
Unity APIs here may be called from any thread. The headline feature is logging from game code, and game code has loading threads, workers and jobs. Two things stay main-thread only however carefully the rest is locked — ScriptableObject.CreateInstance, which builds the configuration on first touch, and EditorPrefs, which supplies the per-category cap — so LoggerProMainThread warms the store before the first scene and the cap is reused off-thread rather than re-read. The log store and the category map are both locked.
Public interfaces here are implemented by third parties. ILoggerStorage and ICategoryManager are documented as injectable services, so a member cannot be added to either without breaking everyone who implemented one. Where a shipped implementation needs to do more — removing a category, stamping an entry with the time it was emitted — the extra method goes on the concrete class and callers check the type.
Folders¶
| Folder | Purpose |
|---|---|
Core/ | The LoggerPro facade, the log entry and severity model, configuration types, the store behind ProjectSettings/LoggerPro.json, and the seams other assemblies bind to |
Shared/ | DevLog, the service that routes a log, the formatter, and the configuration providers |
Category/ | CategoryManager — registration, enabled state, and the name-to-index map |
Storage/ | The in-memory store: deduplication, per-category and global caps, eviction |
Interfaces/ | The injectable seams — storage, formatter, exporter, categories, context |
Common/ | Cross-cutting helpers: the echo guard, main-thread detection, stack-trace trimming, warn-once |
Migration/ | The one-time move of configuration out of the package. Runs once, against real user data |
Where to start reading¶
Core/LoggerPro.cs— the facade, and every entry point game code usesShared/LoggerService.cs— what one log call actually does, in orderCore/LoggerProStore.cs— where configuration lives and how it is written safelyStorage/InMemoryLoggerStorage.cs— dedup, caps, and why eviction is by last-seen time