if I got it right, this library works using Application.RegisterLogCallback. However we use the function already, therefore once we start to use it, I guess the library stops to work.
Can you confirm it? Do you have workarounds?
Unity 5 renamed this delegate to logMessageReceived and fixed the issue of multiple libraries “fighting” over the log callback.
If this library is new i bet it uses the new callback.
I was just about to bring this up! Great minds think alike, I suppose.
I’m super happy that Unity 5 finally fixed the RegisterLogCallback “fighting”, but Unity 4.x users are still kind of up the creek without a paddle.
After taking a quick peek under the hood, I think it would be great if you guys could also expose the Log method that you hook up to RegisterLogCallback. That way Unity 4.x users can make use of the “daisy-chain” method that’s outlined here. They’d just have to register your Log method along with whatever else they have registered, after initializing the service.
The log callback is not exposed in any way that I am aware of.
Also, in case you’re using 3rd party code that registers the log callback it self (and for which you have no control over), even if you did have the reference to the log callback, you wouldn’t be able to change that code to use your new mechanism of registering multiple callbacks.
If you have control over the entire codebase, just have a single log callback registered and have that class expose an event that will allow multiple other classes to register to that (like in the link you mentioned).
Currently, the Log method is not exposed. That’s why I said it’d be great if it could be exposed! It’s currently private – it’d only have to be set to public, and have a separate, new method to just run the initialization without actually hooking into RegisterLogCallback.
You can probably get at it with Reflection, but the Init method does a few other things before registering the callback. I suppose you could probably call Init to initialize, register your own callback (thus overwriting the Crash Reporting one) and then use Reflection to add the Log method to your callback.
I haven’t tried it, but that may work. It’ll be a complete mess, though, and I’d rather not have to resort to Reflection.
Which works great, as long as the Log method for this is made public. 
Howdy! I’d like to echo this statement as well. We’re looking into using the crash logging, but we also use Unity 4.x and can’t have the Unity Crash Logger blowing away our Log Callback, as we require that to dump our Unity logs to disk on iOS/Android/etc.
Any chances we can get a way to override this functionality, or expose the CrashReporting delegate such that we can pass in the exception callstack ourselves? Thanks!
Why can’t you use the RegisterLogCallback delegate ?
Unity 4.x only allows for one thing to register the callback. When another thing comes along and calls RegisterLogCallback, it blows away previous ones. Unity’s LogCallback delegate is private as far as I know; we can’t access it directly.
So what we have is either Unity’s crash logging calls RegisterLogCallback internally, which blows away our RegisterLogCallback delegate, or vice versa, we blow away theirs. Both Unity’s delegate AND the Crash Logger delegate are private, therefore unavailable for us to use directly.
And no, upgrading to Unity 5.x is out of the question at the moment. We’re just a couple months from release and that would be too destabilizing.
It’s not too hard to decompile the library, and add a hook to the CrashReporting class so that you can combine your LogCallback with theirs.
That’s what we did…
We also made it so that we can change the UserId at runtime (i.e. after the user has logged in into our game).
And no, I probably cannot share the code without authorisation from Unity.
1 Like
Why do you need authorization from them ?
Because that’s their code I modified
Decompilation is explicitly against the terms of use. If we’re going to use Unity’s solution and be above board, we need Unity to support our scenario. We haven’t heard anything about this for months, so I’m just going to have to look into different solutions.
I believe this is fixed in Unity 5.x. I wish I had a better answer for our Unity 4.x users.