TheRealDannyyy's Forum Posts

  • So Chromium 115 has hit and with it goes the reliable workaround of using the --disable-windows10-custom-titlebar command line argument. While the titlebar will now be fancy and respect the users Windows theme, it also comes with the same set of issues.

    NWjs Steam Overlay issues (v0.78.0+):

    1. Fully covered window titlebar (overlay renders above or below it)
    2. Broken titlebar features when overlay enabled (e.g. drag, close, minimize...)
    3. Titlebar overlay "ghosting" after closing it

    Known Workarounds (15th Nov 2023):

    1. [Unresolved]
    2. [Unresolved]
    3. Use "Set Title" NWjs plugin action (e.g. combine with "On overlay deactivated" condition and repeat action for 5sec)

    I'm not that active anymore and can't provide help for all NWjs and Steamworks related features like in the past. I'll periodically play around and see if I can find better solutions for this specific issue.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've been battling with this specific Greenworks (Steam API) feature for years now. So I figured I'd give it another try in 2023, since a lot has changed.

    My Goal:

    1. Fetch user steam avatar using Greenworks (returns integer handle)
    2. Convert integer handle to any format that Construct can use
    3. Apply converted image data to sprite using "Load image from URL" action (e.g. base64)

    The official documentation states to use a node module called Jimp. This process basically works by converting the integer handle into a buffer (in RGBA format) and then write it to an image. After many attempts, any resulting written images were always just black or corrupted for me.

    Now to my question. Are there any modern Javascript or 3rd party Javascript API alternatives to convert the integer handle that the Steamworks API provides into something usable in Construct?

  • If it works in Chrome, it probably means Construct is working correctly - if the problem was with Construct then it wouldn't work in Chrome either.

    I think Brave has very strict privacy settings by default. This may mean it intentionally deletes local storage (confusingly also referred to as "cookies", although the term means any locally saved data). If it does that, then all you can do is change the browser settings to not do that.

    Not sure if this will work but maybe giving the local storage plugin a "request persistent storage" option could be a workaround for stricter browsers?

    The editor itself already has this option and it works fine for me on Brave. However, I don't know the requirements and limitations of this feature but I assume ideally we would have an action to request it and conditions to validate it.

  • TheRealDannyyy Sorry for the mention but I know that you are very familiar with NWjs, and that maybe you can enlighten me on that topic

    I have no idea honestly. Are you sure it's NWjs doing it? I ask because the name of the folder is in uppercase. Also what's inside the folder anyway?

    Edit: I tested running NWjs v81.0 and it didn't create that folder for me.

  • > I don't agree. Steamworks SDK is quite extensive and the only feature we have access in Greenworks now is achievements.

    I forgot to mention that I use the official plugin for importing the modules and access the rest of the features through executing js. The plugins by themselves might not support all features (yet).

    The point was that Greenworks itself (not the plugins) support most Steamworks features up to a certain point and Steam is backwards compatible with those.

    As I understand from Mikal's comments, the addon is based on the same abandoned Greenworks JS library as the official Greenworks plugin.

    The Greenworks node module exists as a "communication layer" between web and native tech. Construct plugins just make it more convenient to use those features.

  • > Ashley Could this be simplified by providing an "execute c++" feature similar to the existing "execute JS" action inside the browser plugin?

    No - C++ is a compiled language and also needs to be configured with the necessary SDKs, libraries, etc.

    Oh yeah, it's been a while since I used a language which isn't interpreted.

    Really appreciate that Scirra would be up for adding proper Steamworks support for Webview2 down the line. Sounds like it's up to Microsoft to add something similar to the single process feature in NWjs or Valve to update their overlay.

    To get back to the main topic. I personally don't see a big issue with Greenworks as it stands. Steam is backwards compatible and Valve doesn't force developers to only publish with more recent versions of their SDK. Sure, we won't get support for any new groundbreaking Steamworks features in our games but that should be the only downside for now.

  • Compare that to WebView2 where we already have our own simple, minimal C++ wrapper, which we could directly integrate with the Steamworks API - no middle layers and it wouldn't need updating with every version. IMO that's a much nicer architecture and puts us in full control of the Steam integration.

    I had no idea that Webview2 comes with a C++ wrapper. I'm personally still a bit skeptical since Microsoft decided to pull the plug on UWP in the past but overall I would also be in favor of Webview2. It's still going to be a challenge for devs and their node plugins to be ported over to the C++ wrapper.

    It's common for game engines to at least partially provide access to supporting the SDK/API's below:

    Quick overview:

    (*supported through Node plugin in Construct 2/3)

    In theory it would be possible to have some kind of plugin model for WebView2. But I don't think it makes sense to consider that any further until it's clear we can solve the aforementioned issues for Steam.

    Ashley Could this be simplified by providing an "execute c++" feature similar to the existing "execute JS" action inside the browser plugin?

  • Would Electron be a worthy temporary solution until WebView2 is supported on all desktop OS's? Though I guess this would just move us to a bunch of different potential issues, or maybe even the same exact issues as NWJS. Or maybe another alternative altogether, just to tide us by if NWJS is not seeming to resolve major issues?

    I don't understand why you decided to discard this idea. Electron is still the industry leading standard and widely used to distribute desktop apps with many active developers and guaranteed long-term support because of its community.

    Node Modules which the Greenworks addon relies on aren't supported by Webview2 either. I'm not aware of any alternatives besides using the feature incomplete Steam Web API.

    Ashley I'm aware that this could be one of those "grass is greener" situations but has this ever been on the radar for Scirra? Electron is feature complete, supported by Greenworks and has on-par performance with Webview2.

  • You do not have permission to view this post

  • Not sure if this is worth suggesting or not but would it technically be possible to override the sampling quality inside layers themselves?

    I can see this being useful for projects, which for example use pixel-art but need smooth and clean looking UI. Other engines already offer this feature but on a "per-object" basis. I personally think making it a feature for layers would be easier in Construct 3.

  • Could be related to the Vulkan renderer failing to initialize. Check your user agent in the browser console. It should automatically log all of that stuff there.

    Another thing you can do. Export your project using both versions and check if any files are missing. Maybe Scirra removed some by accident in the latest version of NWjs.

  • Ah ok! I will try to locate the folder myself by comparing files.

    EDIT: do you mean that I *have to* remove irrelevant files from the nw.js for it to work?

    Suffice to say I don't know much about nw.js only that it is a neater way to display the game..

    Not required at all. It will work either way but it will be bloated (total file size) when you distribute it.

  • It depends on the scope and type of your project.

    Construct 3 comes with the benefit of Scirra patching things up, pretty much on demand.

    Just as an example. The NWjs plugin is outdated and has some broken actions because of changes by NWjs (3rd party). I have enough knowledge to workaround issues like that myself but if you don't. It might become an issue down the line.

    Like with any unmaintained software. You'll have to deal with issues yourself.

  • It's safe but you need to clean up any unnecessary files. That was one of the main reasons for why Scirra provided them, instead of letting us do it manually.

  • Sorry to bother you again real quick Everade.

    Does the icons folder contain a file called "WindowsIconUpdater.exe" or has that been deprecated and removed entirely?