Ashley's Forum Posts

  • Closing as by design. This has come up a few times in the past and it's not feasible to change it.

    The problem is the event system is nested, and internally the engine will be half-way through iterating the instances list while running various aspects of an event. Creating a new instance adds a new instance to the instances list, and destroying an instance removes it from the instances list. Modifying these lists while they are being iterated for running events causes bugs and crashes, because it's unpredictable to modify a list while you're simultaneously using it. A long while ago user's projects were crashing because of this problem, so we made this change intentionally to fix it. The end of top-level events are the only safe place to actually update the instances lists, because they are guaranteed to not be in use at that point. After top-level triggers also counts, but not functions (or other triggers fired from inside conditions/actions/expressions), because then you're still nested inside another event.

    Note that creating works the same as destroying, i.e. a destroyed instance does not really stop existing until the next top-level event, although this tends to be less of a problem.

    Working around this from within the engine would degrade performance for all projects, because it would mean every loop inside the engine that deals with instance lists has to have a per-iteration check to see if the instance list was changed while it was looping, and then do extra work to mitigate that. Not only does this slow down everything (particularly tight loops which do little work), it is also a very complex engineering project that would probably take months and involve a whole load of follow-on bugs and further corner cases that need fixing. I really don't see that as a reasonable thing to do when it will also degrade performance everywhere, just to fix a slightly weird corner case which is possible to work around, so this is not something I think we will ever change.

  • Closing as not a bug. You must still specify the return type flag with the deprecated flag, which is what the error message is telling you. Otherwise you are saying the expression is hidden and has no return type (which affects projects that still use it).

  • I already had a lot of experience with it from Construct Classic, so as R0J0hound suggested it made sense to stick with what we knew. Also at least at the time the whole .NET thing made the installation a bit more complicated and could have meant lots of users having to do large .NET installation updates, probably would have meant dropping XP support, and other implications like that. (Remember this might not be a big deal now but we were deciding in ~2010.) C++ apps are nice in that they can be set up to run on a brand new computer/OS install with no extra config, which is a nice benefit for a tool aimed at non-technical people.

  • Just file what you've put here on the NW.js bug tracker, describing how the NW.js process does not close. I could report it for you but in the past I end up just being a middle-man between you and the NW.js developers, so it's more efficient to just report it directly. If you're asked questions about C2 you don't know the answer to, you can tag me on github as

  • Plugins are also stored in your %appdata% folder. If any of the official addons caused this message, everybody would be seeing it, but only you are so it must be a third-party addon in %appdata% which you have not cleared.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Okay, I think I found that there was a mistake in our build script, where it was copying the 64-bit audio tools for the 32-bit build. This meant our previous attempts to update the 32-bit audio encoders did not work. I've corrected it for the next build so hopefully it will (finally) be OK there.

  • Actually I can't reproduce, the provided demo works fine for me. Also the .capx file uses third party plugins which is not allowed in bug reports - please read the bug report requirements - so closing.

  • I can reproduce, but it's clearly an NW.js bug, not Construct 2, so please report it here: https://github.com/nwjs/nw.js/issues

    If the issue is specific to NW.js you can save time in future by reporting it there directly.

  • More of a feature request, but straightforward to add, so it's in the next build.

  • This is by design and documented:

    [quote:7bapmfwb]Note: backups are only made when pressing the 'Save' button. Simply opening a project that somebody has sent you will not make a backup for it unless you modify it and click 'Save'.

    In other words, autobackup means "upon save, make backup if time since last backup is longer than the interval given". Autosave is meant to be the mechanism to trigger that on a regular basis automatically without having to press save, so closing as won't fix.

  • Can't reproduce here - I have dual-monitors running Windows 10 and windows always appear on the last monitor you left them on, which is by design. I tested with the image editor and it can open on both monitors just fine, always appearing in the last place you left it. Note if you drag the main C2 window to a different monitor that doesn't automatically mean all other dialogs will appear on that monitor, but you only need to drag them across and their position will be remembered too.

  • Fixed in the next build.

  • Can't reproduce, works fine here. Maybe try updating your graphics drivers?

  • This is always caused by buggy third party plugins. Closing, please check which third party addons you have installed.

  • Which versions of NW.js have you tested?