Author
|
Message
|
Veteran Member
Join Date: Mar 2004
Location: CT
|
12-14-2005
, 19:57
Read before posting new plugins. - Updated 9-5-14
|
#1
|
To post a plugin, follow these directions:- Click the "Post Plugin" button
- Choose the mod and category of your plugin.
- Write a description about it (Do not put "Plugin:" in title!)
- Add SMA and ZIP (if applicable) files for people to download. Do not add the .amxx file
Note: The only time you can not attach the SMA directly is if your plugin uses custom include files. Do not link to external sites unless it is a one-click download (there should be no registration required).
- Wait for a moderator to approve the plugin.
- To read more about the moderation system, view the sticky in the Plugins forum.
- For completeness, you may want to read the terms of the GPL and How to apply them to your plugin
Rules:- [All Plugins]
- Do not post plugins that already exist or have been written already.
- If you did not write the plugin, put the name of the author in the topic and in the post.
- If the original author requests that it be put under their control or removed, their request will be honored.
- Make the source code available - It should be attached as a separate addition to any package you upload, for the quick-ease of access for Approvers.
- Do not post compiled files (.amxx). When the source is uploaded, the forum generates two links: Get Source - Get Plugin. If your plugin has custom include files which must be compiled locally, contact a plugin approver or moderator to compile it and post it for you.
- Do not post plugins "just for the sake of it". eg. A fulfilled request may have been useful for one or a few people, but that does not necessarily mean that it has a place in the Approved section. Please take the time to expand your knowledge and produce some quality work.
- Do not post destructive or offensive plugins.
- Only post plugins you have written.
- Do not put "Plugin:" in the title. It is added upon approval.
- Do not hardcode paths. Use get_basedir(...) instead.
- Use log_amx instead of log_to_file
- English is a must. If you want to use another language, you can post another version of it or use ML. But, your description and plugin must be English. You can include you description in the other language, but having the description in English is a must
- Use pcvars. They are much faster than the old way of setting/getting cvar values.
- For packages, use only zip, [tar.]gz, [tar.]bz2. Plugins using other compression formats should not be approved, this includes RAR and 7z.
[Ports from AMX to AMXX]
- Do not use amxmod.inc. Use amxmodx.inc instead.
- Do not use the Vexd or XtraFun modules. Use the cstrike, engine, and fun modules instead.
What we are looking for in plugins:- Make sure it's code is clean, concise, and readable.
- It should compile without errors and preferrably without warnings.
- It should work.
- It should use AMX Mod X API only. If you've ported an AMX Mod plugin, port it fully.
- You should have necessary documentation and a good plugin description.
- The code should be yours, or if not, with proper given credit.
- The plugin should be somewhat unique - i.e., a plugin that plays sounds with key phrases has been many times before, and would not be approved.
Some examples of plugins that will not be approved:
amx_slowhack (or any variant)
Any plugin that changes models to another, hardcoded model.
Any plugin that lets you play one sound in response to one event.
Any plugin that already exists.
Note: The AMX Mod X Team expects source to be available for all plugins, under the GNU General Public License. This is because AMX Mod X uses GPL AMX Mod code, which must be under the GPL because it links to Metamod code. The HLSDK EULA mandates that nothing linked to the SDK can be used for commercial purposes, and Small plugins are not linked. If you would like to make your plugin exempted from the GPL rule, please contact us.
Last edited by hornet; 09-04-2014 at 19:46.
Reason: Added quality rule
|
|
|
|