Ashley's Forum Posts

  • Closing as not a bug, sounds like you just erased the plugins folder and needed to reinstall them.

  • Can't reproduce here, works fine in Chrome and Firefox. I doubt there is anything we can do about this anyway since Construct 2 does not have any control over the browser window layout - it's the browser that decides what to do about "request fullscreen". Consider reporting it directly to the Chrome developers.

  • Closing as can't reproduce and report is not actionable.

  • This is an incredibly difficult problem, since the gradient of the floor is changing. The platform behavior can only climb slopes of a certain increment and to be realistic it should "slide off" if it gets too steep. However the platform behavior does not actually know the gradient of the floor it's standing on, since slopes are handled only while moving. The platform behavior is already extremely complicated as well, with the ability to handle rotating gravity, jump-thrus and more. So I'm afraid I don't think we will fix this.

  • The Browser object just returns what the browser says the screen width and height are, so I'm not sure we should change it to deviate from what the browser says. Arguably it is correct: the physical screen is not actually changing size when you change the orientation, just the display mode. I guess it's more like "return the physical size of the display". So closing as won't fix.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Closing, please follow the bug report guidelines (attach a .capx, test the latest build, etc.)

  • Closing, please follow the bug report guidelines or we cannot help.

  • I can reproduce, but this does not appear to be a regression and we're due a stable release, so I will postpone a fix until the next beta cycle.

  • I can reproduce, but it doesn't appear to be a regression so I won't do anything before the next stable release which is due soon.

    However I'm not sure it's really a problem in practice: it fires 'On start of layout' to switch to the correct layout just before actually loading the savegame state, so anything the 'On start of layout' event does should be reverted by the subsequent loading. Is this a problem for a real-world project of yours?

  • Closing, please make sure your bug reports are reproducible (this means including the video file you used - I cannot reproduce what you are doing without it)

  • Sorry, there's not much we can do about reports like this. Firstly it sounds like a graphics driver bug, so check your drivers are up to date. Also the longer you leave a bug report, the harder it is to resolve - r153 was well over a year ago and it makes it hard to know what kind of changes could have impacted this. If you definitely have the latest drivers, I'd recommend reporting the problem to your graphics vendor. If you have a dual-GPU laptop, it may be worth using the control panel to try setting C2 to use the other GPU.

  • OR blocks actually pick instances that met any of the conditions. The | operator is simply a logical OR that returns 0 or 1, based on if either operand was true (nonzero). So if you have "health = 7|8", then 7|8 is evaluated as "true OR true", which results in true, which C2 represents as 1, so it's the same as saying "health = 1" which probably wasn't what you intended!

  • As far as I can recall, I don't think plugins had control over that kind of capability.

  • This is an advance notice of something which is likely to eventually happen in the long term (probably at least 6 months away).

    The C2 runtime ships with jQuery. In 2015, this is really no longer necessary. The browser DOM APIs have very good standards compliance and consistency across platforms, meaning you can often simply make direct DOM calls instead. See http://youmightnotneedjquery.com/ for lots of good examples.

    jQuery is also slow. We've worked to minimise the performance overhead of using jQuery in the runtime, but it's still a very easy way to do something expensive per-frame and that will cause a significant CPU usage increase, and is especially taxing on mobile. Direct DOM calls are sometimes cheaper than equivalent jQuery calls, and can be easier to optimise (e.g. eliminating redundant calls). I am of the opinion that these days jQuery has no place in a high-performance game engine.

    Removing jQuery also reduces the download size and complexity of the C2 engine. Removing it could actually improve compatibility in some cases, since we support some platforms which jQuery was not designed for and therefore causes problems.

    So while nothing is likely to happen for a while, please do not write any new plugins that make jQuery calls, since it may be difficult to update when we eventually remove jQuery. Also if it is feasible, please consider removing any use of jQuery from existing plugins.

    We may have a compatibility fallback where jQuery is included only if the project uses plugins that need it, but this cancels out all the above advantages of removing jQuery, so even if that happens it is still best to remove jQuery where possible.