1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Thread Status:
Not open for further replies.
  1. Wulf

    Wulf Community Admin Community Admin Oxide Developer

    I know this is long overdue and has mostly been handled verbally on a case-by-case basic, so I'm trying to take some time to get some of the basics we've been going by written down. I'll only be covering C# plugins, as support for the other languages is being phased out. This will be expanded and improved on as necessary.

    Plugin Info Basics
    1. The title of the plugin (first part of Info attribute in C# plugins) must be set and closely match the submission name on our site. Please avoid using "Plugin" in the title as well as it would be a bit redundant. Make sure this name is unique as well, as we only accept one plugin per name across all games to avoid confusion and conflicts.
      > Good: BanSystem, Bad: BanPlugin for Admin

    2. The author of the plugin (second part of Info attribute in C# plugins) must be set and match or contain the name of the user submitting the plugin on our site. Please do not use this to advertise your site or personal server.
      > Good: Wulf, Bad: Fluw @ MyServer.net

    3. The version of the plugin (third part of Info attribute in C# plugins) must be set in the x.x or "x.x.x" format. This is updated each time you post an update, and should match your submission on our site. Semantic Versioning is recommended.
      > Good: 1.2.3, Bad: 2017-02-01 Beta 1

    4. The ResourceId is optional (last part of Info attribute in C# plugins), but often preferred by server owners as it is used along with plugins and tools to check for updated versions of the plugin on our site. Setting this to something random will cause issues with plugins that rely on it.
      > Good: 0 (or not set) Bad: 12939402 random #

    5. The Description is an optional, standalone attribute, but recommended as other plugins can utilize it for making help commands and such. Please make sure to actually describe your plugin, but keep it brief. Best practice is to use Sentence case, not Title Case or CAPS. Keep it clean!
      > Good: Allows admin to ban players easily on command, Bad: Cool Admin BanPlugin

    Best Practices

    While not a requirement, cleanly formatted code is always appreciated as it makes our job easier when we can easily follow the code of plugin being submitted. Visual Studio 2015 or above is always recommended to enable support for the latest C# version as well as numerous options for helping improve your code.
    1. Using statements (ie. using System; at the top of the plugin) can easily get out of hand. Try to only add what is needed by the plugin and remove those that are not. Most IDEs such as Visual Studio have options and addons to handle this and more.

    2. Hooks are what make plugins tick in most cases. A hook in Oxide gets triggered every time an area of the game, which in turn calls the hooks in the plugins that are using it. Each time a hook is called takes up resources and time. If your plugin doesn't need a specific hook, don't use it! If you can combine some, go for it! Try to keep the plugin's impact as little as possible.


    There are certain types of plugins that we generally do not approve. These are often because of their general use for abuse, trolling, backdoors, causing conflicts, drama, potentially problematic, or going way beyond their purpose.
    1. Piracy enabling or authentication bypassing plugins (this should be an obvious one)
    2. Any plugin attempt to bypass sandboxing or security measures put in place (security is important)
    3. Any plugin containing a backdoor or access privileges for specific individuals, even developers
    4. FPS "booster" type plugins (these have been known to be malicious and problematic)
    5. All-in-one does-everything plugins (these defeat the purpose of being modular, often cause conflicts)
    6. Copies of existing plugins with various "fixes" in them (fixes should be contributed to the original)
    7. Copies of existing plugins with messages translated directly (translations can be contributed to the original)
    8. Plugins using any sort of obfuscation method (this is not protection, it does nothing other than make your plugin annoying to review)

    Plugin Messages
    1. All default plugin messages are required to be written in English. If you'd like to add support for additional languages, take a look at the Lang API. This includes messages printed in the server console or logs only.

    2. The Lang API: When sending messages to players, the Lang API should be used so that server owners can easily customize or localize them instead of being hard-coded or using the configuration file that is meant mainly for settings/options. Also keep in mind that not all server owners have access to edit plugins directly, and they generally shouldn't be edited directly either as they'd have to make those same edits each time the plugin is updated. Make sure to use the player's Steam ID when sending messages to a player, this will allow them to use their own language when available. If you are unsure how to use the Lang API, most of the recent new submissions will have examples as well as many of the existing plugins from myself and others.

    3. While not required, not prefixing messages with your plugin name is generally encouraged as it keeps the messages sent to players shorter and cleaner. Some plugin developers opt for having the prefix configurable via the config file, but most do not set one.

    4. Try to keep messages brief and to the point to avoid taking up an excess amount of screen or console space. Best practice is to use Sentence case, not Title Case or ALL CAPS.

    If you experience any issues with implementing any of these, feel free to use the appropriate development section of our forums. Happy developing!
    Last edited: Jul 15, 2017
    nuchacho, Cataclysme, Maik8 and 19 others like this.
Thread Status:
Not open for further replies.