Fallback handler could not load library about steamworks.net HOT 20 CLOSED

Try this: move steam_api and steam_api64 dlls next to your executable. Then it should work.

from steamworks.net.

This looks more like the common wrong fallback handler spam as for example discussed here: http://forum.unity3d.com/threads/native-plugin-not-found-on-standalone-player-windows-x86.326868

I.e. the fallback handler stuff could be ignored but looks like it is actually missing a dependency of CSteamworks.dll. Did you put the steam_api.dll (or steam_api64.dll) in the root folder of the game? Eventually it also requires tier0_s.dll and vstdlib_s.dll (or their 64 bit counterparts), haven't tested that in a while.

from steamworks.net.

steam_api64.dll is in my root folder. It occurred to me, could the problem be that I have steamapi64.dll, not steam_api.dll in my root folder, and in my build settings I'm selecting x86 architecture? Where do I find, and how can I configure tier0_s.dll and vstdlib_s.dll, this wasn't mentioned in the setup procedure to my knowledge.

from steamworks.net.

I'm not sure whether it was SteamAPI that required those additional libraries or only Steamclient.dll. No matter what you can get all of them from a normal Steam installation.

Regarding the API: It has to be named exactly steam_api(64).dll (including the underscore) and it has to match the Unity build type (32 / 64 bit).

from steamworks.net.

Hey guys I'm looking into this right now, it seems like Unity went and mucked things up in 5.1 :(

The good news is it seems like the steam_api[64].dll no longer has to be in the project root to run in the editor. Having it in Assets/Plugins/x86[_64]/ next to CSteamworks.dll works fine now! Unfortunately it does not work that way when building the project...

from steamworks.net.

EDIT: I hadn't updated in the SteamManager the SteamAPI.RestartAppIfNecessary(AppId_t.Invalid)) line to include my AppId. I did this, now, if I launch from my desktop it works (although it clearly restarts the app). If I launch from my content folder (where I then upload to steam) it crashes. The location of the files clearly seem to have something to do with this. It seems that the restart is triggering, and then not working correctly. Any ideas?

from steamworks.net.

No idea, but the player's log file and a listing of both working and failing directory trees may be helpful. On the other hand Riley might have an idea without that information, I'm just a user of this stuff too ;)

from steamworks.net.

Uploading to steam, then downloading through the client to the following location results in a crash:
C:\Program Files (x86)\Steam\SteamApps\common\Quadrant\quadrant_Data\Plugins
(note that CSteamworks.dll, steam_api.dll, and steam_api64.dll are all in this location)

Running directly from my desktop however, at C:\Users\Eden\Desktop\quadrant_Data\Plugins works without error (same files are present).

Specifically, when placed on the desktop it gets to the screen where I load the Steam Manager, triggers a restart, I assume via this code detection: if (SteamAPI.RestartAppIfNecessary("MYAPPID")) {
Application.Quit();
return;
}
Then it runs fine. When loaded from any other location (then where it was compiled on the desktop, it gets to that step and then just quits, and does not reload.

Is there an absolute path specified somewhere that needs to be made relative? Where is the player log file, I'm aware of output.txt, which is what I pasted above? Any general troubleshooting ideas?

from steamworks.net.

Is there a known issue associated with this? I'm not sure what to try next to troubleshoot.

from steamworks.net.

I am also encountering this problem. It only occurs on my windows machine, not my Mac. Has anyone found a solution yet?

from steamworks.net.

Never figured this out, I still want to integrate steamworks.net but am awaiting a suggestion on this thread.

from steamworks.net.

I was having this same issue, and realized that it was because I still had steam_appid.txt in the same directory as the game's executable - but you are only supposed to have that during development.

I also noticed this comment in the function RestartAppIfNecessary in Steam.cs:
return false if your executable was started through the Steam client or a steam_appid.txt file
is present in your game's directory (for development). Your current process should continue.

So for me, because I had steam_appid.txt, RestartAppIfNecessary was returning false, which meant that the code to stop the game, start Steam, and relaunch the game would never be run.

Maybe you're having the same issue?

from steamworks.net.

Cool, glad that you guys are getting it sorted. I just pushed out a new release which should clear this up quite a bit.

https://github.com/rlabrecque/Steamworks.NET/releases/tag/7.0.0

from steamworks.net.

This issue was just closed, I updated to 7.0 and had the same issue, I ended up moving the steam_api next to the executable and it seems to be working. That's good news, but I thought I should mention it, perhaps the documentation could include a reference to this.

from steamworks.net.

Whoops, yep, you're completely correct, minor error at the last minute. Fixing it right now.

from steamworks.net.

Given that it's been out for such a short amount of time, hasn't been announced yet and only affected an editor script I just bundled the fix right into 7.0. Redownloading the unitypackage or latest zip should have this resolved now.

The steam_api.dll should automatically move itself next to the executable again.

from steamworks.net.

Fantastic, thanks for this amazing product, very helpful, looking forward to digging into more of the features now that it is up and running.

from steamworks.net.

@rlabrecque - seems that Unity 2017 doesn't copy the steam_api64.dll to the exe directory anymore.

from steamworks.net.

It shouldn't be required there anymore, Unity as of 5.3 or so can load dependent DLL's from the %GameName%_Data/Plugins/*/ folders.

That being said, I'm currently removing CSteamworks completely, so the next few git master commits might be slightly unstable, but hopefully should get rid of a lot of this sort of mess.

from steamworks.net.

That seems to be correct, however, the only dll that was copied into the plugins folder of the build was CSteamworks.dll, the steam_api64.dll did not copy over and I had to move it manually.

from steamworks.net.