anyone else using the Steamworks.NET package from GitHub? While the functionality seems to work fine, I am having trouble in the Unity editor, which crashes randomly since I’ve imported the SteamworksManager.cs script (which is the Facade to the package). Removing this script removes the problem.
Build seems unaffected as far as I can tell, but this is rather annoying. There is no error message in the log; not even the crash reporter comes up; I just get the standard Windows error message (DEBUG/CLOSE).
Is anyone else experiencing this, and -perhaps- knows of a solution?
I ran into an issue where I had a Steamworks call in the parameterless constructor of a class I was serializing. The editor went to serialize stuff, tried to call Steamworks, and barfed all over itself.
@TaleOf4Gamers_1 No, unfortunately there is nothing in the editor log (not the new one after restarting, nor the previous one). I only know it crashed (and didn’t just close) because the Windows error dialog.
@KelsoMRK : Ah, that is interesting. At the moment I can’t think where this might happen in my project, but I will investigate. Thanks!
Hmmm… no, there is nothing before the Crash (just the regular Enlighten “Finished XXXX” which show up every time on bake, I have auto-bake on so it does this after every game run).
I’ve hit “DEBUG” now three times on Unity itself after the crash. Once I got GameOverlayRenderer64.dll as the culprit (which is part of Steam), the other time I got nvwgf2umx.dll (NVidia driver?). The third time I got ntdll.dll. Seems like coincidence.
The issue only occurs after having started the game at least once, so I am guessing that there is some part of the Steamworks API still running which causes the problem.
I tried logging in SteamManager.cs - outside of Unity to avoid caching in the console - but there doesn’t seem to be anything calling the class from the editor. So I think it’s a different case from @KelsoMRK .
Further testing reveals that it is not the Steamworks callbacks either (i.e. registering callbacks in custom code). Whether I register callbacks at all, or do not Dispose() them, does not make a difference.
Okay, this has just taken a surprising turn: When removing all Steamworks.NET code, but launching Unity from Steam (i.e. as an “external program”), it crashes as well in a similar manner.
Did you ever get to the bottom of this one? I have experienced similar issues with random editor crashes when Steamworks.NET is active (I have a compiler define to enable/disable Steam integration).
Would be nice if there was a simple workaround to guard against calls to the Steamworks API when editing (i.e. when Application.isPlaying is false)!
I haven’t found a good workaround for this myself, sorry. I’ve settled for toggling steam support on/off via a compiler define (STEAM_ENABLED), and then doing the bulk of my dev work with the flag turned off to avoid crashes. Wish there was a better way! It looks to be due to the Steam overlay and Unity editor not playing nicely together, judging from the crash reports I’ve been able to look at on my dev machine.
