If you encounter an issue with Galaxy in Turmoil, you are welcome to submit a bug report. Just click "Issues" on the left.
Before you do that for the first time though please take a moment to read the following section completely and also follow the instructions. Thank you! :)
What should I do before submitting a bug report?
Please make sure to test out the current version of Galaxy in Turmoil to see whether the problem you are encountering still exists. Also be sure to test without any non-bundled plugins or mods enabled to make sure it's not a misbehaving plugin or mod causing the issue at hand.
The problem still exists? Then please look through the existing issues (use the search) to check if there already exists a report of the issue you are encountering. Sorting through duplicates of the same issue sometimes causes more work than fixing it. Take the time to filter through possible duplicates and be really sure that your problem definitely is a new one. Try more than one search query (e.g. do not only search for "crash" if you happen to run into an issue with crashing, also search for "op code" etc). Do not only read the subject lines of reports that look like they might be related, but also read the bug report itself.
Very important: Please make absolutely sure that if you find a bug that looks like it is the same as yours, it actually behaves the same as yours. E.g. if someone gives steps to reproduce his bug that looks like yours, reproduce the bug like that if possible, and only add a "me too" or "same issue" if you actually can reproduce the EXACT same issue. Also provide all information as described below and whatever was additionally requested over the course of the ticket even if you "only" add to an existing ticket. The more information available regarding a bug, the higher the chances of reproducing and solving it. But "me too" on an actually unrelated ticket makes it more difficult due to on top of having to figure out the original problem there's now also a red herring interfering - so please be very diligent here!
What should I include in a bug report?
A bug report should contain the following five main parts:
Summary line (short, sweet, summation of the problem)
The Actual Result (a description of what happened; the problem)
The Expected Result (what you thought should happen instead of the problem)
Steps to Replicate (how someone else can make the problem happen too)
Severity (how bad is the problem)
Let's examine those in detail.
A summary needs to be short, and it needs to summarize the problem you're reporting.
Ball gets stuck in the O
A bug report summary is a lot like the subject line of an email. It has to be short, and it has to give an idea of what the email is about (in this case, what the bug is). You'll find that it's easier to write the most concise summation of the problem after you've already written the full bug description.
2. The Actual Result
Writing in first person point of view, describe the problem. Provide enough information pertinent to the problem so that anyone reading the bug report will understand what happened. Write in complete sentences. Use proper punctuation, grammar, syntax, and spelling.
I was playing the Dodgers versus the Zombies, at Pebbledon Downs. I was at bat, and I hit a high fly ball. The ball flew high and long, but it never came down. Instead, the ball got stuck in my onscreen score. The ball flew right into the O and stayed there.
3. The Expected Result
Now that you've described the problem, explain why it's a problem. What did you expect to happen, instead of the thing that actually happened? And what is the basis of that expectation? It may seem to you that it's a waste of time to have to explain why it's a problem -- maybe you think it's self-evident that it's a problem (that any idiot can plainly see why it's a problem, and what any idiot would expect to happen instead). Well, it's your job as a QA tester to communicate. So communicate! What seems self-evident to you may not be so self-evident to your reader. And that even extends to the basis for the expectation.
The onscreen score is an artificial construct; it's not really a part of the physical world being represented in the game. The score remains stationary on the screen while the camera pans around the sports arena. The score doesn't smack any sports fans in the head (the sports fans are not affected by the relative motion of the onscreen score), and the score doesn't collide with structures in the sports arena. So it's unexpected for the ball to interact with the onscreen score in any way.
Now it's dead easy for anyone reading your bug to understand what you expected to happen (and why you expected that to happen).
4. Steps To Replicate
Great, so you found a bug and you're proud of yourself for spotting it. But if the developer can't make the problem happen, how can he or she fix it? You have to tell the developer how to recreate (replicate) the problem. Writing in second person point of view, give the developer complete instructions about how to make the problem happen, so he can see it for himself. And to really communicate thoroughly, conclude with an observation step. Tell the developer what to look for, and what he will see, when he has performed your steps.
The problem has only been observed when playing in Pebbledon Downs, with the Dodgers and the Zombies. Your onscreen score has to be zero, and you have to aim for the zero. It can be tricky to make this problem happen, because it requires a good strong hit, a fly ball, and a trajectory that intersects perfectly with the middle of the O in the score. But I was able to make it happen a second time by simply being persistent. I recommend using the practice mode (that way the test is not prolonged by inning changes, vampire attacks, and timeouts). Using the left stick, position the batter's feet so that a line drawn across both shoetips points directly towards the O. Press the right trigger just as the ball crosses the 5-point line, and hit the ball, then watch as it flies. When the ball flies into the O, observe that it gets stuck in the O.
See how that's written in second person (I told the developer what he has to do). And notice that in the observation step I told him what to look for.
Now that you've described the problem, why it's a problem, and how to recreate the problem, you need to say how severe the problem is, and why you say it's that severe. You can't just say "it's a bad bug and needs to be fixed." You have to communicate the reason why it's bad. And you should use the A-B-C-D scale. (Remember: A is worst, B is bad, C is normal, D is minor.)
When the problem happens, it's quite severe, because the ball is stuck and the game can not continue. The only way out of it (other than rebooting) is to hit Start, then Quit the game. But the problem happens only on those extremely rare occasions when the ball perfectly enters the O. So I'm assigning this a severity of C.
Some Common Mistakes
Non-summing summary line.
"Found a bug." No kidding! Like all these other bugs in the database aren't bugs that somebody found? That's like sending an email with the subject line, "Hey" - or "I wrote an email" - or "From me." Sum up the problem! Say what the problem is. Just like when you write an email, you give the recipient an idea what the email is about before he or she opens it.
Too-long summary line.
"The slithy toves gyred and gimbled in the wabe when the borogoves were all mimsy and the mome raths outgrabe." Dude, just say "The slithy toves gyred and gimbled." That condenses the essence of the problem. You can give us the details about all the excessively mimsy borogoves in the body of the report.
Player as developer.
"The slithy toves need to have a 5-second cooldown after gyring so they don't gimble too soon." No, don't tell the us how to fix it. Just say what the problem is. It's our job to figure out what's the best way to balance the slithy toves so you can get back to enjoying the game.
Not giving step by step instructions.
Tell the us what to do, so we can see the problem. Don't just say "I did this, then I did that." Tell us, "do this, then do that." Give step-by-step instructions, in detail, in the second person.
Unclear basis for an expectation.
"Usually, pressing X causes the door to open." What do you mean, "usually"? Do you mean that's how one opens doors in other games? Do you mean that's how one opens other doors in this game? Do you mean doors in your home open when you press an X button? What does "usually" mean?? Be specific, dude!
Confusing "player" with "player character."
The player is the human who's holding the game controller. That digital being on the screen is a character. Don't use the terms interchangeably.
Wishy-washy observation step.
"Then watch to see if the problem happens or not." Wrong. Tell us how we will see the problem. Tell us to observe that it does happen.
Inappropriate use of the word "should," as in: "After you follow these steps, you should see the bug happen."
The bug should not happen -- that's why it's a bug! If it was supposed to happen, then it wouldn't be a bug. So you shouldn't say "should" in this way. Just say "after following these steps, observe that the bug happens."
The words "glitch" and "bug" are not sufficiently self-explanatory. If you use the word "glitch" or "bug," whether in the summary or in the description of the actual result, you must still clearly explain what the problem is.
If your issue is related to a SECURITY VULNERABILITY, please do not submit this to our bug tracker but instead mail firstname.lastname@example.org.