Why is SteamAPI always initialized?

[tkunze]

in my program i disabled to inizialize steam as shown below:

 

//Initialize Steamworks (optional)

/*if (!Steamworks::Initialize())

{

System::Print("Error: Failed to initialize Steam.");

return false;

}*/

 

However i see the following error messages in the debugger:

 

[s_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.

[s_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.dll.

 

If my steam client is running i get the steam community message inside my window, so it is obviously connecting.

 

How can i get rid of this?

 

I did not bought my version trough steam.

 

Thanks in advance

[YouGroove]

All LE3 version are tied to Steam unfortunatelly, you don't have choice.

[Admin]

You do not need to initialize Steam, but there might be something else going on there the DLL does automatically. The reason for this is we don't want to double the number of build we have to provide for Steam and non-Steam versions, as it would slow down every release.

[Ma-Shell]

I think, you can disable most of the effects by removing the steam_appid.txt

[tkunze]

@Ma-Shell

 

Your're right - removing the steam_appid.txt will disable Steam, but the starting time was dramatically longer and the program loaded and unloaded the steamclient several times.

 

@Admin

 

i understand the point, that it will impact the development cycle. But i ordered a NON STEAM version of the product. The move to steam seems to be an important step for you company, however i heavily dislike, that every program i build using LeadWerks connects to Steam and i have no influence on this.

 

And it should not be too complex to solve this using a DEFINE in the code.

 

Picture: Steam client in the created Executable

[Josh]

I'll see if there is a way to prevent the loading attempt. I really don't want to double the number of builds, because it is guaranteed to produce more bugs and less frequent updates. The engine already uses a __STEAM__ preprocessor definition, but it's not a one-time thing I do. We're talking about doubling the time spent on an ongoing maintenance task. Options are bad, because they quickly escalate.

 

Your screenshot looks cool, BTW.

[miko93]

As I understand, Run-Time Dynamic Linking might do the trick. Only load the dll if Steamworks::Initialize() is being called.

No need to distribute the steam dll with the engine at all if someone's app doesn't use steam.

 

All the dll's exposed function call addresses need to be manually retrieved from the dll at runtime, tho (DependencyWalker shows about 59 of them)...

 

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686944%28v=vs.85%29.aspx

[miko93]

Just for the fun of it, I played with this dynamic loading idea a bit more. My current WIP can be seen here: http://www.mikoweb.eu/tmp/LoadSteamDll.cpp (it is a console app already retrieving several of the dll's entry points - yet not all).

 

By now, I believe that directly loading the dll and getting all the proc addresses run-time is not really the way to go. To get all the interfaces and inline code straight, one would probably need to include many parts of the steam header files - which is doubtable in terms of copyright imo. Also, it would be a mess when the Steam SDK is being updated.

 

What I currently think about is a stub dll, compiled with the Steam SDK as-is. Now this dll would only be loaded run-time if Steamworks::Initialize() is being called. And it would only expose the Leadwerks Steamworks functions. After all, LW is encapsulating the Steam API anyway...

 

Just FYI...

[miko93]

Actually, I have a stub dll test case in place now. Got me the SDK and linked it with a dll which in turn is loaded dynamically at runtime now (or, well, not - as one prefers).

 

During testing, I noticed that the steam.dll keeps rather passive, as long as the SDK's SteamAPI_Init() isn't called. So, to me, it seems Leadwerks invokes the SteamAPI_Init() not only during a call of Steamworks::Initialize (what I was assuming), but always. If this is correct, some remedy could be achieved by moving the call to Steamworks::Initialize and only execute on demand. No need to fiddle with steam_appid.txt etc then, if a user doesn't call Steamworks::Initialize anyway...

 

my 2 cents

[NobbyVedania]

I bought LW yesterday and want to use it as a API for C++ programming alternatively to other previously used open source APIs. I don't have expected any steam constraints and I've assumed that steam connection is only implemented in the steam version not the web shop version. That's very dissapointing to me, because I've wasted 200 $ now for a commercial API that forces me to worry my customer with an steam_api.dll which I can't drop out of the release version of my programs. Unfortunately there is no money back guarantee guarantee on online sales for software.

 

I can only hope that there will be a solution for this issue in the near future or I have to look for another 3D graphics API.

 

I recommend to make this clear in the sales process, so customers can face this issue before they click the buy button.

[Admin]

A newer build is in beta testing that should avoid attempts to connect to Steam, unless it is explicitly called to. It has not made it into the standalone build yet.

[NobbyVedania]

A newer build is in beta testing that should avoid attempts to connect to Steam, unless it is explicitly called to. It has not made it into the standalone build yet.

Thanks for that pleasant and quick information. It should be possible to optionally exclude steam_api.dll from the published release version than I guess (manually not with the publisher of course). I can wait because my project still takes some month to be completed. So I can continue to learn the API and work on the project meanwhile.

 

Another question please: Lua51.dll is been called also in pure C++ apps. Is there a way to avoid the access to this dll when lua is not used?