Ashley's Recent Forum Activity

  • This has been discussed to death already, but in short we're not planning to change Construct's pricing model at this time. I do however want to point out that Construct's pricing is not too expensive, in the ballpark of a Netflix subscription in most places, and so should be acceptable to hobbyists. Thousands of people are willing to pay the subscription to get Construct because it's worth it to get a quality tool stuffed with countless features and has performance, usability and reliability that beats many other options.

    Developing software is expensive, and ensuring the tool is economically sustainable is important for people who work on long-term projects. There are some tools out there that I'm interested to see if they can actually sustain themselves over the next few years as they may well be running at a loss, and I wonder what will happen to customer's work if a tool developer goes under. Sustainability is also important to avoid the need for drastic business changes like Unity's runtime fee debacle. In an alternate universe it's possible we stuck to Construct 2's model, sales petered out, and then we were forced to close the business and go do something else, even though there were lots of people still using Construct - and that would suck for them and their work. I can assure you we're a long way from that scenario, and the subscription model is a good way to avoid that ever happening.

    I'd also add that there are significant issues with Construct 2 - by now I think none of the mobile exporters work out of the box, the desktop exports are well out of date, it doesn't properly support high-DPI displays, it has likely thousands of bugs that were fixed during Construct 3's development, if you run in to any problem there will be no support provided, as the technology ages more and more things will probably stop working, and meanwhile Construct 3 has absolutely tons of new features and improvements allowing for much greater flexibility and creative expression (many of which are listed here, but even that is quite out of date now) - not least the latest support for 3D models. Perhaps some people don't care about any of that. However I would say much of that is important to a lot of people, and there are years and years of hard work that go in to developing a product that is actively supported and continuing to advance in features.

  • As we're probably going to be supporting this workaround for a while, there are a couple more changes in r473 to try to make gamepad support work better in Windows WebView2 exports. There's a new 'Export for Steam' setting for the Windows WebView2 exporter. This does the following:

    • Unchecked (default): sets "allow-host-input-processing": false in package.json. Gamepad input should work normally (using browser-provided gamepad input).
    • Checked: sets "allow-host-input-processing": true for compatibility with the Steam Overlay, and then includes the GameInput wrapper extension to work around the WebView2 bug that stops the browser-provided gamepad input working in this mode.

    The GameInput wrapper extension is also updated in r473 to support multiple gamepads as Microsoft were able to fix the GameInput bug that was preventing us supporting that. Note however as per the previous post, haptics (rumble) are still not supported with GameInput, and you must still install the GameInput redistributable installer to ensure support is available (be sure to use at least v3.2.138 as that has the fix allowing for multiple gamepads).

  • It looks like it should work. It is always difficult to provide much help unless you share your project file though. Maybe take a look at the Screen recording example and see how that does things.

  • > It violates a fundamental security property that only the addon author has permission to update their own addon.

    That's why I mentioned maybe only explicitly marked as deprecated addons by the author.

    Marking your addon deprecated does not mean "I give other developers permission to overwrite my addon" and I think it would be wrong of us to use that setting in that way.

    I'm not talking about making an auto-update. The addon should still be treated as a different addon.

    The entire addon system is set up so the addon ID is what defines an addon, so a different addon with the same ID is not in fact a different addon and there isn't currently a system set up to be able to identify such addons as different. Besides, if the auto-updater doesn't update such addons, then users still need to manually hunt down an updated addon.

    If you think deprecated addons should still be protected, could you at least look the suggestion of github.com/Scirra/Construct.net-website-bugs/issues/205 that has been ignored for over a year?

    If the original addon developer is active enough to add someone as a maintainer, then why not just send them the ported code to publish? The real problem is addon developers who have become inactive and unreachable, in which case implementing an addon maintainers feature does not help the situation at all.

    I'm afraid I don't see any easy answers here.

  • Another way to say it is: We want global layers but that don't share object instances. Can you "just" make it an option to have global layers do exactly all they already do but share objects?

    I'm afraid as I said the existing global layers system is extremely complicated and very difficult to change, and as the design proved highly problematic, I would not want to add a second separate system that uses the same design. So anything along the lines of global layers would be a major project with many difficult complications and a high chance of accidentally breaking other things.

    I think the easiest way to solve this problem might be some way to make batch changes across layouts - for example if you add a layer "Background2" above "Background1", have the option to repeat that change for every layout in the project that has a layer named "Background1". There would need to be something similar for renaming, moving, and deleting layers, and perhaps also an option to copy a layer's properties over all the other ones in the project with the same name. However it would be a tiny fraction of the work and complexity of anything involving global or "template" layers. Would that do?

  • Global layers are intended to solve this problem. Using a global layer covers all content and properties of a layer and allows propagating those changes to other layouts automatically.

    Global layers do not themselves cover adding and removing layers, as if you add a new global layer, you need to go and add new override layers in all the layouts that use it. But there is another approach using sub-layers: if you have something like a set of global UI layers, you can make one global UI layer and add all your other UI layers as sub-layers of that. Then if you make any change to the sub-layers, such as adding a new layer, those changes are automatically propagated to all other layouts.

    Here's a project demonstrating that approach: global-layers.c3p

    If on SourceLayout you add a new sub-layer UISub3 and place a Text object on to it, then switch to InheritingLayout, it has automatically updated with the new layer and content. So perhaps that's a decent workaround.

    FWIW, the design of global layers looks straightforward and seems obvious, but in the end it wasn't actually a great design. It has ended up extremely complicated internally and is an endless source of difficult bugs. Touching that code in any way is very difficult and feels dangerous, which makes us wary of further modifications. Then any further requests to change it have to be balanced with the constant 5+ years of work of other suggestions. So if you can get by using sub-layers of a global layer, that would be the best approach for now.

  • I don't think this is a straightforward thing to do. It violates a fundamental security property that only the addon author has permission to update their own addon. Further, we absolutely do not want to allow people to submit new addons with the same ID as existing SDKv2 addons, as that will result in compatibility nightmares. So even if we only allow submitting an SDKv2 addon with the same ID as an existing SDKv1 addon, that author has then "claimed" the SDKv2 addon ID and nobody else can publish a new SDKv2 addon using that ID. So if someone uploads a partial port of an SDKv1 addon to SDKv2, then abandons it, it's still the case nobody else can publish a new and better port of the original SDKv1 addon. It even opens up the possibility someone could claim a popular, un-ported SDKv1 addon, develop a malicious addon as an SDKv2 port, and then have the auto-updater distribute the malicious addon to everyone. Installing an addon from one developer doesn't mean you inherently trust another developer.

    Meanwhile I think it's reasonable to say you should have the consent of the original addon developer before publishing an update to their addon, especially if it was not originally published under an open-source license, in which case obtaining their consent is likely a legal requirement. If you can reach them to get their consent, then presumably you can also send them your SDKv2 port and ask them to publish that for you. Another problem is if another author does an SDKv2 port, and then the original author turns up and does an SDKv2 port for the original addon, which should the addon auto-updater choose? Duplicating addon IDs fundamentally creates an ambiguity which then causes follow-on problems like that.

    So I think this is in the category of things that sounds obvious but actually has a bunch of complications. It is the original addon developer's responsibility to update their addon, and users only have implied trust in the original addon developer and should not be assumed to trust some other developer updating their existing addon. Outside of that, distributing unofficial ports separately, at your own legal risk, and at the user's risk if they choose to use it, at least avoids the problems caused by allowing other authors to essentially overwrite or duplicate other developer's addons, possibly without their consent.

  • Thanks for informing us Ashley, and for the workaround! Very odd that it only detects the single gamepad input.

    The problem is actually that sometimes it detects a single physical gamepad as two gamepads, in a way that is impossible to distinguish from actually connecting two gamepads. So until they fix that, there's no way to tell apart one gamepad incorrectly appearing as two gamepads, or actually having two gamepads. Our workaround is to only support the last connected gamepad so this doesn't cause a problem.

  • I just want to update this thread with the latest from the r472 release. Unfortunately we have been waiting for some time now for the underlying WebView2 bug to be fixed. To help get us by for the time being until it is fixed, there is a new workaround in r472 for Steam games: the Gamepad plugin now includes a wrapper extension (scirra-gameinput-x64.ext.dll) to directly read gamepad input from the modern Windows GameInput API and send the inputs to JavaScript bypassing WebView2. Essentially it's our own custom C++ implementation of gamepad input to work around this issue.

    For non-Steam games, you can still use the workaround described earlier in this thread: add "allow-host-input-processing": false to package.json, and also delete scirra-gameinput-x64.ext.dll from the exported files, since if it exists it will use the GameInput workaround which has some limitations (described below). This should restore gamepad input using the fully-featured browser built-in Gamepad API.

    For Steam games you cannot set "allow-host-input-processing": false as it will break the Steam Overlay. Instead you can now use the GameInput workaround, which is used by default for all Windows WebView2 exports. GameInput should have good controller compatibility as it is a superset of all prior input APIs, covering XInput, DirectInput, Raw Input, HID, and WinRT APIs - for example I have successfully tested both Xbox controllers and a PS4 controller (which was not historically supported out-of-the-box on Windows). Note however the GameInput workaround currently has a couple of limitations:

    • Due to a GameInput bug currently only a single gamepad is supported. Input from multiple gamepads simultaneously is not supported when using GameInput - the only active gamepad will be the last connected one.
    • Haptic feedback (rumble) is not currently supported
    • GameInput should work out-of-the-box on some Windows systems, but you need to install the GameInput redistributable installer to guarantee support. This can be made part of the install process for Steam.

    To get the GameInput redistributable installer, download the GameInput NuGet package (click 'Download package' on the right), rename .nupkg to .zip, open the zip, and extract redist/GameInputRedist.msi. This is the file that needs to be run as part of an install process (or locally for testing purposes) to ensure GameInput support is available.

    GameInput diagnostic messages are logged to the browser console, so you can check there to see the status (such as whether it loaded OK and which devices its detected, or any error messages).

    Remember if you test with app ID 480 (Space war) you may need to disable Steam Input in its settings until you get your own app ID. (This is just because of the configuration of Space war and isn't really anything to do with GameInput.)

    I appreciate GameInput isn't as straightforward as using the built-in support but the idea is this will provide basic support for gamepad input until the WebView2 issue is fixed, at which point we can delete all the GameInput code and just go back to using standard browser-based Gamepad API input like everything else uses, and then we won't have to worry about any of this. So hopefully this helps in the mean time.

  • I did test this after making the change and it looked like it was working correctly for me. If you think anything isn't working correctly, please file an issue following all the guidelines. I need all that information to be able to look in to it.

  • Most of Construct's exported content goes in the 'www' subfolder, so you should be able to overwrite that with files from another iOS export and have it update. Do not use a different export option though, as the generated files depend on the exporter. I'd also warn you that many types of changes will change other exported files, such as changing various project settings, adding/removing certain plugins, and so on. So I'd still advise a full export periodically just to make sure everything is fully up-to-date.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This approach is not supported. Use Construct's Android export option instead.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,823,603 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs