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

Not favoritedFavorited Favorited 0 favourites
From the Asset Store
_______ Huge collection of metal fixtures ________
  • Hello,

    On another post, Ashley replied the following about the Steam overlay and WebView2:

    "However when the in-game overlay is not supported Steam has fallbacks, such as showing the actual Steam window over the game, instead of rendering it inline, so hopefully that's not too bad."

    I'm unable to make this fallback appear in my game. Nothing happens at all when pressing Shift+Tab. Someone could tell me how I could make the fallback to work if that's possible? Someone managed to have Steam display something when pressing shift+tab on a game exported with WebView2?

    For reference, here is the free Steam demo of the game I'm developping. As you will see, there is nothing happening when pressing shift+tab.

    Thanks for your help!

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

  • Yes, but Ashley mentioned support for NW.js will be deprecated in the future. Also, I have worse problems with NW.js on my part, like tabs being duplicated when doing alt-tab a few times.

    Overall, I prefer using the WebView 2 because:

    - Construct team is planning to support it long-term

    - I don't get the very annoying tab duplication bug

    - The game's weight is much lower

    - I just learned I can also put the game on Epic Games Store using the same technology, thanks to the linked plug-in. (as a reminder if you have achievement on Steam you are required to have achievements on Epic Games)

    The counterpart is that I don't have the Steam overlay which is quite problematic, but indeed it's not a requirement.

  • We're publishing a demo for our game as well and there is no fallback working either. Shift+TAB won't do anything.

    We were hoping the new export option will make it exporting to Steam better, not worse!

    Steam won't stop you but you're missing access on literally the HUB your game can have on steam: screenshots, friends, community, achievements, etc.

    Why is NW.js being deprecated when we have a worse solution?

    I managed a while back to use it to show the Steam Overlay and for achievements.

  • Please, please contact Valve as your first port of call. There is very little we can do about it. It's all their software and we comply with all their documented requirements, which pretty much just say "it should work".

    NW.js support for the overlay currently depends on hacky settings that are not officially supported, and in fact is currently broken in the latest NW.js releases. As it's not an officially supported feature, they are within their rights to say "sorry, that's not supported" and close the issue as 'won't fix'. So I really would not say that's working particularly well either and is not a reliable basis for a feature anyone cares about. If they fix it, it will basically be luck; if they don't, we're back to square one. To have robust support for the Steam overlay that consistently works, we need Valve's co-operation.

    Having said that, try WebView2 in the latest beta if you haven't already - it contains a change that may help.

  • Doesn't work with the latest beta either (r455) and the latest addon version 1.4.3.0.

    Shift+Tab doesn't do anything. Is there some debugging/verbose mode we could turn on in the addon or something to see what's happening?

    The only way to use Steam's features is to call the Steamworks action. So my workaround will be to build some ... menu of sorts when the user presses Shift+Tab hopefully, and to surprise him (in a bad way).

    Console:

    I'll try to contact them and link to the repository (https://github.com/Scirra/Construct-Plugin-Steamworks) but... pretty slim chances they would care. Now if Unity or UE5 integration would break....

  • Valve addresses this:

    partner.steamgames.com/doc/features/overlay

    Q. My game runs in a browser. Can the Overlay work in that?

    A. The Steam Overlay requires a game consistently render frames, not pausing rendering or rendering only part of the screen based on dirty rects. Unfortunately, web browsers do not support this model. A workaround for web based games is to host an embedded Chromium inside a native application, with a D3D window and input forwarding to the embedded Chromium. That can be setup to render in offscreen mode, which then renders the resulting chromium texture each frame in the native app. Partners often use CEF to do this, though this is not an easy task.

Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)