Ashley's Forum Posts

  • Behaviors can't draw, only plugins can, that being an architectural decision taken many years ago.

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

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

  • TheRealDannyyy - Electron is architecturally pretty much the same as NW.js and so has the same shortcomings. These days the node.js layer of NW.js/Electron is pretty much entirely redundant, which makes it more or less deadweight and a significant and unnecessary complication for integrating features like Steam support which have to go through this layer. It also seems to have the limitation that you have to rebuild the addons for every new node/Chromium build which is a real PITA - most of the time you can just write something and it keeps working long-term, but this means it quickly goes out of date without constant active maintenance.

    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.

    However rest assured that nothing will be deprecated or removed until there is a suitable replacement - I think we will have to keep using NW.js and node addons for the time being, until at least things like Steam Overlay support and unrestricted file system access can be implemented for WebView2.

  • False positives should be reported to the antivirus vendor - there's nothing we can do about it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's a built-in addon. You don't need to install it.

  • It's not clear what you're doing. Are you using the Share plugin or the Clipboard plugin?

    If you think there is a problem with Construct than as ever the best way to deal with it is to file an issue following all the guidelines.

  • var textObject = runtime.objects.PW;

    textObject.text = "Hello, World!";

    This is a common mistake that confuses object types with object instances. You are trying to set the text of the object type, but only actual instances have a text property. You need to call getFirstInstance() to get an instance which you can then change the text of.

    I strongly recommend taking the Learn JavaScript in Construct tutorial course which covers all of this kind of thing, in particular part 11 which covers Construct's APIs.

  • Yeah, I was going to ask - maybe you could team up with someone like Chadori or Mikal to develop a new Steam addon?

    It's an option (or just bite the bullet and do it myself), but for the time being I want to see what happens regarding WebView2 support, as that would change the direction we go in.

  • Which export option are you using? Clipboard features should work in Chrome on Android. However if you're exporting an Android app there's a known issue that currently prevents copying to the clipboard from working.

  • I've been thinking about the future of the desktop exports, especially as I'd like to support other stores like the Epic Games Store too, but the current approach of relying on the current set of third-party tools isn't working out (as noted Greenworks is essentially abandoned and I don't believe any Epic Games equivalent exists).

    TBH I'd prefer to move everything over to the Windows WebView2 export option. I've been impressed with how well WebView2 works, and it has the official backing of Microsoft, who have a lot more resources than the NW.js team (who seem to have been struggling to fix even serious regressions lately). It would be more feasible to develop our own Steam/Epic integration for the WebView2 export option as we already have a custom container app around the WebView2 control.

    The only downsides are:

    • Currently WebView2 is Windows only, but:
      • their roadmap does say macOS and Linux support is planned
      • Our stats show the vast majority of NW.js exports are for Windows anyway, so maybe it doesn't matter
    • The Steam Overlay doesn't appear with WebView2 apps, and the command-line workarounds for NW.js don't seem to work for it. I already reported this to Valve, but there's been no progress yet (and my past efforts to get them to fix things have been fruitless, which is why there's a bunch of quirks with NW.js that Valve never fixed).

    So it's a bit of a mess, but so long as the existing stuff keeps working I don't think there's any major urgency. As ever it's also a lot of work whichever path we take and with our limited resources we'd have to delay or cancel some other planned features or tasks to work on this. I'd be interested in thoughts on using Windows WebView2 for Steam publishing, assuming we got it to work - would the lack of macOS or Linux support be significant?

    I'd add it should be possible for third-party developers to step in too - there's nothing stopping a third-party developer (or contracting someone to do the work if it's that important) to write the necessary integration for the existing NW.js export. That includes forking and updating the existing Greenworks code which should provide a fairly mature starting point.

  • It's difficult to see how it could be implemented like that, as it doesn't necessarily know which object will be its parent, and its parent's image points could vary across different animations and frames. A good example of a feature that looks obvious but is in fact probably impossible in that form.

  • That's why the Pin behavior is still there and the manual terminology around it being superseded refers to most (not all) features being replaced by hierarchies.

  • Surely there has to be a better solution then reporting it to each individual vendor, specially if this is a general problem native to construct or nw js?

    I'm afraid there isn't. Everyone affected should report any false positives to their antivirus vendor. It's the only way things like this get sorted out.

    I'm pretty sure this is nothing to do with the icon updater, and the base files themselves are flagged as false positives. Perhaps the fact the icon updater tool modifies the files causes antivirus software to take note.

  • Check the 'Export file structure' setting in Project Properties. If it's 'Flat' then subfolders are not used after export. However if it's 'Folders' it should work.