koobas.hobune.stream
Can't call custom Debug class (assembly issue?)
I'm working on an improved Debug console, but am unable to call any methods on it. Here is a simplified version of the class:
using Assets.Editor;
using UnityEditor;
using UnityEngine;
public class Logger : EditorWindow
{
[MenuItem("Window/Logger")]
public static void Init()
{
Logger window = (Logger)GetWindow(typeof(Logger), false, "Logger");
window.position = new Rect(window.position.xMin + 100f, window.position.yMin + 100f, 200f, 400f);
}
public static void Log(string msg)
{
}
}
If I have a class that calls Logger.Log("something"), unity reports that 'Logger' does not exist in the current context. Visual Studio however does not find an error with any of my code. This code will only need to work when in the Unity editor.
So how can I access Logger from standard classes?
Since you guess an assembly issue this class is compiled in a seperate assembly? right? Where do you have this assembly in your project? And where do you try to use it? You know that this is an editor script and therefore can only be used in the editor. The class won't exist at runtime since the assembly isn't included (since it's an editor assembly).
Then how does Unity's build in Debug class work? You can call it at runtime, and results are displayed in a editor window.
Is there any way to communicate between the editor and normal assemblies?
The Debug class is a runtime class. Also all debug logs can be intercepted with Application.RegisterLogCallback or Application.RegisterLogCallbackThreaded at runtime. The editor probably just "hangs in". However keep in $$anonymous$$d that when testing in the editor the editor environment is the actual one.
I've also created a custom logging class (as part of my mobile debug system), but $$anonymous$$e has the exact opposite aim ;) It should work at runtime so i can see all Debug.Logs and my custom logs on screen.
There's no way to directly call / use an editor assembly from runtime. However all editor classes have full access to all runtime classes. You can see the runtime as a kind of subdomain of the editor domain.
Just to explain this in detail:
The editor assemblies are actually loaded in the same domain as the runtime classes when you're in the editor, however the editor assemblies are not included as references when compiling the runtime classes, therefore the compiling fails because the class you're try to use is missing.
In general: All code in runtime classes have to work with only the runtime available. In runtime classes you can use
#if UNITY_EDITOR
//Do some editor stuff
#endif
To use built-it editor functions, but not custom assemblies.
I've converted my comment into an answer ;) (and moved the comments)
I figured out a solution just before you posted, and wrote my own answer (still needs to be approved by a moderator).
It uses a surrogate class in the main assembly that an editor class can access and display the contents of. (Like your answer says can be done)
I was able to get this working using a surrogate class within the main assembly.
A LoggerUI class (Logger in the original question) is in the editor assembly, and cannot be accessed by any other classes.
A static Logger class (The surrogate) is in the main assembly. It has has logging methods, and saves all logs in a list.
The LoggerUI class then calls GetList() on the Logger class every frame (because the editor assembly is able to access the main one), to update and draw the logged lines.
The list is only updated once every frame. Although this will result in good performance (you can call Logger.Log() many times per frame), when the game crashes, the list might not be as up to date as it should be.
I'm not sure what you're after but if you want a logger without any delays you can provide a callback event in your surrogate class to which your editor class can subscribe. Of course if the game and the editor crashes those lines won't be displayed since even Unity's console accumulates logs and displays them only at intervals.
However if you write out your own logfile from the callback it will be updated in realtime. Just make sure that this can be disabled for the release version.
Great idea, I'll probably do something along those lines.
