Ashley's Forum Posts

  • In that case I would assume the user will call a "Pause" function where they implement their pause system in events. If your addon needs to do something to respond to a pause, this can then just be a "set paused" action in that function.

    I think if you try to pre-empt it with different built-in mechanisms, you actually end up with a less flexible approach. Events are the way to customise your game's logic, addons shouldn't try to short-circuit that.

    If you're integrating with your own addons, I'd recommend simply calling internal class methods instead. There's no need to drag the event actions logic in to it. A nice architecture (which many built-in addons use) is actions actually just call methods on the instance class, and then any other logic that needs to re-use that function can just call a normal instance method, rather than trying to bodge in a call to an action. Basically for internal stuff you can easily bypass the entire event system, and it makes your code nicer.

    Lots of addon developers seem to want to hack around with the event system - generally I think that causes more problems than it solves...

  • If you are developing an addon in developer mode like the SDK documentation recommends, you can also simply fix the problem and reload the editor.

  • I assume you're still using the C2 runtime? The C3 runtime doesn't support IE.

    Storage in the C2 runtime should work on IE. If it doesn't, please file a bug following all the guidelines.

  • This is specifically not supported because it's generally a terrible idea:

    • Nothing else in Construct works this way, so it's confusing to users
    • It hides logic behind "magic" behavior when it could be clear and straightforward events
    • It's brittle and inflexible because it has a hard-coded kind of action/condition to trigger - the user can't choose to do something else, or use a different kind of plugin
    • When using other addons, you end up taking an unnecessary dependency on an external addon - now you're subject to any backwards-incompatible changes or deprecation that may happen to that addon in the long term

    In particular, the last point is problematic - sometimes developers hack in poorly-thought-out features involving official addons, then we change them over time (e.g. deprecating them as we replace them with better features), and now the addon developer has a real headache as they need to figure out how to change their addon, which may in turn cause a backwards-compatibility problem for users of their addon.

    Just fire a trigger in your addon. Users can put whatever events they want in that. It's simpler, and avoids all these problems.

  • Updated the original post with new downloads based on Chrome 74 (NW.js 0.38.0).

    • Post link icon

    Closing, you already posted this here: https://www.construct.net/en/forum/construct-3/general-discussion-7/someone-know-delta-time-143453

    Please do not make the same post multiple times.

  • Broken third party addons are only reported in beta releases. I assumed addon developers would test with beta releases... I was wrong.

  • FYI this is how the URLs work:

    editor.construct.net - latest stable release

    editor.construct.net/beta - latest beta release (redirect)

    editor.construct.net/r123 - specific version

  • See the tutorial Delta-time and framerate independence. Please also only post in English on the forum.

  • Fengist - that sounds like the same case as discussed here. Presumably you're visiting editor.construct.net?

    It would be useful to remember: beta releases are never served from editor.construct.net - that only serves the latest stable release (which is what the typical user will want). If you want to be using a beta release you must have the release number in the URL, e.g. editor.construct.net/r146.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This is caused by broken third-party addons. Try uninstalling any addons you have and reinstalling them one by one. You'll need to report the problem to the addon developer.

  • Isn't this what the comments feature does?

  • Scope is designed to work like it does in programming languages, and in fact actually helps you to organise variables too. If you put a variable in a group (or sub-event) it is only accessible to events in that group. So in many cases you can move a variable to just the section of events that uses it, and it avoids clogging up the project with more global variables. If you enable the "static" option for local variables then you get a locally scoped variable that remembers its value like a global variable. So you can organise variables so they're only scoped where they're used and the top-level global variables are just the few variables that truly need to be accessed by events all over the project.

  • What is the point of the website remembering what version the user is on?

    So it can give you a more useful message. If you were on r130, and then you reload C3 for the first time in a while, it can say something like "you were on r130, and you got updated to r146". Now you know to check all the intervening release notes, if you want to stay up to date with all changes since then.

    If there was a person that wanted to stay on r142. They would nav to editor.construct.net, get a message that the new version is release 142.3, then they would need to go to the address bar and type out editor.construct.net/r142 - then remember to go to that address every time they use C3.

    The approach is based on the principle that most users will simply want to use the latest stable release, so it's geared towards that. The typical user will just type in/visit editor.construct.net, and if you do that, you're always using the latest stable release, which seems like a sensible default.

    It's also our goal to make sure there's never a good reason to stick with old versions. Every update fixes a lot of bugs and we strive to maintain excellent backwards-compatibility. For the typical user, not being updated causes more problems than it solves - they typically end up running in to bugs we've already fixed (and sometimes reporting them, where all we can do is point out that we already fixed it, and they are causing problems for themselves by staying on old versions). So staying up-to-date is an important part of the UX, so people always get the best-quality software currently available. I think if we give everyone an opt-out of updates, rather than applying them automatically, it will result in a worse UX as a greater number of users run in to problems that have already been fixed. Modern software like Chrome adopts a similar approach of silent auto-updates for the same reason.

    Of course software development isn't perfect, so sometimes people want to roll back - and you can do so simply by typing in the version number in the URL.

    I think you've misunderstood how the URLs work, and presumably as a beta user you have more interest in rolling back versions occasionally. This is straightforward, since you can just type the version in the URL. If you visit editor.construct.net you're getting the stability-focused general consumer version. I am pretty confident that is the right approach for the majority of our users. If you opt in to beta releases I think you just need a little awareness of what the URLs mean, and then you can switch between versions at will.