Bug reporting

You found any bug within EVE Online and you want to help CCP to fix this bug and make EVE a better game? Then it would be great if you could write a bug report about it here (out of game). In the following guide you´ll learn in which cases it makes sense to write a bug report and how to write a good report.

Before writing a bug report

• Customer Support: Bug Reports are totally unrelated to petitions, and filing a bug report for reimbursement or help will not work, as bugreports are never seen by the GM/support team.

  You can petition to get help from a GM by using this form or use the in-game petition system.

• Exploits: You found an exploit, which is abused (or may be abused) by other players? Please write both a bugreport (to get it fixed) and a petition (for a fast detection of the exploit and dealing with the consequences).
• Your side: It is always good to check first, if the problem could be fixed yourself, for example by updating your drivers (specially graphics and audio).
• By Design: If you just want to share your opinion about the balancing or game design, please use the forums and don´t write a bug report. Bug reports are not seen by game designers.
• Many problems at the same time: Please always write a separate bug report for each found issue.
• Linux: If you are running Linux and using Wine for playing EVE please report Wine-specific bugs here: http://www.winehq.org/docs/wineusr-guide/bug-reporting
• Macintosh: If you you play the Mac version of EVE, please visit the Mac Bug Reporting site for platform specific instructions.

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:

1. Detailed description of what happened, what you did and how to reproduce it.
2. Screenshot of the bug
3. DXDiag file (Windows only)
4. Logserver log (Windows only)
5. Crashdump (if its generated)

How to write a good bug report

Title

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".
Example: "Overview: War targets not displayed on overview"

Category

Selects one of the high-level categories for the defect.

• Game mechanics: Anything to do with the logic behind the game, design and the way things are supposed to work.
• PVE: Issues with agents, missions, exploration, LP store, NPC’s and so on, which don’t fall in the Game mechanics category.
• Technical: Crashes, freezes, exceptions, hardware-related issues, sound, cache, EVE Voice, graphics and other technical issues.
• Tutorial (NPE): Anything related to the New Player Experience, rookie missions, and the tutorial.
• UI: All issues related to the User Interface (NeoCom, overview, station services etc), but not graphical issues.
• Website and forums: including API and account management.
• Mac/Linux: All technical issues, which happen specifically on Mac systems (please also add Mac to the title).
• Localization: Wrong or missing translations to other languages (but no spelling issues of the English version).
• Art: Graphical problems with ship-models and similar.
• EVEGate: All issues related to EVEGate.
• Other: Stuff that doesn’t fit in any of the categories above (including Spelling and Grammar issues).
• Not Now: Not used, please don´t select it.

Server / Build

Please select the server (Tranquility / Singularity), 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.
You can also find the build version in the common.ini file in your EVE install directory (if you can't start the client).

Description

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.

Reproduction steps

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.

Computer

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

1. When you encounter the bug, press the Print Screen(Prt Scr) button on you keyboard. (If pressing Prt Scr does not generate a screenshot, check the status of your F-lock button)
2. The screenshot should be located in "My Documents" -> "EVE" -> "Capture".
3. Find the screenshot you took (the one with the most recent timestamp).
4. Edit the screenshot in paint to highlight the point(s) of interest.

Saving a DXDiag

1. Select "Start" -> "Run..."
2. Type "dxdiag" and press Enter
3. Select the "Save all information..." button and save the file in a place you'll find it again.

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 2 MB. If you need to submit a larger file than this, please contact a Bug Hunter in the #eve-chaos channel on the coldfront network (typically irc.coldfront.net). 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, txt, lbw, 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'.

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

• Often it might be useful to clear the cache and settings of your EVE client, when encountering a problem with the EVE client.
• List of Known Issues
• Last Patch Notes
• Forums about Issues, Workarounds & Localization, Test Server Feedback, Macintosh and Linux