ID:195162
 
Before you report a bug, there are a few things you should keep in mind that will make your life, and ours, a lot easier.

Step 1: Did you actually find a bug, and is it new?

Believe it or not, people often don't check on this. It's important to know if you're dealing with a known issue, a code problem, or something that really belongs in BYOND Help or in a specific game's forum.

If you discovered something while working on your own code, there's a good chance the problem is in your code. The first thing you should do is do everything you can to resolve it in the Developer Help forum. Post relevant snippets of your code there, and work with the community to figure out if something incorrect is happening. Don't forget to check the reference, either; if it's an interface issue, check the skin reference too. What you're seeing could be intended behavior.

If you ran across the issue in a game, be sure it actually isn't a bug in the game. BYOND bugs tend to stand out more because they usually appear in multiple games, not just one. A bug may also be in play if you see different behavior for the same game but in different BYOND versions. When in doubt, it doesn't hurt to ask around; try the game's forums.

Finally, before reporting a bug make sure it hasn't been reported already. We're not asking anyone to do an exhaustive search, but do a search. (Check out the help forum as well, just in case!) If you do find a matching bug, add a reply to pitch in your new information. If it turns out not to be the same issue, you can always post a separate bug report later; in that case we may ask you to do so.

Step 2: Tell us everything!

There is one word I use more than any other when responding to a bug report: details. We need them. It is crucial, vital, and critical to provide as much information as you possibly can about the bug. We even provided a handy-dandy template for you to fill in.

First pick a subject line that describes the bug simply, like "/image icon does not appear when using override", or "Output text doesn't appear in popup", or something like that. You don't need a full paragraph here, just something to describe it in brief.

Now, the BYOND version: If it's a software bug, enter your version number. If it's the website, we have a choice for that. You can find your software version in the About... box found in Dream Seeker, Dream Daemon, Dream Maker, and the pager. Usually we only need the major build number, e.g. 481, not the minor build number that comes after it, and the choice should be in the list. This part is important: Under no circumstances should you write in "don't know", "latest", or "all". Always put in the version number you saw this with. If it happens in multiple versions, put in the most recent one you tried, and in the full text of the report you can tell us what other versions you tested.

In the template, you'll see us ask for a detailed description. The same thing applies here as on the code help forums: Take your time and write out a description as clearly as you can, giving us as much info as you can, and even a step-by-step analysis of the things you tried or observed. You won't be held to account for grammar or punctuation, but just keep in mind that the clearer you can be and the easier it is for developers to read the issue, the more likely it is we can fix it. By the way, any text you put in should go after the </b> tag, so we can read it. Screenshots and video can often be helpful here, too.

There will also be a place to put in numbered steps to reproduce the problem. Don't skip this if at all possible. We need this because if we can reproduce the issue, we have a much better chance of seeing it ourselves and fixing it. Be as detailed as you can, and break it down into as many steps as you have to. Here's a good example of helpful steps:
  1. Join (link to game's hub entry).
  2. Create a new character. [If the type matters, and for some bugs it does, please say which kind. We hate going through these screens, so please give us the info to get past them as quickly as possible.]
  3. Walk south to the fountain.
  4. Right-click the weaponsmith and choose "Talk".
  5. An armor overlay should appear on you when he is finished, but it does not do this in version X.
If you did see an issue in a certain game, or in several games, links to their hub entries are always a good thing. Don't just say "This happens in NHW", because chances are we don't know what game that is.

There will also be questions about other things you can try, like trying a different game or using a different computer. It also helps us to know if the problem always occurs if you follow the same steps, or if it's intermittent. Some bugs are OS-sensitive and will be different on different operating systems; website bugs can be different on different browsers, too. Fill in the questions as best you can, and you'll be doing us a huge favor if you test the ones you can test. Remember, the more info we have up front, the faster we can solve the problem.

For software bugs, we also ask if they happen in older BYOND builds, because it helps to know when a bug appeared--we can often pinpoint the cause much better by knowing when it began. You can help a lot by testing this. Old builds can be found at http://www.byond.com/download/build. Say you're testing 509. Download the zip file for the 509 build. Create a new directory like, say, byond509, and unzip the files into that. If you close down the regular BYOND pager, you can open up the pager from that build and then any games you join should be in build 509. (Always check the About... box to be sure you have the right version running.) Obviously this won't always be possible, but being able to pinpoint exactly where a bug began is a really huge deal.

Step 3: Include a demo

Whenever possible, it's important to include a demo project that shows the problem in action so that it can be easily reproduced. If reducing the problem to a demo proves difficult or impossible, I'm usually able to take a look at full source code, which you can send to me securely via a link in a private message. (When testing full source code, I always ask for specific instructions on how to get to the spot in the game where the error occurs. If your game has a character setup screen, give me detailed instructions on how to get through that screen quickly. Even better, you could always include an option in your source that bypasses that screen.) While running a demo in the debugger, it is often possible for me to catch a problem in action.

Even if a problem appears very simple, a demo is a huge help. For one thing, it's a time-saver on my end because I don't have to try to reproduce the problem from scratch. Also, it is very common that something specific to a certain game or certain code will make a difference in whether the issue can be reproduced at all; if I try to build a demo from scratch, it may show nothing wrong. If a bug cannot be reproduced, it will be marked as Unverified and that can cause a further delay in getting it fixed. So it's always better to include a demo whenever feasible.

Also, be sure to package your demo as source code, not as a .dmb and .rsc. It is important that I be able to examine the source and make changes as necessary, as this often helps narrow problems down. A file that includes no source will not be used.

As mentioned above, images or videos demonstrating the problem are often helpful, and are worth including in your report--but they are not equivalent to a demo. An image or video can demonstrate what's happening, but only a demo can be used to determine why it happens.

Step 4: Be available

If you post a bug report, the worst thing you can do is ignore any followup replies. When I investigate a bug, I'll often ask for more information that the original poster forgot to include, or ask questions to try to narrow down the issue. In some rare cases, we have also hooked up users with test builds when we couldn't be sure of reproducing a bug on our end but thought we had a fix. If you're around to respond to questions, it's really helpful.

Step 5: Be patient

I know, this is the worst step of all. Bug reports take time to fix, and some get fixed quickly while others take longer. Keep in mind we have a very small development staff, and we're often focused on one issue at a time. If we're working on software, website bugs may have to wait, and vice-versa. Some bugs are hard, or even impossible, for us to reproduce reliably. Some may have no good or quick solutions, and may be deferred for later review.

If you don't hear back from us on a bug, it doesn't mean it's been forgotten; it may just not be high priority at the moment.