GodotSteam: Crash when game is not owned on logged in account

When logged into Steam with an account that doesn’t own the (unreleased, that might be important?) game, the game crashes when launched from the editor:

Godot Engine v3.2.2.stable.custom_build.6a9fbafcb - https://godotengine.org
OpenGL ES 2.0 Renderer: GeForce GTX 1050 Ti/PCIe/SSE2
OpenGL ES 2.0 Batching: ON

CrashHandlerException: Program crashed
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[0] Steam::steamInit (D:\dev\godot\modules\godotsteam\godotsteam.cpp:294)
[1] MethodBind0R<Steam,Dictionary>::call (D:\dev\godot\core\method_bind.gen.inc:325)
[2] Object::call (D:\dev\godot\core\object.cpp:922)
[3] Variant::call_ptr (D:\dev\godot\core\variant_call.cpp:1127)
[4] GDScriptFunction::call (D:\dev\godot\modules\gdscript\gdscript_function.cpp:1091)
[5] GDScriptInstance::_ml_call_reversed (D:\dev\godot\modules\gdscript\gdscript.cpp:1268)
[6] GDScriptInstance::call_multilevel_reversed (D:\dev\godot\modules\gdscript\gdscript.cpp:1277)
[7] Node::_notification (D:\dev\godot\scene\main\node.cpp:152)
[8] Node::_propagate_ready (D:\dev\godot\scene\main\node.cpp:196)
[9] Node::_propagate_ready (D:\dev\godot\scene\main\node.cpp:186)
[10] Node::_set_tree (D:\dev\godot\scene\main\node.cpp:2574)
[11] SceneTree::init (D:\dev\godot\scene\main\scene_tree.cpp:464)
[12] widechar_main (D:\dev\godot\platform\windows\godot_windows.cpp:161)
[13] main (D:\dev\godot\platform\windows\godot_windows.cpp:196)
[14] __scrt_common_main_seh (d:\A01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[15] BaseThreadInitThunk
-- END OF BACKTRACE --

Reproduced this on multiple machines (all running Windows 10). I should note that on some of the machines, I got this traceback instead:

Godot Engine v3.2.2.stable.custom_build.6a9fbafcb - https://godotengine.org
OpenGL ES 2.0 Renderer: GeForce GTX 1070/PCIe/SSE2
OpenGL ES 2.0 Batching: ON

CrashHandlerException: Program crashed
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[0] <couldn't map PC to fn name>
[1] <couldn't map PC to fn name>
[2] <couldn't map PC to fn name>
[3] <couldn't map PC to fn name>
[4] <couldn't map PC to fn name>
[5] <couldn't map PC to fn name>
[6] <couldn't map PC to fn name>
[7] <couldn't map PC to fn name>
[8] <couldn't map PC to fn name>
[9] <couldn't map PC to fn name>
[10] <couldn't map PC to fn name>
[11] <couldn't map PC to fn name>
[12] <couldn't map PC to fn name>
[13] <couldn't map PC to fn name>
[14] <couldn't map PC to fn name>
[15] BaseThreadInitThunk
-- END OF BACKTRACE --

When Steam is not active, the game runs fine and exits properly on the Steam init check.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 23 (12 by maintainers)

Most upvoted comments

Yeah, I can recreate it too if I used a different app ID.

Is the implication that if the game isn’t installed it will crash? Otherwise I can’t imagine running into a problem where one is running their game with anothers app ID, and where a player is somehow executing a copy of the game without having installed it.

The problem is because SteamUser() is returning a null pointer. Doesn’t seem to be documented, but a lot of the other API methods seem to do this too.

image

Not sure how you’d want to handle it, check if SteamUser() is null first, and throw an error “Invalid app ID or app not installed”?

That’s fuzzy as well, it’s not clear if these are the only condition where it fails and returns null, can’t inspect their code. I presume the wrong app ID just leads to the same problem, you don’t have it installed.

Either way it’s probably fixed in a few lines.

I did notice this in the header btw just now getAPICallFailureReason() It returns a string, curious if that gives the reason for the init failure after it was attempted.

Yeah, I was wondering too, I was expecting the API would’ve had something to simply launch steam. (Kind of thought steam init would do that at first glance.) The restart app if necessary is the closest thing, but that won’t work with running from the editor. If I recall correctly, it will restart to the build that is downloaded to your steam apps directory.

No big deal though, this is just for editor testing side of things only, so a constant is fine since we control where steam is installed on our end. The other steam startup logic works fine for release builds.

If there is a way to reliably get the app path from all the supported OSes, it might be a nice feature to have in some situations.

It wouldn’t be too much more than the example project. Might add a timeout or handle certain errors depending on what comes up.

extends Node2D

const STEAM_PATH = "C:\\Program Files (x86)\\Steam\\Steam.exe"

func _ready() -> void:

	var pid = -1
	var result = Steam.steamInit()


	while(result.status != Steam.RESULT_OK):
		
		if(pid == -1):

			print("Starting Steam.")
			pid = OS.execute(STEAM_PATH, PoolStringArray(), false)
		
		yield(get_tree().create_timer(1.0), "timeout")		
		result = Steam.steamInit()

I think only when multiple people use Steam on the same PC, that’s how we came across it.

Ah, interesting, hadn’t thought about shared storage with multiple users. It would make sense for them to leave the files of un-owned games. Yeah, it would be good to handle that situation gracefully with some feedback.

This also fixes this issues: https://github.com/Gramps/GodotSteam/issues/127

So another plus is that I can now write a script to attempt to launch and await for Steam to open when launching from the editor.

Yep, works! Thanks so much! 😄

Oh yeah, this isn’t a huge issue probably (I think only when multiple people use Steam on the same PC, that’s how we came across it), but since it was so consistent I though it might be an easy fix 😃 Might save some cryptic support mails in the future, haha.

Hmm, that’s pretty interesting and a fantastic lead, sir! Yeah, the situations where this arises shouldn’t be common but still should be fixed.

I’ll mess around with this and get a patch in by the weekend. Thank you for this information!

UPDATE: Huh, I get a totally different error before it spits up the backtrace portion.

I’m compiling from scratch, with msvc, using these options: scons -j6 platform=windows target=release_debug use_lto=yes disable_3d=yes. I just tried it with the pre-compiled build, but it had the same issue (although I now got the second traceback, with all the <couldn't map PC to fn name> lines, instead of the first traceback?).

I do have an steam_appid.txt in the editor directory yes 😃 Everything works fine and Steam recognizes the game if I start the game from the editor with an account that does own the (unreleased) game. The crash specifically and reliably occurs for me if I’m logged into a Steam account that doesn’t own the valid, unreleased appid.