Revision 1: Added "no bumping" forum rule
Revision 2: Added "supply MIDI for music requests" rule
Revision 3: Added "Include SPC with custom music submissions" rule
Revision 4: Clarified rule 2.6
Revision 5: Added rule 10.4
Revision 6: Added note about the rules, added rule 1.7
Revision 7: Revised 4.11
Revision 8: Replaced 12.3 with an updated version of it.
Revision 9: Clarified rules 4.9 and 4.10 a bit.
Revision 10: Added rule about ID666 tags for music submissions.
Revision 11: Added a rule about submitting blocks that can be made with Blockreator.
Revision 12: Removed request section guidelines.
Revision 13: Updated tool submission guidelines.
Revision 14: Updated patch submission guidelines.
Revision 15: Clarified the bumping rule.
Revision 16: Merged document and tutorial submission guidelines.
Revision 17: Added IRC rule 5.8
This thread is meant as a guide to help people stay out of trouble. The rules listed here cover issues we've had people commonly run into. They were not written to be taken completely literally. Staff members may exercise their powers as they see fit, for any reason. Use your common sense and don't be a smartass.
Avoid creating unnecessary posts with little or no thought involved.
Do not advertise.
Do not create threads to advertise your own website, forums, etc.
Use proper spelling and grammar.
Proof-read your posts and avoid using chatspeak, leetspeak, etc.
Post in the relevant forums.
For example, don't ask SMW hacking questions in the art forum.
Look for existing threads first.
When seeking help, there is a chance that the question you want to ask has been asked before. Be sure to check for existing threads/tutorials, or in the F.A.Q. section.
Don't backseat moderate.
Don't tell the staff what to do, and furthermore do not try to enforce your own rules on the site. You are welcome to politely point things out to other users, but you are not superior to them and should not act as such. If you have a concern or question, please send the appropriate staff member a private message.
No explicit content without warning.
This includes any form of pornographic images or any textually explicit postings. Do not embed these types of images directly in posts. Instead, link to them and make sure they have an appropriate NSFW label.
Think twice before posting in inactive threads.
Posting in a thread that has been inactive for over 30 days may not be a good thing to do. If you have something relevant to say about the topic in hand and the thread can still be kept in track then you are free to post in it; however, if the thread is dead or the discussion is not relevant anymore you should leave it as it is.
Make sure that your text color goes well with your background. Keep in mind that some colors are very hard to distinguish on some LCD screens. Always ensure good contrast.
Make sure that your font has a comfortable size.
Do not use fonts which are too difficult to read.
It must be easy to locate your post text.
You should generally never place anything above or to the left of your post text. Make sure that your post text is well seperated from the rest of your layout. It should not be possible to mistake any part of your layout for your post text.
Minimize the amount of distractions in your layout.
Don't use large images or flashy animations that draw attention from the post text.
You may never have more than three userbars visible at the same time in your layout.
User bars take up a lot of space and attention from the post text.
User bars may only be placed below your post.
Don't place user bars in the header, to the left, or to the right of your post text.
The total file size of your layout may not exceed 200 KiB.
Try to minimize the file size of your layout. We would like page loads to be as fast as possible.
Do not use fixed backgrounds in your layout.
Fixed backgrounds tend to cause unsmooth scrolling and general slowdowns on older computers.
Do not use the opacity: rule in your layout.
Using opacity: to achieve transparent backgrounds also makes your post text, images, embedded media, etc. transparent, which often makes your post hard to read. Use rgba() or a semi-transparent PNG instead.
Your layout must comply with the rules in the latest version of every major desktop browser and on every thinkable screen resolution.
Major browsers include Internet Explorer 8, Internet Explorer 9, Firefox, Opera, Chrome and Safari. Popular screen resolutions range from 1024x768 to 1920x1200.
You may only use variable-width fonts with high legibility. Below is a list of recommended fonts:
Comic Sans MS
Franklin Gothic Book
Times New Roman
If you would like to use a font not listed here, go ahead. As long as it is easy to read, there shouldn't be a problem. Note, though, that your layout will be removed if your text is too difficult to read. If you're in doubt about a certain font, feel free to ask.
Please use the "My Files" feature to host your layout files.
Since external hosting services are potentially unreliable, this is the only way we can ensure fast loading times.
Minor edits of existing SMW levels will not be accepted.
Use Ctrl+Del to remove old SMW levels. (104, C5, C7, and 3 are exempt from this.)
Do not steal content.
Any hack containing content that was used or copied without permission (i.e. stolen) will be removed.
Avoid major graphical glitches.
Errors such as garbled sprites/FGs/BGs, message box text screwing up layer 3 items, floating/stacked/cutoff tiles, and general graphical ugliness are frowned upon. Furthermore, don't forget about glitches which involve the sprite memory - the graphics of the sprite will 'disappear', but the sprite will still be there, and can unfairly hurt Mario.
Your hack should be of a reasonable length.
Unless you intend to make your hack contain very long and very high quality levels, demos which are too short to provide any feedback on or be enjoyable will be subject to removal. A general rule of thumb is that the hack should feature at least one complete world with about five levels, or should feature around at least 15 minutes of game time.
The player should not be able to die in the title screen or intro level.
The title screen can glitch up if Mario collects a star, hits a P-Switch, enters a door/pipe, or dies. The life counter will also glitch up if Mario is able to die in the intro level. Please try to avoid these errors.
The player should not be able to enter Level 0 or 100 from the Overworld.
Level 0 and 100 are the Bonus Game levels, which are handled in a special manner that makes them "endless" if you enter one from the overworld. This causes the player to be trapped forever. To prevent this, check and test your overworld events and levels to make sure that they lead where you want them to.
Warn players ahead of time if mature content is present.
You should have a fair grasp on what is mature and what is not.
Keep the hack at a fair difficulty.
Avoid issues such as death traps after the goal, blind jumps, forced damage, excessive enemies, places where you can get permanently stuck, excessive 3-UP moons, projectile sprites (e.g Bullet Bill) placed directly into a level instead of using the correct shooter/generator sprite, etc.
Test your hack on all major emulators.
This will ensure that all players, no matter which emulator they are using, can play it without experiencing slowdown, crashes, or audio glitches. Major emulators include but are not limited to: ZSNES, Snes9x, and bsnes.
Have fellow users beta test your hack before submitting it.
Your hack should be as good as you can make it before you submit it to be featured in the hack database. A good way to make sure you have a quality hack is have it beta tested. Have your friends play it and give you feedback, or recruit some beta testers.
Quality level design!
Your hack has a much higher chance of being accepted if the level design is fun. Conversely, if the level design is found to be lacking, then small graphical glitches may be enough to push the hack into deletion.
Your submitted hack must have at least one screenshot!
When you submit your hack, you should also upload at least one screenshot, if not several. An acceptable screenshot should feature an example of actual gameplay from the game (e.g. a screenshot that features the player, typical graphics and level design, choices of sprites, etc.). Unacceptable screenshots include unrelated images, as well as screenshots of simple, unrepresentative things (e.g. the Nintendo Presents screen or a very bland beta title screen). If you use the title screen as a screenshot, please include another screenshot of actual gameplay.
Each tool should include a readme file, even if it's a very simple tool with one function. The only exception to this rule is if the readme is inside the tool itself.
Do not submit duplicates of existing tools.
This clutters up the section. Unless the tool you are submitting is superior to an existing tool, and/or an updated version, please do not do this. This means no "starter packs" or anything similar!
The tool is directly related or useful to hacking a game which we support in some way.
This means no tools specifically for games like Super Metroid, Star Fox, etc. The games we support right now are: SMW, YI, and SM64. General hacking tools and general hacking tools for a system are fine though.
Nothing illegal should be in your submission.
This means no ISOs/ROMs/WADs or any other copyrighted material itself.
Make sure the content of your document is explained thoroughly with no errors.
This is the most important requirement. Your document shall be removed immediately if there are any incorrect explanations.
The tutorial should be relevant to SMW hacking.
SMW Central focuses on SMW hacking, and therefore we want SMW-hacking related tutorials.
Use proper spelling and grammar.
Tutorials riddled with misspellings, grammatical errors, chatspeak, leetspeak, etc. are unpleasant to read.
The tutorial should be as descriptive and easy to understand as possible.
If you want people to understand the process explained in your document, make sure the content is as well-written as possible. For tutorials, telling the reader steps without explaining them won't teach the reader anything; tutorials are for teaching things, not making readers mimic you.
The palette included with the ExGFX submission should not overwrite the status bar colors.
In almost all cases, overwriting the colors on the status bar will render it ugly and unreadable.
Your ExGFX palette should only overwrite the colors used by the graphics.
Make sure the palette file you include is not a direct copy of the palette of the game itself, or else other colors may also be affected.
If you're submitting a background ExGFX or ExAnimation file, please make sure you include a .MWL.
Backgrounds which take a lot of time to assemble should have a .MWL file with the background included for convenience. The same rule applies to ExAnimation.
Make sure when submitting your Graphics to include an in-game screenshot and a screen shot of the 16x16 editor in its respective field.
This will allow others to view your graphics and see if they will fit in their own hack. Along with this, because of the new zoom feature as of LM 1.90, please do not use a magnified version for the map16 page, it takes up way too much space.
Make sure your song is compatible with all emulators.
An ADSR Decay value exceeding 7, and an echo buffer value exceeding $04 may break the music on more accurate emulators.
Put the proper song information into the song description.
Song Duration (how long the song is in M:SS), the size of the song upon insertion (in decimal), how many channels the song uses, and what additional items it requires (AddmusicM, MORE.bin, Carol's MORE.bin, etc).
Aim for both quality and accuracy.
Submissions which sound inaccurate or poorly made will not be accepted.
Include an SPC file in the submission.
Include an SPC file of the custom music, so the user doesn't have to go through the trouble of setting up a test ROM and inserting the music, just to preview it.
Edit ID666 tags on your SPCs before you submit them.
You can find out how to do that here else they will be removed. This makes it more convenient for the mods so they don't have to resubmit your work.
Please test your blocks before submitting them. We do not want malfunctioning blocks hosted on the website..
Your ASM block should have correct jump tables.
If your block has a missing jump from the jump table, or it has an extra jump, the block will be rejected. The only exception is the BTSD's latest version's optional 3 jump tables. You need to enable them with db $42 in the beginning of the file. If that code is missing while you have 10 jumps, the block will be rejected.
Only .asm files are to be submitted!
.bin files will not be accepted anymore, as they will soon not be backwards-compatible anymore in newer versions of BTSD. This also means you won't have to list offset values in the readme anymore - however, a good readme is still appreciated.
Make sure to include the "acts like" settings of the block.
It is your responsibility to include the details for the "acts like" settings of the block (as in, should it act like tile 130, a cement block? Tile 25, a blank block? Etc.)
It is MANDATORY to include corner and inside block off-sets in blocks that require those offsets, i.e. solid ones.
Though, to ensure your block won't have any bugs of that sort, include the off-sets in any case.
Don't submit blocks that can be made with Blockreator.
These can be easily made and are usually very simple.
Don't make patches which change very small amounts of data in the ROM. Those hex edits should be submitted to the ROM map. An exception to this rule would be a rather complex hex change, such as several different addresses in the ROM. This does not include a couple of 1-byte hex edits, however.
Always put a RATS tag in your patch.
If you don't, there is a possibility that your patch will get overwritten by various tools. An exception to this rule is if the patch does not require free space.
Do not upload simple edits made using other patches.
Multiple versions of the same patch is unnecessary.
Only patches in the .asm format are acceptable.
The patch should be an .asm file that works with Xkas v0.06 or Asar. Asar is the preferred assembler and will become the absolute standard in the near future.
Avoid including unnecessary files and/or folders with the .zip.
Those folders aren't often needed, unless you have 5 or more files inside the patch. In that case, you're allowed to use a folder to organize the files.
Don't submit addresses unless you are 100% sure of their function.
If editing an address seems to have multiple negative side effects, it is probably part of an important subroutine. Make absolute sure that each address you submit works as intended and doesn't mess up other parts of the ROM.
Give your submissions a proper description.
Descriptions such as "Tilemap related" are insufficient, vague, and should be avoided. Key details should always be included, such as the exact effects certain bytes have on the address.