Before writing a bug report
What is needed for a useful bugreport
To make it faster and easier for us to reproduce your bug report we would appreciate getting following information from you:
How to write a good bug report
A good Bug Report (or BR) title is short and descriptive. It should tell the reader what the bug is, where it happens and in which circumstances it occurs. A good idea is to put the location or a keyword as the first word, so it'd be easier for BH's and QA people to sort through bug reports. Like "Exploration", "Chat" or "Mac".
Selects one of the high-level categories for the defect.
You can ignore the other options (for example "EVE - Not Now") in the drop-down list for the category.
Server / Build
Please select the server (Tranquility / Singularity / Duality), on which you found the bug. Selecting the server will give you a default build version, but this might be outdated, specially when using Singularity or shortly after a patch. You can find the build version in-game on the top left corner in the settings screen or in the login window.
Here you should give as many details as possible and describe the bug scenario in detail and all the circumstances in which the bug occurred.
A good description will save the developers a lot of headaches and make it easier to fix your issue quicker. For example, submitting a bug "War targets not displayed on overview" or "Cannot unfit launchers on ships" sounds very serious until you specify that it *only* happens if you select a certain option in the Overview or you have a certain rig fitted on your ship when trying to remove the launchers. It's important to give a measure of how severe the bug is and how wide its area of effect is.
Mention how often that bug occurs, if it's something that happens every time or just some weird occurrence that only happened once and couldn't be reproduced. It's important to know if it's a common issue that can easily happen or some kind of oddball exception.
For graphical issues please also specify your graphic content settings.
The most useful bug reports are those that have a good description as to how to reproduce the bug in a consistent manner. Try to reproduce the bug again and determine the exact steps you need to go through in order to make it happen again. Try to find the simplest method to make your bug happen. This section should outline how you made it happen, broken down into steps, numbered chronologically.
Try to make it very clear for anyone reading the BR just what exactly they have to do in order to reproduce the bug. The bug might seem fairly obvious to you, because you've experienced it firsthand, but if the reproduction steps are complicated try to make the steps as clear and complete as possible so that we can reproduce it ourselves and fix the issue.
The computer field is best left around and you should instead attach a DXDiag file to the bug report. If you're not on Windows and don't have access to DXDiag you can use this to type up the details about your computer. Remember to include driver versions.
Where to find the attachments
Saving a screenshot
Saving a DXDiag
Getting a logserver log
See the article about log server
Finding the crashdump
Check the article about reporting crashes.
More info, specifically regarding Pingplotter and Macintosh
If you have network problems (for example many disconnects) or you are running Eve on a Mac, check this article.
Restrictions (file size / type) for attached files
There is a limit on the file size of those files submitted with bug reports of 16 MB. In the need for larger files please use a 3rd party upload service and give the link in the bug report. For logserver-files please use server-mode to prevent too large files.
Please make sure that you always zip files of any significant size (over ~200 KB)
Please note that only following file-types are accepted in Bug Reports, for everything else use zip/rar: jpg, gif, png, txt, rtf, doc, lbw, log, zip, rar, pp2, dmp and mdmp.
You can also attach multiple files to a report. Submit the BR with one file attached and then add more files through the editing option. The report will be listed under 'Bug Reporting -> My Bug Reports'.
Report Bug ingame tool
An in-game bug reporting tool is now available to make it as easy as possible for you to let us know about bugs.
It serves the same function as the bugs website but better! You can find it in the help menu (F12) at the bottom: Report Bug
You enter all the information in the appropriate fields and send it on its merry way.
You have to provide your Tranquility account credentials which the tool uses to file that report on the bugs website in your name via a secure SSL connection.
If you want to continue your report later you can Save it (stored under your settings folder) and Load it again later via the tool.
You can attach up to three screenshots. The screenshot editor lets you add frames, arrows and text to a screenshot. You can take screenshots of modal dialogs by pressing CTRL+ALT+SHIFT+P.
You can change the color of the added arrows, frames etc. by right-clicking them in the editor.
The Report Bug feature attaches several files for you automatically.
These are the following:
In addition to file attachments the tool automatically writes information into the 'computer' field of the bug report as follows (the field is not shown in the tool but it the same as the one on the website):
In the case that you need to attach additional files you can do so through the regular website after you sent the bugreport through the ingame tool.
What happens to the bug report
After a bug report (BR) has been submitted it arrives on the list of currently open bug reports. The usual process is then that a bug hunter verifies it by trying to reproduce the problem. If the BR is missing some important details (like logserver, DXDiag, screenshots etc) and the bug hunter doesn't have enough information to try to reproduce it, the BR will be closed and sent back to the reporter, who is asked to fill in the missing details. The reported can then enter the new information and reopen the BR.
If a problem can be reproduced, the bug hunter will create a defect that is forwarded to CCP's QA department. They again will then assign the defect to one of the CCP departments, which will then be responsible for fixing the issue. After a defect has been fixed, it will be tested again on one of the test servers and eventually the fix will be applied to TQ in a patch.
If there is already an existing defect about this problem, then the bug hunter will attach the BR to this defect, to give the programmers all available information.
Other resources and tips
Top Contributors For This Page