Ashley's Recent Forum Activity

  • In practice browser engine updates breaking things is extremely rare. I can't remember a case since 2014. All of Construct's existing web, Android and iOS exports already rely on auto-updating browser engines and have worked fine year after year, and I expect the same to be true with WebView2.

    In this case the bug is caused by enabling the use of a newly implemented mode that allows the Steam Overlay to work. You can work around it by disabling the new mode as I described in my earlier post. So it's not a regression caused by updating the browser engine - it's a regression caused by us enabling a new mode, and the new mode having a bug.

  • What we want to do is develop reliable software that doesn't constantly break. Hopefully we can all agree that is a reasonable goal.

    When you allow third-party addons, that goal becomes a lot more difficult. If addons access internal code, it will sooner or later break, since software products are constantly evolving and sooner or later the internal code is changed. This means some future update to the product breaks things. The impact of this ranges from a mere inconvenience to a complete catastrophe with thousands of customers complaining and thousands of projects broken.

    The way the industry solves this is with two key principles:

    1. Provide a stable, public, documented API that developers can use. This allows substantial internal changes - even complete rewrites - while preserving compatibility so long as the public API still works the same.
    2. Use encapsulation to enforce that only the public API can be used. This prevents developers succumbing to the temptation to access internal details anyway, and still cause all the problems that the API was meant to avoid.

    This is all basic stuff in the software industry and it isn't remotely controversial. Go and use any other product with an addon system and you'll find it probably works the same, for the same reasons.

    With SDKv1 we were failing in our goal to make reliable software that doesn't constantly break. Therefore we moved to SDKv2 which uses the above two key principles, like the rest of the industry uses. I fully understand this is a painful transition, and it is not something we did lightly, but it is absolutely necessary in order to achieve the goal of making reliable software that doesn't constantly break. This also benefits addons! If you also want your addon to be reliable and not constantly break, it needs to follow the above two principles as well.

    I suspect perhaps some developers got interested in the ability to access internal details, and thought it was cool or useful. However that was only possible due to the historic weakness of JavaScript encapsulation, and if you do that, you will end up with unreliable software that constantly breaks. I am not sure everyone understands that point - some people seem to think they can just deal with it. That is misguided: it is a very real possibility that such addons permanently break at any time. Some people seem so convinced this is not true that they resort to being abusive to staff, which is unacceptable. People may disagree but they must abide by the Forum & Community guidelines. However I must point out that disagreeing is going against decades of industry-standard practice and consensus.

    If you wish to develop quality software and build addons that are reliable and work in the long term, it is also in your interest to use these principles. I don't know why any responsible addon developer would want to make an addon that they cannot guarantee to users will keep working and risks permanently breaking at any time.

    So far I've mostly just re-iterated the situation with SDKv1 to SDKv2, which mostly pertained to the runtime. This brings us to the editor and the prospect of SDKv3.

    The editor is not designed to have UI extensions. The entire DOM - all HTML, CSS, event handlers and so on - are considered internal details. They could change at any time, and that could break any addons integrating them. This brings us back to pretty much the same situation as SDKv1. Not only could such addons break the editor at any time - with the prospect of editor crashes on startup being particularly worrying - but we could also break your addon at any time, quite possibly permanently, and we won't provide support in that situation. Exacerbating the problem, we cannot actually just wash our hands of it and leave the addon up to you, because when things break, everyone comes and blames us and tells us to put back whatever we broke. Some people simply refuse to accept the fact it's not our responsibility, and forcefully insist that we fix it. This is a nightmare scenario for us, and we've had it with SDKv1.

    So I have to ask: do you intend to build reliable software that keeps working? If you do, you won't do this, because you can't guarantee to your users that it will keep working! In order to provide that guarantee, we need the above two principles: a stable, public, documented API, and encapsulation to enforce it. Neither exists for the editor DOM. We could in theory do this. However it is a great deal of work with its own maintenance complications, some of which I addressed in this post. So the next best thing is to at least use encapsulation to enforce that editor addons can only do supported things - hence the prospect of SDKv3.

    I am well aware of all the criticism aimed at us over both the move to SDKv2 and the prospect of SDKv3. However our goal is and always has been to make reliable software that doesn't constantly break. If we are to achieve this goal, the above two principles are essential. It does not matter how much people criticize us or how much other developers disagree about these points: this is unequivocally what it takes to develop reliable software that doesn't constantly break. I think some people perceive this as being overly controlling, but let me remind you this is how the rest of the industry operates.

    You might then ask: how are you meant to achieve this then? The answer I'm afraid is simply that you don't do that. It's not supported. Move on and invest your time and effort in something that is supported and will continue to work in the long term. Find some other way to solve the problem. For example instead of trying to integrate some tool directly in the editor, make it an external tool, and provide some way to import/export your work. I've seen some experiments with making a 3D editor that operate on that principle, and it is a good approach. You can do anything - absolutely anything at all - providing you stick to the public, documented, supported API features. There is plenty of scope to be creative and come up with cool and innovative features that abide by that. There is also scope to extend the supported editor APIs to better allow integrating with external tools, such as the existing Custom Importer API which was designed for importing work from external animation tools like Spriter. We can always do more in that direction, especially where they are thoughtfully designed relatively small but flexible features. Perhaps one less-bad option would be a supported option to open a popup window which can then show custom HTML and CSS content, and communicates with the editor via postMessage() - at least then the custom stuff is sandboxed within a separate window, it's still relatively flexible, and it's still a long way short of full editor DOM modification.

    If you disregard this and make addons that break the editor, then I will again feel that we are failing in our goal of making reliable software that doesn't constantly break. Therefore I will feel obliged to act on behalf of us and our customers to improve the situation such that we have reliable software that doesn't constantly break. That is why I would consider SDKv3 to enforce encapsulation for editor scripts too, even though it may be another painful transition. It's simply what is necessary to achieve our goal.

    I want to finish with an appeal for co-operation. Please consider everything I've written, and do what you can to work with us. If you ignore this and work against us, using unsupported features and ending up with things breaking, we will feel obliged to take steps to mitigate the problems caused, such as by enforcing encapsulation. If you co-operate and work with us on supported features, such as perhaps a popup window API that is significantly more reliable long-term, perhaps we can end up achieving both some degree of the features you want, while maintaining our goal of making reliable software.

    • Post link icon

    Your tutorial has been deleted due to being abusive towards staff members. See the Forum & Community guidelines. This thread is now closed.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The addon does not run any code on startup that relies on anything C3 does if that makes you happier

    I'm afraid it does not. Any CSS style, DOM change, or event handler could cause problems. Already a constant support headache for us is browser extensions making unexpected changes to the editor and causing crashes and bugs, even when they only tweak the DOM or CSS styles. Presumably the developer thought "this is a small, safe change that won't break anything", but they were wrong. It looks like you have over 2000 lines of code making similar kinds of changes. We can use encapsulation in JavaScript now, but HTML and CSS still lack robust encapsulation. With browser extensions we simply must suffer the consequences, but ideally we would not have to suffer that with third-party addons.

    What would you even do

    Sandbox editor scripts in ShadowRealms, when browsers support that. If editor DOM modifications are used widely and cause compatibility disasters, which I suspect would happen as this is analogous to the SDKv1 situation, then you should expect to see an SDKv3 which does editor script sandboxing. So my advice is: do not do this or anything like this at all - find some other way to solve the problem that does not involve that. Please: take a step back, look at the ways the industry has come up with over decades to ensure reliable software development, look at everything we already just went through with SDKv2 which was just re-learning those same lessons - let's not risk anything that might repeat that. Unfortunately from the SDKv1 situation I'm aware that such warnings are not always heeded, and I fear we're going to end up suffering the consequences anyway. So I guess I should start planning for editor script sandboxing...

  • Does it work when uploading with the Steam Devkit client? Last I tried that was working fine. If the problem was with code on Construct's side, that wouldn't work, but it was working for me. If it works with the Steam Devkit client but doesn't work after a web upload to Steam, then that would suggest the problem is with the Steam web upload process. (My best guess would be it's still the file permissions getting reset.) So that would mean you either did something wrong modifying the zip, or Valve need to look in to it.

  • I don't know if you are aware of this but I recently implemented my own editor UI API to fix this exact problem you're mentionning:

    I'm afraid this makes me quite nervous. This is not something we officially support and the editor is not at all designed to accommodate this type of thing. It risks repeating the issues of SDK v1. If we change Construct and suddenly thousands of people's editors are crashing on startup because we accidentally broke your editor UI API - something I'd say is likely, because we don't support it, don't know what it does, we don't have an officially supported API for it and so we don't know how to not break it - then we face disaster, and everyone will be contacting our support, and blaming us for releasing a broken update. I think that outcome is ultimately inevitable and there is no acceptable way to properly support it for commercial software that is meant to work in the long term.

    Editors crashing on startup is a worst-case scenario and prevents users even being able to update or uninstall the addon causing it. That is a nightmare scenario worse than we faced with SDK v1. It is such a serious outcome that we may well take steps specifically to prevent it, much like moving to SDK v2.

  • I believe you need to set the NSLocationWhenInUseUsageDescription string in Xcode, and possibly some others depending on the type of location permission needed. You can add this in Xcode by editing Info.plist (which might appear as just "Info"), adding a row, and then for the key there should be a dropdown where you can select "Privacy - Location When In Use usage description". Then you can put your description as the value on the right. As I mentioned there's a few other strings under "Privacy - Location..." so you might want to review those as well.

  • That's why I've been thinking of this as a special/dedicated layer (like the HTML one) with restrictions that don't clash with the existing high-performance 2D/basic3D engine.

    I'm not sure that would work well in practice. Suppose someone wants to drop a 9-patch object or Text object on to a 3D layer powered by a third-party library like ThreeJS. That probably involves two sets of rendering code depending on what they are rendering in, which is a pain for maintenance. Alternatively you just give up and say it's not supported, but now you have zones with different feature sets that aren't compatible, and you can't do something like decide to make an existing 2D layer in to a 3D one.

    Users using this "beta" layer would understand that they are in a "third-party" territory (as with HTML layers).

    In my experience users do not understand such things. Instead - not unreasonably - they expect things in a commercial product that they paid for to just work.

    I think this type of approach would be better explored via third-party addons, so it's not in the core product and can more easily be treated as an "beta" type technology that we don't support. So perhaps that's another direction we could explore, via exposing APIs in the addon/scripting system.

  • Integrating an existing 3D engine like ThreeJS is not a straightforward choice and has some tricky trade-offs. For starters, we've already gone quite far down the road of having our own engine, and it's probably a major project to switch to another engine wholesale. Making a high-performance 2D engine also has specific requirements that 3D engines don't usually need or care about, so it may be that it cannot be done without a major performance degradation.

    Taking on board a third-party dependency for such an important component is also fairly risky in the long-term. The intentions of the ThreeJS maintainers may not align with our needs. This is illustrated by the fact a while back when putting together that 3D engine integration example, I submitted a code change for ThreeJS - but the ThreeJS maintainers rejected it. We could maintain our own fork, but long-term that can easily end up being a nightmare. So the end result is we just live without it. In the long term that means the limitations of ThreeJS become the limitations of Construct. It may mean there is really interesting stuff that is basically infeasible to do due to depending on a third-party library for that. It's the kind of thing that in the short term speeds you up, but in the long term can become a hindrance.

    I'd compare that to Construct's user interface: with Construct 2 we used a third-party library. It saved time, but frequently people would request things, or run in to bugs, that we could not do ourselves, and sometimes the library developers wouldn't do either. For Construct 3 we could have saved time and moved quicker if we used some other off-the-shelf UI library - but we actually spend considerable time and effort implementing our own UI library. Over the years we've been able to adapt it to specifically what Construct needs. In the end I think Construct is a much better product for it.

    Libraries like ThreeJS are open source though, so we are allowed to use bits of it, or copy-paste chunks of their own code in to ours as we see fit, providing we comply with the license requirements (which for the MIT license is basically just including their copyright notice). I suspect a hybrid approach like that might be the way to go. As the 3D engine example illustrates there are also already ways you can include third-party 3D engines wholesale, so that's something you can explore as well, and perhaps there are also ways we can tweak the engine to better support that.

  • Does it work if you disable WebGPU? If so it might be a graphics driver bug - check for updated drivers and install any available system software updates.

  • Without knowing more and relying only on guesswork, I'd speculate that this is a browser bug then - presumably the browser has got stuck since if Construct actually started loading and then encountered some kind of error, something should have been logged to the console.

  • Maybe it is worth considering to make the C3 editor extendable by 3rd party developers instead.

    The problem is, stated like this, and to do a good job of it, is an absolutely huge, open-ended project with some pretty nightmarish maintenance considerations. For example in my view to do this properly, we'd need to expose to addons the entire editor UI library, such as tree controls, list views, data tables etc. so editor addons can make use of the same look-and-feel of the rest of the editor and not have to reinvent the wheel for things like a custom editor window with a tree view in it. Every API that addons can use then obligates us to effectively support it forever to avoid breaking backwards compatibility - especially as breaking something that causes the editor to crash on startup has a far higher impact than something that crashes the runtime on startup. In the long-term that can then become a drag on our ability to upgrade the core editor features.

    We could bypass that by just giving addons a window to put any old HTML in, but then you likely end up with a bunch of ugly addons with janky looking UI. Implementing quality user interfaces is actually extremely difficult and a great deal of work, and I don't think it's realistic to expect addons to do that for each and every addon. There are also likely going to be complicated compatibility problems anyway - the editor is designed to support only the built-in UI, and is not designed to handle arbitrary HTML injected by addons. There may well be glitches and bugs that happen because an addon inserts some HTML or CSS that does not integrate with the editor. People then assume it's our responsibility to fix such things, which ends up being a nightmare. HTML and CSS also don't have much in the way of encapsulation - although it's better now than it was a few years ago - and so we risk ending up in an SDKv1 type situation with regular breakages as future Construct updates change things.

    Then if you want to go in to further specifics, like customizing the Layout View, integrating with the undo system, etc. then you open further cans of worms with compatibility, API design and so on.

    So on that basis I would say rather than making an editor system to allow others to implement a 3D editor view, it is actually significantly less work and much easier to support for us to just implement the 3D editor view ourselves.

    Other than that, a better approach is to figure out what the smallest possible set of editor features you'd need to have fairly good flexibility for some useful editor features, and request that. For example to address the specific problem of being able to import complex content to the editor, like Spriter animations, we built the Custom Importer API with methods like AddDragDropFileHandler (see the customImporterPlugin sample for a demo). It is far more feasible to support specific cases like that than go for a whole open-ended editor addon system.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,762,066 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
  • x125
    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
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs