Before You Post

This guide explains how to write clear, useful reports in the SFMB #bug channel. The [[sfmb_betatest_community_rules]]{Community Rules} still apply and take precedence over this guide.

Use #bug when SFMB behaves incorrectly, crashes, freezes, or produces an unexpected result. If you want to suggest a new feature or an intentional change to existing behavior, use #request and follow the [[sfmb_request_guide]]{Request Guide} instead.

Before posting:

  1. Search #bug for an existing report of the same problem.
  2. Confirm the problem on the latest version available to you.
  3. Repeat the problem several times when possible.
  4. Gather the version number, reproduction steps, expected result, and supporting files.
  5. Write one complete message. Use Shift+Enter for readable line breaks.

Finding an existing report does not prevent you from posting the bug again. A duplicate report is allowed when you want to emphasize that the problem still matters or still occurs. When possible, mention the earlier report and explain what the new post confirms, such as a newer game version or another reproduction case. Every duplicate must still follow the full bug-reporting format. Do not flood the channel with the same report repeatedly.

Keep separate problems in separate reports so that each bug can be reproduced, classified, and tracked independently. Do not ping the Developer just to get attention or use the Developer's status reactions yourself.

What Makes a Useful Bug Report

A useful report lets another person understand the problem, reproduce it, and verify a future fix. Include exact details instead of only saying that something is broken.

The official bug-reporting format contains these seven items:

  1. The bug explanation and what is happening.
  2. A screenshot or GIF showing the bug. A video may also be useful when motion or timing matters.
  3. Steps to reproduce the bug. Try them several times to confirm the result.
  4. A map file that reproduces the bug. This item is optional.
  5. What should be happening and what should not be happening. Clearly distinguish the expected behavior from the actual behavior.
  6. Whether the bug happens every time or only sometimes. Include how many attempts you made when possible.
  7. The version of the game you are using. Use the complete version number shown by your copy of SFMB.

The following details are recommended when relevant, but they do not replace the official seven items:

  • The affected area, such as the game, Map Editor, Stage World, or downloader.
  • The stage title or ID for a Stage World stage.
  • Relevant settings, Game Theme, character, object options, controller type, or other conditions.
  • A short, specific summary that helps readers recognize the problem quickly.

Writing Reproduction Steps

Write steps that a person who has never seen the problem can follow. Start before the problem occurs and identify every choice that matters.

Weak:

Put a Koopa there and it breaks.

Better:

  1. Open Map Editor in the SMB1 Game Theme.
  2. Place a red Koopa Troopa one tile above a moving platform.
  3. Test the stage and wait for the platform to move left.
  4. The Koopa falls through the platform when it reaches the edge.

Repeat the steps several times if possible. If the problem is intermittent, say so and describe anything that appears to make it more or less likely.

Screenshots, GIFs, Videos, and Files

Visual evidence should show the setup, the action that triggers the problem, and the result. Crop out unrelated content, but keep enough context to understand what is happening. A GIF recorded at 30 FPS or higher is recommended when motion matters.

Evidence supports the written report; it does not replace it. Always include reproduction steps and expected behavior even when the problem is visible in a video.

Do not upload a bug or test stage to Stage World. Attach the map file to the report or share it by a link that staff can access.

Crash Reports

When the game or editor offers to create a dump file, choose a full dump whenever possible. A full dump contains more diagnostic information than a mini dump.

  1. Save the dump created in the game folder.
  2. Upload it to a file-sharing service if it is too large for Discord.
  3. Make sure the link can be opened by the people reviewing the report.
  4. Post the link with the completed bug-report template.

Also include:

  • What you were doing immediately before the crash.
  • The affected stage title and ID, if applicable.
  • Whether the same crash happens with other stages.
  • Whether following the same steps causes the crash again.

Dump files may contain diagnostic information from the running process. Share them only through a service and access setting you are comfortable using.

Bug Report Template

This copyable template follows the official format in the Community Rules. Replace each prompt. Do not leave required fields unanswered; use Unknown when you genuinely cannot determine something.

1. Bug explanation / what is happening:

2. Screenshot or GIF:

3. Steps to reproduce:
1.
2.
3.

4. Map file (optional):

5. What should be happening / what should not be happening:

6. Frequency (every time / sometimes / once):

7. Game version:

You may add a short summary, affected area, stage title or ID, crash dump link, or other relevant conditions after the seven required items.

After Posting

Monitor the report in case the Developer or a Moderator asks for clarification. For a small correction or a simpler reproduction method, edit the original report or add one concise follow-up. You may create a new duplicate report later to emphasize the bug again, but it must use the complete format and must not become spam.

The Developer uses status reactions to classify reports. These reactions may mean that the report is confirmed as a bug, is not a bug, was already fixed, is being fixed, or needs clarification. Moderators may also react when a report is incomplete or invalid. Do not add these status reactions yourself.

Final Checklist

Before sending a report, confirm that:

  • It belongs in #bug; if it repeats an earlier report, the repetition is intentional and not spam.
  • It contains one independently reviewable problem.
  • The bug and what is happening are clearly explained.
  • A screenshot or GIF is attached when available.
  • The game version is included.
  • The reproduction steps begin from a known state.
  • The actual and expected results are different and clearly described.
  • The report states how frequently the problem occurs.
  • Links and attachments are accessible.
  • The whole report is readable as one organized message.

Related Documents

  • [[sfmb_betatest_community_rules]]{Community Rules}
  • [[sfmb_request_guide]]{Request Guide}
  • [[sfmb_trouble_shooting]]{Troubleshooting}