Project

General

Profile

Guide » History » Version 9

« Previous - Version 9/32 (diff) - Next » - Current version
Squelch, 09/05/2015 03:42 PM
Additional section and clarification of clean installs in guidelines.


Information on Support and Bug Reporting

The Kerbal Space Program Bugtracker is the place where bugs can be reported for the attention of Squad. There is a team of testers and other interested people who look through these bugs and try to assist people who have issues, as well as helping to identify when bugs need to be raised to the attention of developers.

Please keep in mind that while best endeavors are made to prevent bugs from slipping into released code they are a part of software development that is a reality. While they can be immensely frustrating when they manifest at the wrong time, do try and investigate/report them in a methodical and complete manner. The better the input in a bug report the better the chance that someone can help identify it/fix it and improve the experience for all

A note on Modded Installs

As it is the place for raising issues to the Core Developers, the bugtracker is only targeted at Unmodded installations of KSP. The developers don't run modded installs and are focused on providing the most stable core experience that they can. Modders can then build on this stable foundation. However, Mods can introduce unwanted influences that are sometimes hard to track, even if they outwardly deal with something else unrelated. Please consider the testers and ultimately developers time in getting to the heart of the bug as quickly as possible. We therefore kindly ask that any suspected bugs are reproduced and verified in a clean game before reporting.

If you are experiencing issues with KSP and cannot replicate them in a stock install then there is a really good group on the Forum where many of the testers and modders hang out and try and help with issues on Modded Installs. Here is a link to the Modded Support Forum

Issues logged for modded installs that cannot be replicated will be looked at, but will likely be closed if there is not enough compelling information for a non mod induced bug to pass them to the devs for attention. A good example of this exception might be; a fault in the plugin API that can only be demonstrated by mod installation. Please do involve the mod author(s) in this if you are not one of them out of courtesy.

So whats important when looking at a bug?

When investigating strange behavior and reporting a bug there are some key pieces of information that can help pinpoint where a bug may be occurring and also help others to try and replicate the behavior. try and ensure that you have as much of the following information as you can:
  • KSP version including Windows, Mac, or Linux, 32 or 64-bit, and if it's Steam
  • A detailed explanation of what happened and what you were trying to accomplish
  • A screenshot of your craft or any relevant screens (or even a video if you are feeling demonstrative or its difficult to describe in text)
  • A .craft file or save files if relevant
  • The ouput_log.txt or player.log file KSP creates when it launches and, if applicable, the crash log KSP has generated when the program crashed (note that this is not the KSP.log file)
  • A detailed list of system specifications
  • Are you running a clean installation, or have you updated and some of your persistence or craft files might be older versions, if so which version(s)

To find out how to obtain this information, please see below:

 

Reporting that bug

The key thing about reporting a bug is being able to include enough detail in the report so that the behavior can be replicated by someone else - especially by a dev when they are looking at your submission. Anything we can do to improve the turn around on bugs is a great help in the efficiency of coding the fixes.

Below you will find an example of the format used by the QA and Exp teams to log issues during testing. We've found it a quite effective way to include all the relevant info. You'll see how the report clearly states how the bug was encountered and how it can be reproduced with as few moves as possible. It is as helpful as a bug report can be, and this helps Squad narrow down the problem.

An Ideal Example


If you wish to format your report to make it easier to read, please refer to the Redmine formatting page
 

Extra Classification

Further to the content in the body of the issue there is some extra information you can provide by categorizing the issue using some of the fields in the bug tracker. Don't be put off if you don't know what to choose, there are always helpful people around who can help triage the issue too

There are two types of Issues for reporting on the tracker that are available to use:

  • Bug: There is something wrong with the game that you'd like to report.
  • Feedback: Where we find opinions and balance.

How Priority Helps

Priorities help us to figure out which issues need inspecting, reviewing and fixing first and foremost. Thus, the priority assigned to an issue needs to be as objective as possible; not a result of how much it affected your mission or current gameplay goals, but how much it affected the game itself. If youre unsure the following table should assist you in deciding what priority to assign an issue.

Categorizing Issues

Setting a category helps us get things to the right developer when they get to that stage. You can see the list and details on the Tracker Categories page

Some Guidelines on Bug Reporting

Some helpful information and ideas to keep in mind as you are writing things up. feel free to use the headings here as reminders and come back to these for more detail if you need it:

 

What Happens Next?

To read a little bit more about what happens after a bug is submitted you can check out the How Bug Reports are Managed - i.e. What Happens Next page

 
 

Other Support Resources

You will also find a lot of good support resources on the Official forum in the sub forums below: