• The majority of reports are not actually bugs

    Most bug reports turn out not to actually be bugs in Construct 2. In one release, 85% of reports did not require changes to Construct 2's code. Very commonly it is a mistake in your events, a misunderstood feature, or intentional design for reasons the reporter is not aware of, or the report does not follow these guidelines and is therefore impossible for us to investigate so is closed without any action being taken. This places an unnecessary burden on developer time and also wastes your time.

    By now Construct 2 is mature and well-tested software; you must be rigorous to prove that something really is a bug. Please read all these guidelines and follow them carefully to help save everyone's time by making sure what you are reporting is a genuine problem.

    Use the bug report template

    When pressing 'New topic' in the Bugs forum, the post text will have a template with information to fill out about the bug report. Don't delete the template - fill out everything. We need all that information, and your report will be closed if you ignore it.

    Testing every browser is an important part of diagnosing the problem. Please test across every major browser (Chrome, Firefox, IE, Safari if possible) and indicate if they are affected by the problem. You should still do this even if you are using NW.js. Omitting this information can make it more difficult or take longer to fix the bug.

    A .capx file demonstrating the issue is required

    If you do not include a link to a .capx file demonstrating the problem you are reporting, your report will be immediately closed without being investigated. This requirement was introduced because it is very common that the developers are unable to reproduce your problem at all unless you provide an example. This makes it quicker and easier to fix the problem, which benefits everyone.

    Your .capx should be a minimal project made from scratch demonstrating the problem with as few events and objects as possible. Either build it from a new empty project, or delete everything you can that does not directly relate to the bug.

    Do not use third party plugins in your .capx file. This is necessary to prove the problem is not caused by another developer's code, which Scirra can't support.

    Don't say "it's a simple bug which doesn't need a .capx". Your report will still be closed. We deal with thousands of bug reports, many of which are useless, so we enforce this rule strictly to minimise the amount of pointless work.

    To save a .capx file, click "Save as single file" in the File menu. If you need a host, put it on a free Dropbox, OneDrive (formerly SkyDrive) or Google Drive account. We are unwilling to use file hosts which require an email address to be entered, and services which throw up loads of ads or make us wait for a time limit test our patience; use one of those three linked services which are all free and allow immediate downloads.

    Due to heavy spam on the forum, we have to block the posting of links for new users. If your link to the .capx is blocked, either remove the http and www parts, or insert * characters through them, e.g.




    If you are reporting a bug in the editor itself, a .capx file can in some cases be uncessary. However if including a .capx file could in any way improve the report or save time, then it will be held to this rule.

    Please only test the latest version of Construct 2

    Often bugs are reported which have already been fixed. Please make sure the problem occurs on the latest beta release.

    If you are reporting an issue that has been occurring for a while, it is also very useful to indicate the first release where it started happening.

    Don't troll the developers

    Our staff are here to help you. We have experienced engineers who have dealt with thousands of bug reports. The vast majority of reporters are helpful and are happy to work with us. However if you don't co-operate or are unnecessarily combative in dealing with staff, we will close your report and stop investigating it. We will resume investigation on the report if someone files it complying with the guidelines.

    The following list are behaviors we will see as trolling. If too many of these behaviors occur in one report it is liable to be closed.

    • Insisting developers investigate the issue over holidays or weekends. Please be patient.
    • Repeatedly nagging developers to investigate an issue ahead of schedule, or repeatedly bumping the thread.
    • Exaggerating the impact of an issue, or otherwise acting as if your issue is so serious, it is the end of the world. This is rarely the case, especially if the issue is not new. Diverting attention can also end up postponing work on other genuinely more serious issues, harming other users. It is also unnecessarily aggravating.
    • Constantly treating the developers with scepticism or distrust. We are not perfect, but we are experienced engineers. Please have a little faith. Sometimes we discuss the issue and make educated guesses. However there is no need to try to argue us down every time we say something; it is simply a waste of everyone's time.
    • Throwing in unrelated bugs or gripes. Please don't muddy the waters by talking about unrelated issues, complaining about why your favourite feature is not implemented yet, etc. Fixing a bug is difficult enough as it is, and having a concise, focused approach gives us the best chance of fixing it.
    • Blaming us before the issue has been fully identified. All software depends on a wide range of third parties, such as OS developers, compiler and library authors, driver developers, browser makers, and so on. We do routinely fix or work around issues which are not directly our fault, in order to try to make sure Construct works as well as possible. If we point to a third-party cause, it does not necessarily mean there is nothing that can be done about it, although it may make it significantly more difficult. Our normal routine investigation simply involves identifying the root cause before we proceed to mitigating it. There is no reason to launch in to a rant about how it's our fault. Often this is simply incorrect and may also cause embarrassment.
    • Demanding a resolution when none is practical. Some issues will have no good resolution, such as an issue caused by a specific graphics driver version on a particular OS and hardware combination. It is not feasible to investigate such issues, particularly if the evidence suggests the problem is not in our code. It is also unreasonable to demand an explanation of the inner workings of these other pieces of software we've had no part in developing.
    • Accusing us of not responding or not caring about the issue, particularly after we have already put effort in to responding or investigating it.
    • Arguing about whether or not what you did qualifies as trolling or not ("meta-trolling"). It is up to the judgement of our staff.

    Bug report FAQ

    Why did you close my bug report?

    You need to provide all the information requested in the template, and follow all the guidelines in this post, for the developers to actually have a reasonable chance of being able to diagnose and fix the problem you are trying to report. We get a large number of bug reports and dealing with them can be very time consuming. In order to save the developer's time so they can spend more time writing new and exciting features, and to save your time so you don't write useless reports which aren't useful to the developers, these guidelines are mandatory and reports not following them will be closed without investigation.

    You closed my report without investigating it. I'm offended!

    Please do not be offended; we deal with large numbers of bug reports and our aim is to deal with them as efficiently as possible. We want to make sure you get in to the habit of filing useful, detailed, actionable bug reports which we can diagnose and fix quickly. This benefits you as well, since you are more likely to get your bug fixed, and sooner. So it is in everyone's interest that you learn to follow the guidelines to the fullest extent possible for every bug report. We may unceremoniously say that it is closed without investigation, but that is probably one out of 10 or 20 that day, and we want to highlight how you need to help us help you.

    My report was closed for not following the guidelines. What should I do next?

    Please do not reply to closed bug reports. Closed bugs are not monitored and even if you reply to add more information, it may be missed. Instead, please file a new report, and make sure you follow all the guidelines and provide any missing information.

    Do I need to share my entire project? I have copyright concerns.

    No, we don't want your entire project.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)