How do I use Steam "fallback" when the Steam overlay doesn't work (with WebView2)

It's meant to work automatically. If it detects the in-game overlay isn't supported, then it automatically uses fallbacks instead. In my testing the fallbacks worked as expected, for example showing the actual Steam UI over the game instead of the in-game overlay.

If the fallback doesn't work as expected it's hard to offer any help as it's entirely implemented by Valve as part of Steam - it would be best to direct any further questions to them.

It's meant to work automatically. If it detects the in-game overlay isn't supported, then it automatically uses fallbacks instead. In my testing the fallbacks worked as expected, for example showing the actual Steam UI over the game instead of the in-game overlay.

If the fallback doesn't work as expected it's hard to offer any help as it's entirely implemented by Valve as part of Steam - it would be best to direct any further questions to them.

The fallback isn't working for me either. Have you done any recent testing? Given the numerous reports of the Steam fallback failing, it's clear we need a proactive approach rather than waiting for Valve to address the issue. I understand this topic is frequently raised, but robust Steam integration is critical for many developers aiming to release commercial games. I believe the Construct community would strongly support your dedicated efforts to find a stable solution for this rather than other features.

The problem is even where we can reproduce issues with this, there's nothing much we can do about it. From Construct's point of view Steam is a black box that automatically modifies the way the application works. It is meant to just work automatically and is not customizable. So I would say you should get in touch with Valve first regarding any issues with this - it's their software, their documentation says it should just work, and if there's a problem with it then they need to fix it.

The problem is even where we can reproduce issues with this, there's nothing much we can do about it. From Construct's point of view Steam is a black box that automatically modifies the way the application works. It is meant to just work automatically and is not customizable. So I would say you should get in touch with Valve first regarding any issues with this - it's their software, their documentation says it should just work, and if there's a problem with it then they need to fix it.

I hope you understand that from our point of view, you consistently opt to integrate third-party solutions that are less than fully reliable and regularly tell your users to contact these companies for support instead of Scirra. This is your choice, not ours.

Steam itself is a third-party solution. If you want to publish to Steam, you have to deal with Steam. If Steam isn't working properly, unfortunately that's outside of our control and not something you can easily swap out with something else, unless you're willing to publish to a different store like Epic Games (which we also have a plugin for).

Steam itself is a third-party solution. If you want to publish to Steam, you have to deal with Steam. If Steam isn't working properly, unfortunately that's outside of our control and not something you can easily swap out with something else, unless you're willing to publish to a different store like Epic Games (which we also have a plugin for).

You mean, if Construct 3 users, people who sought to use your game making software, want to publish their games to the largest game store platform available? Where do you want your users to be able to present their creations? Do you want your users to be able to present their creations as intended on these types of platforms? If so, maybe it's worth diving deeper into such issues.

Clearly you do recognize that this is an issue, otherwise you wouldn't have created this thread on the Steam forums. I assume Valve hasn't been helpful in the matter, we've also tried our best reaching out to them but to no avail. This is why people are broaching other potential solutions.

What do you want me to do - open the source code to Steam and fix it? That's not possible. You can still publish your game to Steam without support for the in-game overlay - it's not something Valve require (perhaps because they know it doesn't always work!) We've also already gone to great lengths to try to get it to work and unfortunately had to conclude it's not feasible, at least with the current state of things, and so Valve need to change Steam to get it to work.

Unfortunately sometimes issues come up which are genuinely beyond our responsibility and capability to fix. For example sometimes a graphics driver bug - part of the system software tied to the hardware - causes someone's game to crash or glitch, and they insist we should fix it. Unfortunately the problem is the responsibility of the graphics driver developer though - they need to fix it, and usually it's infeasible for us to do anything about it. The person affected by a graphics driver issue might say similar things to you, like people who want to publish games with Construct should have a guarantee it works. They're complaining to the wrong company though. It's out of our hands. We work hard to make Construct robust and reliable within our own code, but software is complex and any ordinary program involves using components from dozens of different companies. It's possible some other component fails, and if that's the case it's the responsibility of a different company and there's only so much we can do. The best thing to do is to take it up with the company responsible. If you keep asking us, I'm afraid it won't change the situation.

What do you want me to do - open the source code to Steam and fix it? That's not possible. You can still publish your game to Steam without support for the in-game overlay - it's not something Valve require (perhaps because they know it doesn't always work!) We've also already gone to great lengths to try to get it to work and unfortunately had to conclude it's not feasible, at least with the current state of things, and so Valve need to change Steam to get it to work.

Unfortunately sometimes issues come up which are genuinely beyond our responsibility and capability to fix. For example sometimes a graphics driver bug - part of the system software tied to the hardware - causes someone's game to crash or glitch, and they insist we should fix it. Unfortunately the problem is the responsibility of the graphics driver developer though - they need to fix it, and usually it's infeasible for us to do anything about it. The person affected by a graphics driver issue might say similar things to you, like people who want to publish games with Construct should have a guarantee it works. They're complaining to the wrong company though. It's out of our hands. We work hard to make Construct robust and reliable within our own code, but software is complex and any ordinary program involves using components from dozens of different companies. It's possible some other component fails, and if that's the case it's the responsibility of a different company and there's only so much we can do. The best thing to do is to take it up with the company responsible. If you keep asking us, I'm afraid it won't change the situation.

Valve recommends using CEF in its documentation. However, since you mentioned that asking further won't change the situation, let's leave it at that. Thank you for listening.

I've found that NWJS has been the most reliable desktop exporter.

I have games on Steam with it.

Just have to use NVPatch-UI to make it work with laptop GPU.

And occasionally a version of NWJS doesn't work properly, so just try an older version when exporting.