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.
Required information
Your report must include the following information or it will be closed without investigation:
- Attach a project demonstrating the problem
- The steps to follow to reproduce the problem in the project
- What you expected to happen
- What you observed happening instead
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.
example.com/myproject.capx
or
h*t*t*p://w*w*w.example.com/myproject.capx
If you are reporting a bug in the editor itself, a .capx file can in some cases be unnecessary. 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.
Community guidelines
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. For more details please refer to the Forum & Community guidelines which also apply to bug reports.
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. Sending us your entire project is usually not actually helpful. The guidelines require a minimal project with the fewest events and objects possible. Preferably you will be able to demonstrate the problem by creating a new empty project, and adding the minimal events and objects to show what is happening. This is the only practical way for the developers to diagnose the problem. Projects with hundreds or even thousands of events or objects are a nightmare to test because there is so much going on in the engine and it is almost impossible to isolate which part is potentially going wrong. Further, a very significant proportion of bug reports are simply mistakes in events, and not actually bugs. Spending hours or even days debugging a huge project only to find it was a mistake in the events is simply too costly to our developer time, especially as we are a small team. Everyone wants the developers to get back to writing new and exciting features instead! Generally if you cannot reproduce the problem in a new empty project, that is a strong sign it is really just a mistake in your events, so this is a good way of filtering out mistakes from bug reports.
In your minimal project you can also easily use placeholder graphics instead of your actual artwork. This also removes any concern about copyright or having to sign NDAs. So it's better for both you and the developers.
I can't reproduce the problem in a new project. What should I do?
This is a strong sign it is most likely a mistake in your own events. First of all, carefully review your events and make sure they are working correctly. Secondly, start isolating the problem. Back up your project and start deleting away chunks of it. At some point the problem may go away, which indicates the cause was in the last thing you deleted. In this case, go back and start removing smaller parts, and so on until you can identify exactly what is causing it. If it looks like a bug, use this as a starting point to demonstrate the bug in a new empty project. If the problem does not go away while you delete away content, you should be able to delete everything down all the way to a minimal project with no unnecessary events or objects. If you are sure the problem is a bug and not a mistake or misunderstanding of the events, then you can submit this project in a bug report.
Why haven't you responded to my bug report yet?
We do look at every report, but developer and release schedules mean we may not get round to it immediately. Please allow a few weeks for it to be investigated. If you are waiting, you can improve the chance it is resolved when a developer does get round to it by carefully reviewing these guidelines and providing as much useful information about the problem as possible. If you are missing anything, you may end up waiting a few weeks for a reply simply asking for the missing information, and then you're back to waiting again.
How do I report bugs in browsers?
Some bugs may conclude as really being bugs in the browser or platform, rather than being a problem with Construct. This includes any problem where the browser itself crashes or does a "sad tab" (where the tab replaces its content with a message saying it encountered a problem or crashed and you have to reload it) - Construct's code cannot normally cause this, only problems with the browser itself. You may be asked to report the problem directly to the browser maker instead. Here are the links to report problems in browsers:
Chromium (Google Chrome, NW.js, Cordova on Android): crbug.com
NW.js (issues that happen in NW.js only, and not the other Chromium-based platforms): NW.js issues
Firefox: Mozilla Bugzilla
Edge / Windows Store apps: EdgeHTML issue tracker
Safari (Mac, iOS, Cordova on iOS): WebKit Bugzilla