Ashley's Forum Posts

  • The browser runs your JavaScript code, not Construct. Switch-case is a basic feature that has been around for decades and if it was broken, significant portions of the entire web would stop working. So by far the most likely culprit is your code is wrong. It's hard to say more without seeing all your code.

    • Post link icon

    Are you reporting a C2 bug or a C3 bug? C2 is being retired next year and is only receiving critical updates now. C3 bugs should be filed here instead: https://github.com/Scirra/Construct-3-bugs

  • Can you identify which browser extension is the one that causes the problem? It would be useful to know in case anyone else runs in to the same problem. I could also look in to a way of notifying the developer, or working around the problem.

  • FYI someone posted an off-topic reply, it got a couple of replies, and then the original poster deleted their reply, so I cleaned up the thread to avoid it looking weird.

  • It's hard to say anything, it might be a bug. I'd suggest filing an issue following all the guidelines. We need all that information to figure out what's going on anyway.

    Do you have any browser extensions? Does disabling them help? Previews work fine for me here and the error is quite mysterious - sometimes browser extensions interfere with the page and break stuff.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's running identical code on both platforms, so it should work identically. If you think there is a bug, please file an issue following all the guidelines. It's impossible to help otherwise.

  • From the manual entry for 'Invoke download':

    Downloading is a browser feature and depends on the browser UI. Note that mobile apps don't run in browsers (there is no address bar etc), so the download feature isn't available there. Consider using the Share plugin to share the file instead.

  • I think we will need to update the library the editor uses to parse JS code to support the new syntax. This applies only for new features that involve new syntax and so need new code to recognise them. There might also be a lag time between browsers adding support and the library adding support.

    I wouldn't recommend using really new features anyway until all browsers and platforms support them. Otherwise you'll end up with a broken game in certain places.

  • It's not clear what anyone's actually seeing. Can someone share a screenshot? I'm not sure if it's Construct's own dimmer, or something the browser is doing.

  • The specific ordering in the engine is very complicated, varies depending on the feature, occasionally changes, and is the type of thing people really should avoid depending on if they can, so it's not documented.

  • Pathfinding should work in that case. It's not clear why it doesn't. Did you apply a cell border to make sure blocks don't mark adjecent cells as obstacles?

  • C3 requires either WebGL 1 or WebGL 2. For the purposes of Construct WebGL 2 is not particularly important; it will use it if it's there but there won't be much meaningful difference in how the game runs. (It might be a little more efficient sometimes, but that's about it.)

    WebGL 1 support is effectively ubiquitous these days, being supported on virtually all desktop and mobile devices.

    Coincidentally, there's a lot more background in this blog post I recently wrote.

  • Please note the manual specifically states not to use c3_callFunction from the scripting feature:

    Do not call this with Construct's scripting feature. It will not work correctly. In that context you must use runtime.callFunction() instead. This method only applies to external JavaScript.

  • Those aren't the same conditions though. On button clicked is totally separate from On button clicked on Sprite. I would fully expect that the engine would call all On button clicked triggers first, and then move on to On button clicked on Sprite.

    This is correct.

    The order of triggers is actually pretty complicated, especially if you start bringing in things like triggers in sub-events and triggers via included event sheets. I'd recommend wherever possible avoiding depending on the order the engine fires triggers, especially since it's not clear from looking at an event sheet what the ordering really is. Generally you can do this by just using a single trigger event to do everything in one set of actions/sub-events, so you can clearly see the order things are done within that event.

  • FYI the Pathfinding behavior uses the A* pathfinding algorithm on a grid. It's also massively more efficient in the C3 runtime.

    Generally so long as you have a reasonably large cell size and you're not using ridiculously huge layouts, it's pretty fast. The main cases people find it's slow is if they set a tiny cell size like 1x1, which forces the pathfinding algorithm to search through tens of millions of cells, which is really slow. The whole point of using a grid is to massively speed up the search by reducing the amount of searching that needs to be done.

    1. Does simply having Pathfinding assigned as a behavior to an object (enabled, but not actively being used) cause any considerable demand on CPU?

    No. It's only finding a path that uses CPU.

    2. Would destroying an instance of an object make a difference as soon as it's not needed?

    No, because of 1).

    3. Is a grid generated per object using Pathfinding?

    Grids are shared between all instances, but if you change the cell or border size, it has to create a new grid out of necessity. But you should not depend on that, it's designed to share the grid between all instances to make it much more efficient on CPU usage and memory.