Bugtracker

From BattleMaster Wiki
Revision as of 19:51, 19 May 2013 by Vita` (talk | contribs) (→‎Reporting a new issue)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The Battle Master Bugtracker for logging bugs and feature requests.

http://bugs.battlemaster.org

How to use the Bugtracker

Reporting a new issue

  • Login - you may log in as guest (username and password; no capitalization), but we really do appreciate it if you give us a way to contact you. Many times we need clarification on an issue, and if we can't ask you, we will often just close the case because we don't understand.
  • Search - Search - At the top left of this page you will see "Search", and edit box, and "Apply Filter". Please try to search first on the most important words or error message (just as you would with Google, for example). Adding to an existing report is very helpful; creating duplicate reports slows us down.
  • Report - Report Bugs - If you cannot find anything that looks like the same case, report it as a new case.
  • Category - type of problem occurring. If you are not sure, go ahead and say "not sure".
  • Reproducibility - can you make it happen again? If possible, try again before reporting.
  • Severity (need to find list from docs)
  • Priority (need to find list from docs)
  • Summary - VERY IMPORTANT! Imagine you are going to search the web for this issue - Try to make it short but informative. Don't say it's a "bug" - we know.
  • Description - now you can say as much as you want. Try to reproduce the steps as best as you remember, and tell us your char's name, if he has a position or title, etc.
  • Game World - FEI and Beluaterra are testing islands, and run slightly different code, as does Dwilight, so this is important to us.

Feedback

Many cases will need us to contact you for more info, or to check if we fixed it. If we ask for feedback, please do your best.

What NOT to give us as feedback:

  • Silence - we are all volunteers. You asked us to take the time to look at a problem for you, so please follow up with us the best you can.
  • Related issues - we need you to open a separate case for related issues, unless you think that the same code bug might be causing it. For example, if the bug is "Priest cannot preach in enemy realm", don't add a separate issue about priests losing hours just because they are both "priest issues"
  • Discussions - the bug tracker is for collecting info on bugs. If you think a change should be made to the code, a value should be changed, etc., please take it to the D-list first. We are coders and can't make those decisions anyway, so you are just wasting everyone's time.
  • I can't check right now - this may be a necessary answer, but if you can ask a realm mate to look at something and get the answer, please do. We also use this:

Please Help - Issues the developers would like your help with in collecting data.

When is it fixed?

Just because a bug is marked as "resolved" on the bugtracker doesn't mean you will see the effects immediately. Depending on which island you're on, one or two things need to happen before you see the effects: first, Tom needs to move the fix from the test server to the production server. Almost always, new changes will go into testing, which means that if you're on Beluaterra, Dwilight, or the Far East, you'll see the changes then. If, on the other hand, you're on a stable island--Atamara, the Colonies, or the East Continent--you have to wait until a few days (or, sometimes, more) have gone by and the changes have been checked out by people on testing and found to at least not cause more problems than they solve.

So please, be patient, and don't complain that "it's still broken" 5 minutes after the bug is marked resolved.

  • Tom doesn't manually intervene (we fix bugs, but not the results of bugs) unless the game is seriously unbalanced by a bug.

Common "How To"s of Bug Reports

Additional Notes

  • The first aim of a bug report is to let the programmer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
  • In case the first aim doesn't succeed, and the programmer can't see it failing themselves, the second aim of a bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.
  • When BattleMaster does something unexpected, freeze. Don't click on anything else until you've at least made a note of exactly what happened, and how it was different from what you expected.
  • By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
  • Be ready to provide extra information if the programmer needs it. If they didn't need it, they wouldn't be asking for it. They aren't being deliberately awkward.
  • Write clearly. Say what you mean, and make sure it can't be misinterpreted.
  • Above all, be precise. Programmers like precision.
  • If you lost something due to a bug, you will almost certainly not get it back, no matter how many times you ask. This is standing policy.