Ashley's Forum Posts

  • You do not have permission to view this post

  • In normal usage of Construct, it should be impossible to save a project with invalid expressions.

    If you do something like addon development and make a mess of a project, e.g. by saving it with one expression, making breaking changes to the addon, and then trying to open the project again... that's kind of on you!

  • I realized this is confusing and renamed it for the next beta to "set min/max delta-time", as that better describes what it does - it's essentially a clamp on the value of dt.

  • If you're using a local server for addon development, and you end up in a mess, the easiest way out is to clear browser storage (which has the effect of uninstalling all addons).

  • It's expected. In general as a dynamic language like JavaScript, it is not possible to identify exactly where all properties are consistently used and automatically update them. You can use a text-based find-and-replace but you should review every match to make sure it doesn't update something incorrectly.

    One of the benefits of Construct's object model is it can rename things for you automatically and exactly (except where string "by name" references are used). TypeScript also uses static typing and tools like VS Code can use "Rename symbol" which should help.

  • The general coding standard is properties and functions beginning with an underscore are private, and anything else is public. To follow that convention, this._worldInfo is a private property that the class itself can use, but outside callers can use GetWorldInfo().

    Honestly, JavaScript performance is so outstanding these days that worrying about references/GC is very likely premature optimization and a waste of time. These days I ignore all that stuff for engine code and 95%+ of the time it works out fine. The main problem is people underestimating how good the technology is. See the manual section on Performance tips most of which applies to JS coding too.

  • If you are looking at the code in Construct's built-in behaviors, all of that is considered internal details for support purposes, and we won't provide any support for that or answer any questions about them. It is not intended that anyone looks at internal code, and internal code can change at any time for any reason, including completely replacing it.

    Many of the behaviors are also pretty old (with code originally dating back 10 years or more), and as anyone who has dealt with codebases over that period of time can advise, such code is often full of odd quirks, compatibility changes, and other weird stuff, and so I would strongly caution against trying to infer what kind of code you ought to be writing from internal code.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Event blocks don't really have a JavaScript equivalent. They are a different paradigm and are exported as data which the engine interprets. There are lots of JavaScript examples in Construct though which show how you can build various types of things with coding - filter by the 'Scripting' tag in the Example Browser. Ghost Shooter Code is a good one as there is also an event sheet equivalent example (although you'll see they're quite different).

    Both your code snippets include syntax errors. I would strongly recommend going through the tutorial series Learn JavaScript in Construct which covers the basics and should help you avoid these mistakes.

  • You probably want to use the 'Move to' behavior instead of timeline movement. You can tell the behavior to move along a timeline and then it moves through the points at a fixed speed instead of on the timing schedule, as in the Move along path example.

  • I think loader layouts are designed to be shown while the project resources are downloading in a web export. With an offline export like NW.js or WebView2, all resources are available locally with no need to download them, so I think in that case it skips any loading phase and just assumes everything is available, and so there is no load time (at least in the perspective of the engine).

    So in theory as long as the first layout is small (i.e. does not load loads of images), it should load quickly.

    PMs were used for abusive purposes including spam, and moderating them means the team looking at people's supposedly private communication, which creates some fairly difficult data privacy/regulatory/legal problems, so we removed them.

  • I think the answers to these questions depends on Microsoft's policy for Xbox publishing, and so you'd have to talk to them about it.

    If by lag, you mean network latency, then that is determined mainly by the quality of the Internet connection. Reducing the amount of data synced will reduce the bandwidth transmitted, but that does not make messages travel faster, unless perhaps you were swamping the connection with more data than it can handle.

    Scirra's signalling server has been running for several years now and should continue to do so for the foreseeable future.

  • Also, why not just simply refer to: 

    > 	this._worldInfo

    In the documentation that property is not documented, and so for support purposes it does not exist. If you use it, it could break at any time (e.g. if we rename or rearrange some stuff in the engine, which we do occasionally). So you should only call this.GetWorldInfo().

    You could cache the return value of that yourself, but I don't really see any point in doing that.

    Supporting mobile apps generally requires annual updates to comply with the latest publishing requirements. As Construct 2 was retired in 2021 it is no longer being updated and so will only fall further behind the latest publishing requirements, which likely makes it infeasible to publish mobile apps any more. You can of course upgrade to Construct 3 which fully supports this and continues to be updated to support the latest publishing requirements.