may be cant run Slay_the_Spire_2

[xinerqu]

Title: Slay the Spire 2 (AppID 2868840) — In-game "launch from Steam" prompt, Steam shows no game running (v1.4.0)

Body:

Problem
Two issues encountered when using uc-online2 with Slay the Spire 2:

v1.2.0
The game displays an in-game error about GetISteamGameSearch — the function is not exported by uc-online2's steam_api64.dll, so Steamworks.NET cannot resolve the entry point.

v1.4.0
The GetISteamGameSearch error no longer appears, but two new issues occur:

The game displays an in-game message telling the player to "please launch from Steam." This is likely caused by the game's own SteamApps()->BIsSubscribedApp() check failing because the AppID is forced to 480 (Spacewar).
Steam does not show any game as running — not even Spacewar. In v1.2.0, Steam would at least show Spacewar as the running game. In v1.4.0, nothing appears in Steam's "now playing" status.

and

uc-online runs well and can multi

[veeeanti]

I'm actually working on this as a separate thing, STS2 is a Godot game and has the appid hardcoded in its files. The issue I have with it is the fact its such a massive game to decomp and recomp to just make a small edit would be too time consuming, as I'd have to go through and fix every compilation error one by one. I'll have it done eventually, I promise.

[xinerqu]

I’ve already resolved this issue and successfully got the game running, and I also published a release on my forked branch. However, I haven’t submitted a PR yet because there’s still more work to do.

Specifically:

The root cause was NOT the hardcoded AppID — the BIsSubscribedApp hook already handled ownership checks.

The real issue was a missing flat API export: SteamAPI_ISteamUserStats_RequestCurrentStats.

Steamworks.NET (C#) calls this function via P/Invoke immediately after SteamAPI_Init in order to load stats and achievements.

Since uc-online2 did not export this function, the C# side threw an EntryPointNotFoundException, which was then caught by the game’s exception handler.

Fix:
I added the missing export to api_flat.h.

This function was removed from newer Steam SDK versions because stats are now managed automatically by the Steam client. Therefore, the implementation simply returns k_uAPICallInvalid, which effectively tells Steamworks.NET that the data is already ready and no asynchronous loading is required.

This fix will likely benefit all Steamworks.NET-based games, including Godot, Unity, or basically any C# game using Steamworks.NET.

[veeeanti]

You're truly a lifesaver, not once did I think about that when I was working on updating the SDK. I can't thank you enough, and whenever you are ready just send the pr through. I don't get notifications for issues for some reason, sorry for missing these.

[xinerqu]

Hi veeeanti,

First of all, thank you for merging PR #6 — really appreciate it! 🙏

Since opening that PR, I've continued working on the fork and made several rounds of improvements across v1.6.0 → v1.6.2 (which were also pulled into the merge):

v1.6.0: Fixed Godot/Steamworks.NET games crashing due to missing RequestCurrentStats flat API export
v1.6.1: Added local filesystem fallback for FileRead/FileExists to handle save data persistence when Steam Cloud doesn't sync properly
v1.6.2: Added Facepunch.Steamworks compatibility with missing ISteamAppList flat API exports and fixed GetISteamAppList initialization path
These changes have helped get a few more games running that previously wouldn't work at all, which feels like good progress.

However, I've also run into a couple of issues I haven't been able to solve yet:

EOS-integrated games — notably AppID 3481020 (a UE5 title using EOS + Steam) fails to establish online sessions. I suspect the issue is on the EOS side rather than the Steam API layer, and I have a feeling most games with EOS integration will run into similar problems. Still no clear idea on how to approach this.

Game overlay rendering — some games have trouble displaying the Steam overlay correctly. The overlay seems to load but doesn't render properly, which affects things like inviting friends or using the in-game overlay features.

Just wanted to share where things stand and see if anyone else has run into these. Thanks again for maintaining this project — it's been a great foundation to build on, and I've learned a lot from the codebase.

[veeeanti]

I'm having nothing but trouble with getting things to run on my end, it initializes steam obviously as I can see my status turn green and show I'm playing whatever appid I set, but the game never runs or it fails to run.

One such case is with Half-Life / Deathmatch Classic / Ricochet / all GoldSrc games, it fails to run the game due to the fact that it doesn't have the filesystem interfaces that GoldSrc expects or what the filesystem_stdio.dll expects, and I'm wondering if it's due to me splitting the dll into two - the main steam_api and then the core "client" dll. Please, if you can get in touch with me better, add me on fluxer - my username is veeanti#4047 - or if you need me to add you on something you use, I'll be more than happy to sign up for it to better communicate with you on this.

[veeeanti]

I know why it's failing on goldsrc games now. It's because of my modifications I made to the basedir (valve) folder, I put everything in a pak0.pak file (how it shipped out long ago back in '98 on CD-ROMs) to cut down on download times due to the massive amount of loose files. I'm going to retest it with an exrtacted Half-Life game and find out.

[xinerqu]

Early Valve games were not designed to run by simply launching the executable directly.
They require the Steam environment to be initialized first.
So the game must be launched through Steam, because Steam prepares things like:
required launch parameters
interface initialization
mounted game resources
If you launch the EXE directly, those parts are missing, so the game may fail to start.even with a legitimate copy of the game.
Also,So I probably won’t have much free time recently. Sorry about that.
Actually, I personally prefer uc-online1 because it’s simpler. I even made some modifications to it before, including support for changing the AppID and implementing OGAPPID for the overlay. But of course, it still couldn’t achieve more advanced functionality.
Following your ideas, I also experimented with a lightweight proxy DLL approach, where my own DLL only handled feature logic and function forwarding while still loading the original DLL underneath. And honestly, I received a lot of help from AI during the process.
I really hope the uc-online2 project keeps improving and becomes even better.

[veeeanti]

If you launch the EXE directly, those parts are missing, so the game may fail to start.even with a legitimate copy of the game.
Also,So I probably won’t have much free time recently. Sorry about that.

The 25th anniversary update fixes things like that, mainly the launcher exe being able to be renamed to the mod folder's name to launch it directly (Blue Shift > bshift.exe, Counter-Strike 1.6 > cstrike.exe). Surprisingly, v1.2.0 of uc-online2 works flawlessly. I need to backtrack and see where things went wrong. Not only was it likely failing due to the botched filesystem (also the fact i was generating bad pak files) but it's likely due to some other stuff i didn't account for. Maybe if I want to split the dll into two, i can use steamclient as a proxy to do what I need to do and then pass it off to the real dll.

I believe I remember merging it! I do apologize for how overcomplicated I made the initial repo with the numerous branches, I'm hoping to clean it up and make it much more organized and easier to read through.

I hope it does as well, maybe third time will be the charm and uc-online3 will be the solution to every trouble had with 1 & 2!