Approval guide

Introduction

Any registered user may submit a plugin for review.

Several experienced developers have volunteered their valuable time to help uMod review new plugin submissions.

• nivex
• LaserHydra
• 0x89A
• WhiteThunder
• Ryz0r
• 5Dev24
• MrBlue
• Mughisi
• Whispers88
• Jacob
• k1lly0u
• austinv900
• somemando
• CloysterDitch
• misticos
• Bazz3l
• AdsDev

Please be patient with these reviewers, the community is lucky to have them.

Approval Guidelines

In order to be approved a minimum of two passing reviews must be made by two separate reviewers. A review is considered passing when all of the minimum guidelines are sufficiently addressed and the submissions has no "MUST FIX" issues.

• Attribute definitions exist and are valid

  • Plugin must contain an [Info("title", "author", "x.x.x")] attribute which specifies the plugin's formatted title (i.e. with spaces), author's username, and current version.
  • Plugin must contain the [Description("text")] attribute which provides a brief description (more than a couple words) of the plugin, without re-stating that it is a plugin.

• Detailed documentation

  Documentation must be filled out and explain resource features, any permissions, available commands, etc. in detail.

• Language API usage (if applicable)

  Messages sent to players (normal or admin) must use the Lang API for localization/customization.

• Messages are using English (if applicable)

  Messages sent to players should be written in English by default. Localization in other languages can be provided as well.

• No System.Reflection usage

  Plugin must not be using any Reflection, as this will be restricted and blocked.

• Permissible open-source license attached

  A permissible open-source license must be attached to this submission before continuing.

• Does not rely on deprecated functionality

  Upcoming or existing deprecations will necessitate fundamental changes, refactoring, and/or universalization (with preprocessor directives). Plugin should utilize the most up-to-date game-agnostic API.

• Main class and filename are valid match

  Main class in plugin and filename of plugin must be valid and match each other. Ex. "Teleport" and "Teleport.cs", not "teleport" and "teleporter.cs

• Submission name is unique and relevant

  Submission name (plugin, main class, and filename) should be unique and differentiate from all existing submissions. Submission name should also be relevant to functionality within submission.  Ex. "Discord" and "Discords" are too similar.

• Dependencies are defined and properly utilized

  1. Any and all dependencies must be added so that they are defined on plugin's page.
  2. Plugins that require another plugin (explicitly) to function should utilize "// Requires: PluginName" at the top of plugin.
  3. Any dependency checks and output should be done in OnServerInitialized() hook or later, not Init(). Reference to plugin is set when dependent plugin has loaded.

• Sufficiently configurable

  Essential parameters should not be hard-coded.  If a plugin has parameters which are likely to change between server installations or rely on game variables that might change unexpectedly (e.g. asset paths) then a plugin should implement a configuration file.

• Static instances/references/variables properly handled

  When storing state in static instances/references/variables, make sure these are nullified on plugin Unload to avoid leaking memory or unintentionally reusing old state for future reloads.

• Functionality is unique or is an improvement over existing solutions

  New plugins should add functionality that does not already exist or provide a substantial improvement over existing solutions. If failed, please provide a justification for why this plugin is better than existing plugins that do the same or similar things.

• Uses permission system (if applicable)

  Features should generally be gated by a permission or multiple permissions.  More information about implementing permissions can be found here.

• Reverts modifications on unload

  Plugins that alter the state of the game world should revert those changes on Unload when possible and if not intrusive to players.

• Optimized for performance

  1. Avoid using slow functions like Unity's FindObjectsOfType. There are often much faster alternatives.
  2. Avoid saving large data files. If you expect the plugin to accumulate lots of data, consider using a database, using proto storage, or partitioning the file into multiple in order to save only the data files that have changed.
  3. Avoid frequent heap allocations since they put pressure on garbage collectors. Beware of the popular library LINQ which can create a lot of heap allocations behind the scenes.
  4. Avoid using hooks that are frequently called unless absolutely necessary. Consider subscribing to them dynamically only while they are needed.
  5. Cache frequently accessed objects for quick lookup.
  6. Features that can cause significant performance problems, including admin features, must have additional restrictions in place such as cooldowns, to reduce the likelihood of server owners lagging or crashing their server due to misconfiguration or abuse by moderators.

Issues

Reviewers may add specific issues to reviews. Issues usually reference a specific piece or multiple pieces of code and have a severity assigned to them.

Severity

• Must Fix - Must be fixed in order to be approved
• Should Fix - Should be fixed but will not prevent approval
• May Fix - A suggestion but will not prevent approval