Topic: ENGINE PLUGIN: AGSteam v3.4 (Windows; Linux; Mac OS X)

[monkey0506]

I realized there were some issues with the changes I made converting "AGSteamStub" to "AGS2ClientStub", but even after I corrected those and rebuilt the stub with the "v141_xp" toolchain, the stub still crashes with the exact same error. Based on the fact that "AGSteam-debug.exe" is running perfectly on Windows XP while both the AGSteam plugin and the stub plugin are resulting in a crash, I really feel that this is an error in the way that AGS is loading the plugin, possibly related to the fact that the plugins are built against a different VC++ runtime (despite static linkage, which is meant to prevent this kind of failure).

[Radiant]

Ok, so if I understand you correctly, AGS3 games using any kind of plugins will no longer run under Windows XP. Is that correct? Given that XP is fifteen years old by now, I'm actually ok with telling people to do an upgrade, since we now know what's causing it. Thank you both for looking into this issue.

I don't suppose it would help to build the plugin against the same VC++ runtime as the AGS main executable?

[Crimson Wizard]

I'd say more investigation may be needed. If no plugins were working on Windows XP we would receive reports earlier. That's not hard to test couple of existing plugins too.

Then maybe use some dummy plugin to debug the issue, like stub plugin (which is open source?).

[monkey0506]

Then maybe use some dummy plugin to debug the issue, like stub plugin (which is open source?).

You might have misunderstood my most recent comments above, but I did actually test this with the stub. The stub does nothing more than register itself with the engine's plugin API. All of the functions are no-ops. But when built with Visual Studio 2017, using the "v141_xp" toolchain, the AGS engine fails to initialize the stub with the exact same error message.

Ok, so if I understand you correctly, AGS3 games using any kind of plugins will no longer run under Windows XP. Is that correct? Given that XP is fifteen years old by now, I'm actually ok with telling people to do an upgrade, since we now know what's causing it. Thank you both for looking into this issue.

I don't think it's "any kind of plugins", but I think it must have something to do with the VC++ runtime and the way the AGS engine is loading the plugins. My suspicion is that the engine is somehow expecting the plugin to have the same VC++ runtime libraries as it uses itself. I don't know if this is a limitation of the engine or the way it invokes the plugin functions, but it has always been my understanding that external libraries should be allowed to link against a different C++ runtime, so long as that linked runtime is available (which is the case, due to static linkage).

I don't suppose it would help to build the plugin against the same VC++ runtime as the AGS main executable?

I will have to reinstall VS2008 to test this, but I will see what I can find out. (P.S. As an aside, I noted above that I had mucked some things up with the configuration settings of the stub when renaming the project (namely, when using the stub for "disjoint" builds, which I forgot to test). The stub should be able to build against VS2008, and I will upload relevant binaries and source once I'm sure that everything is working there properly.)

[monkey0506]

I can confirm that the issue is related to the VC++ runtime. Building the stub with VS2008 makes the game playable on Windows XP without Steam achievements. The AGSteam project itself is not currently compatible with VS2008, but I can see about adding the same compatibility measures used by the stub.

The stub download links have been built with VS2008 and work on Windows XP with AGS 3.3.0 engine. It also loads with the AGS 3.4.0-p4 engine, but the mouse goes absolutely insane and is unusable.

[eMTe]

Thank you all for the efforts.

So, where does it leave me, because the talk got too technical? Is it doable to make HQ working under XP, I mean of course it's doable, but is the workload/time/purpose ratio acceptable, like adding few lines of code or is it an absolute waste of time?

Especially with me being the only user reporting the issue.

[monkey0506]

Okay, so this build of AGSteam (built using VS2008) loads on WinXP without crashing, but I don't seem to be getting the Steam API to initialize. This is a release build, not a debug build, so it doesn't include any debug info about what result is returned by the call to initialize Steam. Effectively, it's functioning the same way as the stub at the moment, which is to say that the game is playable, but you won't get Steam achievements.

Technical discussion: I think there may have been some misunderstanding on my part regarding how C++ assemblies with differing ABIs can communicate. And while the core functions are all implemented as free functions, it's possible that they are being mangled in some unexpected way between the different VS versions, or that there is some other ABI incompatibility (probably the changes in the STL would make the ABIs incompatible, I might think). Based on this thread on Stack Overflow, I have some hope that perhaps forcing the DLL exports to use the C ABI instead could solve the runtime issues, though I'm honestly not sure about this. I'll look into porting the stub to the C ABI and see if I can get it to load that way when compiled from VS2017. If I can't, then I'll probably just call it all a wash and only maintain project files for AGSteam (etc.) that match the current AGS project files' VS version.

Edit: Unfortunately, even with every single free function marked as extern "C", the AGS engine is still crashing when trying to load the VS2017 plugin from WinXP. I even went as far as wrapping every single entire file in an extern "C" block (sans #include lines), to absolutely no avail.

[monkey0506]

I've managed to track this down to the use of "static" variables inside functions. STL, free, and class functions are all working, until it encounters a static definition inside a function. Using the more traditional approach of static struct/class members with external storage defined in a .cpp file works. It will take a short time to port the code, but it seems that I should be able to get this fully working on XP.

[Radiant]

Wow, I'm impressed! That's some serious code puzzling there

[monkey0506]

Huh... Actually, I think that the plugin I linked above is initializing the Steam API, it's just not showing the Steam Overlay. Which is also the behavior I'm now getting with the VS2017 plugin. I'll investigate the overlay issue, but if nothing turns up soon then I'll just push up a new build with the fixed VS2017 code.

Edit: The Steam overlay works with the 3.4.1-b7 engine on Windows XP under D3D9 and OpenGL, but not software renderer. Oh, and it crashes with a segfault when I close the window via the red 'X'. Not sure if that's related to the plugin, nor if it would cause crashes during playing. Oh boy.

[Radiant]

Latest builds

There was an issue reported by Dave Gilbert that has been patched in this version, but I got distracted before I updated links and such. This is only the "unified" build (use "AGS2Client.Function()" instead of "AGSteam.Function()"), but I can make sure that the "disjoint" build is uploaded as well in case you're using that. The issue Dave reported may have been the same one regarding a null pointer, which would occur if Steam failed to initialize (namely, if Steam wasn't running).

I will make sure that GetCurrentGameLanguage is added back to the plugin(s).

Edit: As of this writing, I am uploading the latest builds, which have GetCurrentGameLanguage added back in.

Aside from the above, there appears to be an issue with your latest version of the Steam plugin (the one from the quoted post). Specifically, it prevents the game from accepting keyboard input, when ran from Steam. If I log out from Steam and run the game directly from Windows, it works normally. Earlier versions of the plugin did not have this issue.

[Problem]

I can confirm this bug - I've updated to the latest version of the plugin, and people are reporting keyboard issues. I can't reproduce it myself though.

[Neo_One]

What i have to do to use this plugins? There are 4 .dll files.
My game will not have achievements or cards, just i want put in Steam the game. What should do i?

[Neo_One]

Edit: OK, i have found https://bitbucket.org/monkey0506/ags2client/wiki/Using_the_plugin_interface#markdown-header-setachievementachieved
I forget the answer of other user about . I don't have to use the plugin to sell the game in Steam.

[Radiant]

Aside from the above, there appears to be an issue with your latest version of the Steam plugin (the one from the quoted post). Specifically, it prevents the game from accepting keyboard input, when ran from Steam. If I log out from Steam and run the game directly from Windows, it works normally. Earlier versions of the plugin did not have this issue.

Hi Monkey, I was wondering if you had some time to look into this? I would like to upgrade to the newest version of AGS2client but I'm stuck with the old one because of this keyboard bug. Thank you for your time!

[monkey0506]

Aside from the above, there appears to be an issue with your latest version of the Steam plugin (the one from the quoted post). Specifically, it prevents the game from accepting keyboard input, when ran from Steam. If I log out from Steam and run the game directly from Windows, it works normally. Earlier versions of the plugin did not have this issue.

Hi Monkey, I was wondering if you had some time to look into this? I would like to upgrade to the newest version of AGS2client but I'm stuck with the old one because of this keyboard bug. Thank you for your time!

Hi, sorry about that. It was a breaking change I introduced due to my own misunderstanding. Dave actually had asked me recently about the same, and I realized what the issue was. I'm doing some refactoring of the code currently, but I'll push up a new build with the fix.

Edit: Fixed build v3.3 should be available via Github. There's no binary for the Linux builds yet (but the Code::Blocks project for Linux is provided; never got around to authoring a Makefile from scratch).

[Radiant]

Ok, that appears to fix the issue, thank you. I'll be using the disjoint version for now, to keep the game in sync with the Linux build.

[Radiant]

A windows XP user reports that using the previous version of the plugin fails with an unresolved import error, whereas the current version aborts with "An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x100011BC ; program pointer is -23, ACI version 3.3.0.1162, gtags (0,0)"  We can probably get a dump file if you think that helps.

[Radiant]

Could someone please advice me on how to add the Steam plugin to an OSX game in xcode?

[monkey0506]

The latest version 3.4 now includes Mac OS X ".dylib" files! OS X support is in beta as I don't (currently/yet) have a means to test it myself with real games. However, I don't foresee issues as it is built using Code::Blocks in a nearly identical way to the Linux ".so" libraries.

The Windows and Linux builds are also now bundled with the appropriate version of the "steam_api".

Edit: Was able to test this over the last couple of days and everything seems to be working. I've also written a Makefile! I will push up the Makefile to the git repo and update the Mac download link ("libagsteam.dylib", blast it!).