Everade's Recent Forum Activity

  • So maybe this can manifest without multiplayer in other scenarios too, depending on how things are implemented.

    Technically yes.

    But the main point was to give an example where the crash can be reproduced consistently, so it can be debugged and fixed.

    The proposed solution was obviously tailored towards multiplayer improvements, as it originated from the old feature request platform. So that can be technically ignored. It would have worked as a workaround to prevent this multiplayer edge case from happening in the first place, not fixing the actual crash.

  • In short:

    No it doesn't work on WebView2.

    Why?

    Because WebView2's rendering architecture is problematic for Steam's overlay to hook into.

    So Scirra came up with a workaround to make Steam's overlay work. This is described in the Steamworks plugin documentation.

    It adds the D3D11Overlay_x64.ext.dll to your exports as you've noticed, which is a library used to create this DirectComposition Direct3D 11 overlay-frame, on top of your game. Steam then hooks into that, instead of your game.

    While this makes the Steam overlay work on Webview2, it also breaks direct game recording with any recording tool, including Steam Recordings, as well as Steam Remote Play and Steam Broadcast. As applications now pickup this transparent overlay, instead of the actual game.

    Scirra likely can't do more than this -> Steam doesn't care because not enough people report it to them -> There will realistically speaking never be a solution to this.

    There's a small chance that either WebView2 or Steam gets an update adressing this in the future, but i definitely wouldn't count on it.

    A workaround would be to use 3rd party exporting solutions like Pipelab, which uses Electron. Use an old C3 version to export with NWjs. Or migrate your game to a different game engine.

    Which is unfortunate, but it's the situation we're in.

  • Send your project to support, I'll take a look. But without something clear to look out for, there is a low chance I could do anything about it, primarily because at any given time we have a bunch of other things to do.

    I'm pretty certain that it's exactly this bug here: github.com/Scirra/Construct-bugs/issues/5623

    If the client destroys the instance, while the host destroys it as well, it will crash, because the sync tries to destroy an instance which is no longer existant peer-side.

    I've made a minimal reproduction project back in 2022: github.com/Scirra/Construct-bugs/issues/5623

    Proposed Solution:

    github.com/Scirra/Construct-bugs/issues/5623

    This bug still exists, as it has never been addressed.

  • Hello,

    I understand but I used the Linux export and even repeated it but the issue remains and Steam support say everything is correctly set up.

    Sounds like the game is being started with the Proton compatibility layer. In that case, Steam downloads/installs the Windows build you've uploaded.

    So it's possible that you haven't properly configured the Linux build on Steamworks. Or that the player has manually chosen the Proton compatibility layer in the game's properties.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The Steamworks plugin currently has a workaround to make the Steam Overlay work. This is described in the Steamworks plugin documentation.

    This workaround creates transparent window on top of the game, simply to be able to render the Steam overlay.

    From what i've seen, it adds the D3D11Overlay_x64.ext.dll to your exports, which is a library used to create this DirectComposition Direct3D 11 overlay-frame which Steam hooks for the overlay.

    While this makes the Steam overlay work on Webview2, it also breaks direct game recording with any recording tool, not just OBS. As they now record this transparent window, instead of the actual game.

    For OBS, the recording can be fixed by changing the OBS settings.

    There's also an open pull request to get OBS automatically to default to these settings for Construct 3 Webview2 exported games. See here:

    github.com/obsproject/obs-studio/pull/13477

    However this only solves it for OBS. For other recording tools you still would need to either record on a "Desktop"-level instead. Steam recordings definitely won't work.

    All you can do on your side is deactivate the Steamworks plugin overlay setting, that would probably prevent this overlay workaround. Or not using the Steamworks plugin at all.

    There's not much else you can do, other than reaching out to Steam support and beg to support overlay for web based games. Because Scirra is definitely not interested enough to get this resolved for us. As they've already spent too much time on the actual overlay workaround.

  • OK, so it looks like it's not just achievements, the entire Steamworks plugin is failing to initialize. I'm afraid it's difficult to help though - whenever I test this it using the Steam Devkit client it works fine, and I don't know what you could have done differently that would mean it doesn't work. Are there any error messages in the Steam Devkit log? Are you sure you are not doing something that is causing a problem with file permissions?

    I may have found the cause on LTS:

    github.com/Scirra/Construct-bugs/issues/9216

  • There will always be some delay when data is sent over the internet. That is simply a physical limitation of networking.

    You can make each player’s flipper respond immediately on their own machine, but if the host remains authoritative over the ball, the visible ball reaction will still arrive later. Input prediction does not remove latency, it only tries to hide it by showing the expected result before the authoritative result arrives. And it's just used for inputs, so controlling something. You can't really apply this directly to a physics behavior-ball.

    That is generally what real-time multiplayer networking is about: hiding latency through prediction, interpolation, reconciliation and, in more advanced cases, rollback.

    For this particular game, one possible hybrid approach would be:

    • Let each peer activate their own flipper immediately.
    • Send the input, timestamp and relevant flipper state to the host.
    • Let the peer temporarily predict the resulting ball collision and trajectory.
    • Keep the host responsible for deciding the final authoritative ball state.
    • Synchronize regular ball snapshots from the host.
    • Interpolate normal movement and gradually reconcile small prediction errors over several frames.

    A more advanced implementation would keep a history of inputs and physics states so the client or host can rewind and resimulate from the collision time. That is broadly referred to as rollback.

    Note that this is just a simplified overview. There is no single setting that makes networked physics responsive and consistent. the appropriate solution depends on how much latency, visual correction, implementation complexity and potential cheating you can tolerate.

    Also keep in mind that that applying these techniques using the physics behavior may not be feasible. It would probably be easier to run your own event sheet driven physics solution. Separating the actual ball's collision box with its visuals could also help to further hide position corrections and so on.

  • What does your content directory look like? Are you putting all the Linux files in the directory root and then a sub folder for the Window/Mac versions? Or are you putting everything into the root?

    All in root, but not mixed together, to me it sounds like you're trying to mix all exports into a single depot. I'm not sure why you would want to install Linux and/or macOS on a Windows machine for example.

    In Steamworks, you can create a separate depot for each export variant and configure them accordingly.

    For example:

    • Depot Windows -> configure Operating System: Windows
    • Depot Linux -> configure Operating System: Linux + SteamOS
    • Depot macOS -> configure Operating System: macOS
    • Then configure the "Store package" to include all 3 depots.

    Then for each depot, you upload only that specific export variant.

    • Depot Windows -> upload WebView2 export only (root)
    • Depot Linux -> upload Linux (CEF) export only (root)
    • Depot macOS -> upload macOS (WKWebView) export only (root)

    If everything is configured properly, Steam will download the respective depot depending on your current OS. Instead of installing all builds on all platforms with sub-folder structures. Which is honestly just bloat for the end-user.

    Steamworks has a lot of settings scattered throughout multiple menus. So make sure to refer to the Steamworks documentation.

  • Works for me.

    Export: Linux CEF - x64 - Chromium v147 (Bundle assets)

    Plugin: Steamworks v1.6.0.0

    Construct 3: r487-3 Stable -> (also works with r449-3 LTS)

    Tested on CachyOS (not Steam Deck, but should work just fine too)

    If it doesn't work for you:

    Since Steam overlay is not supported on Linux, it's always smart to look into devtools' console logs to see whether everything is working as expected.

    - How to open devtools on Linux

    If you upload using Steam's web-uploader, then you must re-zip the export with the files being in the root folder. But you can't do this on Windows due to file permission issues!

    Optionally you can use the SteamPipe Build Uploader or SteamPipe cmd-line.

    Also read this note about the plugin's Development Mode.

    Error loading '.../Isle of Reveries/Linux/steamworks-x64.ext.so': libsteam_api.so: cannot open shared object file: No such file or directory

    Both files should be located in the root folder. Not sure why it would be looking for a "Linux" sub-folder.

  • This function is not called every tick, it is called while the player is inputting a movement direction (which I suppose is every tick that it is needed) and deceleration is handled by the 8-Direction behavior. Would I still need use "TimeElapsedSinceLastExecution" in that case?

    If the function is called once per tick (while movement is active), then you should be good to go.

  • It's not really an issue with the 8 Direction behavior, but with how the lerp is implemented. Your code is not framerate independent.

    Framerate independent lerp example:

    lerp(CurrentValue, TargetValue, 1 - (0.05 ^ dt))

    In this example, 0.05 means that after 1 second, only 5% of the difference remains. Lower values = faster / Higher values = slower.

    If the function does not run every tick, then you would need to replace dt with the elapsed time since this function last executed.

    In that case, use the elapsed time since the previous function execution instead:

    lerp(CurrentValue, TargetValue, 1 - (0.05 ^ TimeElapsedSinceLastExecution))

    You should apply this to every lerp.

    Sidenote: Since this code is inside a function and i don't see how it's being executed... the function should run once every tick for the lerping to behave as expected.

  • Hi,

    I recently got Blasphemous. I played it on the deck for an hour, and then when I booted it up on my pc, the save file didn't exist, because the linux version and the windows version of the game apparently can't share save files. So my playthrough is stuck on the deck.

    If this is the case, and with the existence of the proton interpreter, Why would I bother with making a Linux version for a game targeting the steam deck?

    It's up to the developer to set up steam cloud saving properly. It's definitely possible to share save files between different operating systems, i've done it myself. This has nothing to do with the export option, with Auto-Cloud, the developer must configure the save path mapping correctly across OSes, using a single root plus overrides for cross-platform sync.

    A proper export would surely run smoother than letting Steam run it through Proton, so there are surely some benefits. Possibly a little quicker to get through the SteamDeck verification process as well. The game would also be listed as "Native" on databases like protondb and so on. So marketing wise it might do you some favors too.

    However again, this has nothing to do with cloud save syncing issues.

    If you as the game developer use Steam's Auto-Cloud feature, and want to support cross-platform saves, then you must configure a "Root Override" for each OS manually within Steamworks. So it's possible that they missed that on Blasphemous if what you're saying is true.

    For more details, checkout the "Cross-Platform Saves" section here:

    partner.steamgames.com/doc/features/cloud

Everade's avatar

Everade

Online Now

Member since 24 Jun, 2014
Last online 8 Sep, 2026

Twitter
Everade has 13 followers

Connect with Everade

weakspots.com

Trophy Case

  • 12-Year Club
  • Entrepreneur Sold something in the asset store
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • x4
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • RTFM Read the fabulous manual
  • x88
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x152
    Lightning Draw First person to up-vote a new Construct 3 release
  • x4
    Great Comment One of your comments gets 3 upvotes
  • Delicious Comment One of your comments gets 10 upvotes
  • Magnificent Comment One of your comments gets 25 upvotes
  • Email Verified

Progress

27/44
How to earn trophies