I’m not getting enough information in the log in order to properly be able to see what is causing this crash.
I packaged the project using debug 64-bit, using separate steam accounts across two machines in different locations (using TeamViewer10 to perform the testing on remote machine). I create a session on the remote machine, can join with client machine perfectly fine, both are dropped in a lobby map where they are both able to chat before starting a game.
From this point forward, if anything happens, steam crashes on the client machine and makes the game hang. Destroying session as client or host will activate this bug, as well as the host doing a ServerTravel for both. During the server travel, the transition map loads perfectly fine on both host and client as well as the destination map. It’s only when the client has finished loading the map that their steam will crash, making the game infinitely hang. The host is completely fine, steam will never crash on their end, even if they destroy session.
I’m using the same steam version on both machines.
It sounds like the Steam client is crashing. Is that correct? If so, you should follow up with Valve.
If the game is crashing, please provide the call stack so we can look into it. Thanks!
That is correct, I’ll try hooking up steamworks v132 and see if that fixes the issue.
The main concern is … the game doesn’t crash, just no longer responds, so no call stack is provided.
Do I need to re-compile the engine for it to recognize v132? Logs keep saying LogOnline:Display: STEAM: Loading Steam SDK 1.30
To upgrade Steam SDK, you’ll need to change the version in a bunch of places, as it is hardcoded at the moment. Look for “v130” (with and without quotes) in the code and change that to “v132”. Then recompile. This is assuming you’ve placed the Steamworks SDK in a manner similar to ours so it will make directories Steavm132 next to existing Steamv130 in Engine/Binaries/ThirdParty/Steamworks, Engine/Source/ThirdParty/Steamworks, etc.
This is a “proper” upgrade. You can also attempt to copy just the steam_api.dll (steam_api64.dll for a 64-bit game) from a newer SDK over the existing one and see if that works.
It would probably be best to see what the Steam client problem is first, as it may be easier. We’re not sure if it matters, but running Steam over a normal session and not a remote one will remove one more unknown from the equation.
A game is not supposed to lock up at any time, but we don’t really test crashing Steam client so we can’t be sure that’s what’s causing the lockup.
So, I’ve tried changing the steam version to the latest 1.32 by following not only the [steps listed here] but also looking for v130 throughout all the system files and changing the references accordingly.
As soon as I try compiling, I get the following errors
Had to revert back to v130 so that the engine may compile again.
What I’ve been doing so far has been taking the redist files from newer steam versions and adding them to the packaged game, but I believe this is causing the issue.
- Using the original v130 dll’s with the latest steam client dll’s seem to allow me to view sessions that are created, use steam in-game, and let me join a session, until someone destroys session or does a server travel, then the client’s steam crashes and completely makes the game hang forever without a crash.
- Using the v132 dll’s with latest steam client dll’s still give me the steam in-game options and overlay, the ability to look for sessions, etc, but now whenever I try to join a session, the client instantly has steam crashing and the game hangs once again forever without a crash. The host sees that someone has connected, along with the details of the person who has connected. The host machine is perfectly fine, steam still running, everything works great.
Given all this, what would you suggest as a possible way to fix this?
Just to re-iterate, this bug only happens on the client, never on the host.
I apologize for the delay, but it looks like we’re working to get 1.32 integrated. This pull request should help in the interim:
Is the integration going to happen in a 4.7 hotfix or are we looking at 4.8?
It will probably be 4.8. Were you able to use the pull request I linked to?
Thanks a lot for the pull, I’ll try it out as soon as I can get this fixed, right now it’s stopping me from being able to package for development.
Okay, I’ll make sure I get someone to take a look at that bug report for you.
Ben, you’re awesome, don’t let anyone tell you otherwise.
It looks like the issue you reported in this other thread has been reproduced and reported, though there’s no word yet on when that will be fixed. For now, I’m going to resolve this post for now for tracking purposes, but if you get to the point where you can try that pull request (or after 4.8 is released and Steamworks 1.3.2 is fully integrated), please feel free to comment here if you’re still experiencing trouble and we’ll keep looking into it. Thanks!