Obscurity, the Art
Project Leader: OD
Join Date: Feb 2006
Resource Submission Rules
Resource Submission Rules & GuidelinesLast updated: July 23, 2009
Specific Resource Rules
- Moderator / Administration approval is required for a resource to be added to the resource database.
- A moderator / administrator cannot approve his or her own resource. It must be reviewed and approved by another qualified staff member.
- No matter how good the resource is, if the submission does not contain all of the requirements (outlined below) it will not be accepted for the main section.
- Do not submit things to the database only to receive feedback on them. If feedback is all you want, post it in the respective forum of the site for that type of resource. The resource submission queue is for 'completed' work and any feedback received there should ideally only be for touch-ups. Do not submit WIPs.
- All resources must have some form of comment directly related to the resource.
- If a resource is not approved, the type of resources moderator or admin will explain why, be sure to follow as they instruct or your resource will not be added to our resource database.
- After a period of time extending no more than 7 days after a moderator requests changes, unaltered resources will be sent to the "Graveyard." They will not appear in the mainstream sections but will still be accessible for the users. If changes are done to the resource a resource might be "approved" and moved to the main sections.
- The resource approval staff members have full discretion in applying these rules to any given resource as they see fit. Specific rules may or may not apply to a given resource depending on what it is, but the staff will make sure that these rules are followed as best as possible.
- All files (Be it an image, zip, mdx, or otherwise) must be attached to your post. With the only exception of tools that could be links to other threads for convenience. Do not link to off-site images unless the file is larger than our site maximum.
- Any resource submitted must be created by the submitting user, or with clear, valid permission from the creator.
- The first image file attached to your submission will act as your resource's thumbnail. You can always change this image later by editing your thread.
- To delete your own resource, use the thread tools menu.
- First of all and most important: NO 100% EXPORTS FROM OTHER GAMES ALLOWED. All exports are going straight to the graveyard.
- Small exports, like a weapon or a shield for a soldier model are allowed. Just the weapons/shields/whatever alone, as attachment models, are violating rule #1 and will be graveyard'd.
- Model edits are allowed as long as the model is changed significantly, with appropriate acknowledgment by a resource moderator.
- Be original and don't submit models similar to other existing models or models which are not done by yourself.
- If the model has any custom textures, they must adhere to the texture submission rules.
- The submission must include an in-game screenshot.
- The mesh must be clean, with no excess of unnecessary edges and no wasteful geosets or polies.
- The UV map must be decent and continuous, with as few seams as possible and without nasty stretching of the texture.
- If the model has custom animations, they must be good and smooth, with no Parkinson-like movement. Animations cannot be too slow or too fast and should be as realistic as possible. Also a portrait animation is mandatory.
- The model must have proper attachment points.
- If it's a geomerge, make sure the parts are blended properly and so they don't look like something wickedly unnatural (i.e. exaggeratedly huge heads, very thin necks/waists, etc); objects that should be attached to body parts must not float around or attached unnaturally (i.e. a sword floating near the hand or attached to the lower arm instead of being in the fist); also make sure the UV mapping is correct and that it has no nasty stretching. If so, redo it.
Textures & Icons:
- Credit the author. If someone else helped in making the resource then they should also be credited for their work.
- The file must have been tested in the WE to make sure it works properly - provide an in-game screenshot at default camera view to cover this requirement.
- The resource must make clear what model it is for. If it is for a custom model, link to the resource.
- Always include the texture path in the description.
- List all files included in the .zip/.rar/.7z archive.
- The art must be at least 75% original work by yourself. This means freehand graphics, not copying/pasting, filters, or color manipulation.
- Should have decent lighting and shading - no flat / matte textures!
- Submitted textures must be in 256x256 resolution (based on model demands). A 512x512 or higher resolution version may be attached to the submission at no penalty.
- Icons require a DISBTN. Additional variants are optional.
- Icons must use the WC3 icon borders.
Spells, vJass Spells, Systems, & Scripts:
A script is a conjunction of code without objects (unless made via the object editor injection in Grimoire) that can be implemented into other maps and used to achieve a very specific goal via copy-paste installation only. Scripts include test cases and implementation instructions, but do not need a test map. Scripts are for use as utility code to either interface between systems in a map or to simplify the coding process for spells. Script submissions' thread titles should be prefixed with [script].
A system is a conjunction of code and objects that can be implemented in other maps and are scalable. They also include clear documentation and a test map for both implementation and usage. Systems are interactive and perform a specific action within a whole map. Systems should not be for utility, but rather to achieve a specific functionality in a map. Systems typically are higher level batches of code that are not expected to be required by other libraries, but often require many libraries themselves. System submissions' thread titles should be prefixed with [system].
- Required Resources/Libraries
If you want to use non-script resources made by others in your spell/system/test map, you must have the resource author's permission to redistribute it in your map and give credit in a visible place (for example in the loading screen or in a text message displayed in the map). If your submission requires additional script libraries, links must be posted to the required libraries in the submission thread and no permission is needed from the original author to use them.
- WEU / Grimoire
You are allowed to make your spell/system with WEU, Grimoire, or other custom editors. If it can't be opened in the normal editor, you must state which tools the user needs to open it with in your post.
- Debug Messages
If debug messages may not be disabled you should remove them before a release, an exception would be messages that require compiler debug mode.
- Cinematic Spells
Cinematic spells may not be approved. A cinematic spell is a spell that pauses a unit for an extended period of time, uses cinematic mode, or impedes upon the standard play of a map. If you want comments on cinematic spells, they should either be posted in the Triggers & Scripts forum or the Cinematics forum.
- vJass Spells
If your spell submission takes advantage of vJass, then certain requirements may be made of it that otherwise would not apply to normal JASS spells. Some of these specific demands are detailed below in content requirements. You may be asked to adjust other things in addition to those listed in your vJass spells based upon the specifics of your submission.
- Memory Leaks
Your submission must have no memory leaks. If you are unsure about what memory leaks are and how to avoid them, find out more in the tutorial section.
- Multi-Instanceability (MUI)
Your spell/system must be fully multiinstanceable, else it will not be approved.
We don't want cliché spells that have been made many times before, nor do we want copies of spells already in the section that don't constitute a big enough difference in implementation. If the spell is not original in the least, it will be rejected.
The indentation of the code must be a standard format or easily read, proper commenting is highly recommended (but not required in all cases), and proper efficiency considerations must be taken. We realize that coding practices are constantly changing, but you must adhere to the efficiency demands of the moderators. If you know/think that your spell/system is not of the best quality, but you are new and would like feedback, you should post it as a thread in the Triggers & Scripts forum instead.
If a system/script is not useful then it will not be approved. Your submitted system/script must achieve something that cannot be achieved very simply or with little constructive thought by a user.
If coding with vJass, it is standard practice for a library that needs to achieve something done by another script to require that first script's library as opposed to remaking it. If your system/script does far more than is listed and another library in the database performs that action, your system/script should require that library.
This requirement may or may not be demanded of submissions by the respective resource moderators and is case-dependent. Systems and spells (even not made with vJass) that blatantly include all of another library or system's code will not be approved.
- Proper Scoping
All code made with vJass should be properly scoped. This means that a spell or system must be a library where it may be used later on in a map's code within scopes and that vJass spells should be in a scope so that it can take advantage of any required libraries. Initializers should be used as necessary, as well as the proper listing in the library line of code of other library requirements.
Especially when submitting a vJass spell, a proper configuration section at the top of the spell's script is preferable. It should allow users of the spell to configure the spell to their needs (Balance-related tweaks, eye candy options) and also make implementation easy (Rawcodes other necessary constants).
- Follows the same rules as Spells, Systems, & Scripts.
- May have exceptions to the Spells, Systems, & Scripts rules. The objective of samples is to be purely educational so you can have leaks or sacrifice MUI so long as such flaws are noted in the submission post.
- Valuable resources that fail to meet the Spells, Systems, & Scripts criteria for approval and are not updated to do so may be moved to Samples until they are updated.
- There must be a short description what the tool does in the submission thread.
- Note about required files in the description and/or readme if any (eg. .NET framework or Visual Basic Runtime Files)
- Note about the required OS if not Windows 2k/XP.
- Submission threads must include an icon attached to the thread. If no icon is provided, the icon of the executable will be extracted and used.
- Tools that contain viruses, too many bugs, or that are generally not useful will not be approved.
- Tool submissions must include a readme file that contains at the very least the release date, program version, author, and author contact information. (eg. e-mail or a link to the wc3c forum thread)
- Source code for the program is recommended to be provided, but is not required. Source code may be required for certain tools at the discretion of a moderator.