Packaged game doesn't use Steam

Hello,
the title says everything. After packaging the game it has no steam which leads to no overlay and the game crashing on steam calls with Fatal Error (no further description). I encounter some warnings while starting up the project for the first time and packaging it, stating that steam would be disabled, but all steam functions work flawless in standalone game.
This is the most detailed version of the error occuring when i starrt packaging:

UATHelper: Packaging (Windows (64-bit)): LogOnline: Display: STEAM: Loading Steam SDK 1.39

UATHelper: Packaging (Windows (64-bit)): LogOnline: Warning: STEAM: Steam API disabled!

UATHelper: Packaging (Windows (64-bit)): LogOnline: Display: STEAM: OnlineSubsystemSteam::Shutdown()

PackagingResults: Warning: STEAM: Steam API disabled!

while packaging and during editor startup just the Warnings get displayed.
note that it states i would be using 1.39 but i am using 1.44.
i am currently completely clueless what else i could be doing to make this work again.

Everything form the documentation and wiki has been done and redone without changing anything.
(except modifying WinPlatform.Automation.cs because i can’t find it…)

i found some similar threads but they all had steam_appid.txt missing or no .dll in packaged build (both exist in the packaged builds i tested).

i am working in a blueprint project with c++ in case that helps determining the problem.
maybe someone here can find a possible problem spot that i didn’t

hoping for the best

~Nestoro

edit: after creating a new project with same etc steam functions and testing it to confirm it works, i compared both projects visual studio sln. i can confirm that they use identical settings there… i am completely clueless where the problem could be.

the .sln includes DefaultEngine.ini Target.cs and Build.cs from the project.

so those are eliminated error sources, as are global settings.

From my understanding, Unreal is using 1.39, so maybe change to that if it’s possible for you.
in the release notes from 4.22, They still have Steam 1.39 as latest supported version.

i’ve changed my version down to 139 (packaging creates the Steamv139 folder as it did with 144 and places the .dll) but the behaviour didn’t change at all…

this does not seem to change anything except the used steam version…
standalone game also still works like a charm, just the packaged one doesn’t has steam overlay and crashes on accessing steam functions…

also all warnings stay as they where with 144

The overlay should work just by enabling the OnlineSubsystemSteam plugin and editing the DefaultEngine.ini if you use the Epic launcher version of unreal.
If you use the Source version, you will need to add the Win32 and Win64 Steamworks dlls to the root of your Project: Engine\Binaries\ThirdParty\Steamworks\Steamv139\Win32 and
Engine\Binaries\ThirdParty\Steamworks\Steamv139\Win64
The tutorials you are following are pretty old though.

Nestoro, have you had a steam connection working at all?
In my project (which is pure blueprint) I put this in defaultengine.ini

[/Script/Engine.GameEngine]
+NetDriverDefinitions=(DefName=“GameNetDriver”,DriverClassName=“OnlineSubsystemSteam.SteamNetDriver”,DriverClassNameFallback=“OnlineSubsystemUtils.IpNetDriver”)

[OnlineSubsystem]
DefaultPlatformService=Steam

[OnlineSubsystemSteam]
bEnabled=true
SteamDevAppId=480

[/Script/OnlineSubsystemSteam.SteamNetDriver]
NetConnectionClassName=“OnlineSubsystemSteam.SteamNetConnection”

Then, I enable the steam subsystem under edit>plugins>online platform. Enable Online Subsystem Steam.

Package and it works( for me). In versions 4.15 or 4.21

What I would do is make sure that works (pure blueprint project) and then add a c++ class and see if it breaks. Then you know it is a C++ problem for sure. I also had the warnings about ‘steam API disabled’ and thought it was not going to work. But it does.

Basically, simplify and add bits gradually until it breaks. That is how I make things work.

Would be interested to hear your results.
cheers and good luck.
Podge.

it does work but not after packaging. as i mentioned the .dll’s exist and also are those for the selected version (i have builds for 144 and 139) but none can access steam. while all can do so before packaging

what u mentioned is everything i did. and the steam connection works. just not after packaging the game. it once worked and i don’t know what could have changed since then.

i opened a new project and implemented all steam functions that are in my main project and there everything works after packaging. i am still encountering those warnings so i can happily ignore them.

edit:
after comparing both projects visual studio sln i can confirm that they use identical settings there… i am completely clueless where the problem could be

Nestoro, so you have a project that packages and works with steam. Now add one C++ actor at a time and see if it breaks.

I had a problem migrating a project from 4.15 to 4.21. It would not behave in 4.21. I got a simpler version of my project that did work in 4.21 and moved parts into it bit by bit until it all worked in 4.21. I never did find what the difference was. I think that sometimes an error of some kind sort of becomes embedded in the project and the only way to clear it out is to refresh by rebuilding. I cannot explain why but it seems to be true.

i already addet the c++ code and executed it in the project… migrating everything will consume a huge amount of time and as far as i can see i can’t migrate settings. fixing it that way will be a enormous effort.
but if that really is the only thing that could help i assume i gotta do it. rip next month

I know it is annoying. But if it works then that is good and the process will not be as bad as you think. It only looks bad because you think it unnecessary but bite the bullet and it will soon be over.
Something has come to mind though. Visual studio has settings to recompile only changes to a project (which saves time normally). Perhaps if the whole thing was recompiled all would come good.
I cannot remember immediately where that is.
Good luck.

well it didn’t took me a month and was indeed less work than expected but still consumed several hours… abandoning the ship was the solution here…