Ore 插件提交指南


This document refers to an outdated SpongeAPI version and is no longer actively maintained. The policies, guidelines, and some links have changed. Please refer to the latest version of the documentation instead.

歡迎來到 Ore 提交指南。這份文件概括了我們對專案與檔案提交的預想。

請記住以下內容為一般狀況下的指南,Ore 團隊(以下簡稱為「工作人員」)可能隨時變動未在此明文規定及說明之內容決議。




您欲提交的專案名稱不應包含版本號、標語或其它說明。名稱應獨特且原創,也不可夾帶含有 Sponge 專案意味的字句(如:SpongeWarp 不被許可,但 Cool Warps for Sponge 可行)。


此為所有人進入專案時看見的首頁。應包含專案特點及其它資訊。若您的插件包含以下內容,且未在其他地方說明,則下列資訊應被包含在您的 Ore 專案首頁中:指令、設定及權限。 另外,若與專案相關,請將以下內容包含在首頁中:


If your project utilizes a web API, phones home to collect data, or otherwise connects to a system external to the server it is running on, the presence of this feature as well as information on how to enable or disable it must be displayed prominently on the main page. If your project’s sole purpose involves utilizing an external system (such as a Sponge plugin that translates chat between languages), a configuration option to toggle making connections to that service is not required. If your plugin sends information (for example, plugin list or player data), the information collected must be listed on the main page.


  • 統計資料或使用資訊收集(「metrics」)
  • 地理位置
  • 翻譯服務
  • 在插件上運行的 Web 伺服器,為使用者提供資訊
  • 在插件上運行,監聽來自其他服務的請求的伺服器
  • IRC/Discord/Telegram/WhatsApp 的機器人或中繼


The category you choose should be accurate. Your project should use the narrowest category possible rather than any category that slightly applies. If no category appears accurate, the Miscellaneous category should be used.

Monetization / Advertising

Submissions may not be sold, nor may additional features be unlockable with payment. Advertisements and other revenue generating links (e.g. adfly) are not permitted. The documentation may contain a link to a page to donate to the project maintainer or other contributors as thanks but that page may not offer additional features or other plugins/mods for sale.

“Cracked” / Offline-mode / online-mode=false Support

Projects that explicitly state they are designed for such uses are not allowed. Some projects, such as authentication systems, may have functionality that can be useful for servers regardless of the server’s use of Mojang authentication, but they may not promote this additional usage or be specifically designed for servers avoiding Mojang auth. Projects designed for proxies requiring online-mode=false are allowed, provided they are not written to facilitate circumvention of Minecraft account ownership.


We aim to comply entirely with the Mojang EULA. Any plugins, services, posts, and/or links suspected of violating the EULA may be removed at the discretion of the Sponge Staff or at the request of Mojang AB.


Forks are permitted, provided they meet all items in the below list. Staff have the final say in what constitutes an accepted fork. Follow the license of the parent project appropriately.


  • Contain significant changes warranting the creation of a new project. This is to avoid “I changed the message colors in Plugin X and now I claim credit!”, or
  • Continue a plugin that has been abandoned, with proof the author has not been answering messages or has stated the project will no longer be updated.

Acknowledge or credit the past plugin and developers. Essentially, don’t claim it is a new plugin and exclusively your creation.


Files submitted should meet the following expectations:


A file that utilizes obfuscation will be denied unless it falls under the following exception:

NMS Obfuscation

This only applies for plugins which reference Minecraft or a Forge mod. Examples would be a plugin using Mixins or a plugin which doubles as a Forge mod (hybrid plugin). Provided that the only obfuscated references are to obfuscated source generated using ForgeGradle or VanillaGradle, the plugin is allowed to proceed through the review process.

Core Mods and Mixins: Modification of the Minecraft Base Code

Plugins and mods that use a system that modifies the Minecraft base code at runtime, (such as core mods and mixins) must disclose the edits that they make to the Minecraft code, and their reasoning for them. Sponge plugins should use the Sponge API where possible. Sponge implementations may implement technical restrictions to prevent such modifications from being applied by default. Files are not permitted to attempt to work around these restrictions, but can notify the user that enhanced functionality can be enabled via the Sponge provided configuration options.

外部連線(Web API、Phoning Home 等)

Many great features can be written by making calls to external systems. As well as being clearly documented in project descriptions, such functionality should be configurable and disabled by default. If your project’s sole purpose involves utilizing an external system (such as a Sponge plugin that translates chat between languages), connecting to that system does not need to be disableable. If your plugin sends information (e.g. a plugin list, player data, or map data) to external systems, the information collected must be listed on the main page (see above).

Execution of Downloaded Code

This is a security risk we will not tolerate. This includes downloading jar or class files, generation of bytecode from downloaded sources, and execution shell scripts.

Monetization / Advertising

All functionality present in your plugin should be usable without restriction, and can not require a license key to operate. External APIs, such as translation or geolocation services, that require payment for functionality can be allowed but must be discussed among staff prior to approval. Plugins may not be used to display advertisements.

Update Checking

Checking for updates should be performed using the provided Ore API. Your plugin may not link anywhere but Ore when directing users of your plugin to download new versions. Note that this update checking counts as an external connection, which must be documented and for which configuration must exist to disable it.

Privilege Granting

Plugins must not grant or revoke feature access to any particular user or group of users determined by the plugin developer. This includes the author granting themselves a special display name or letting themselves use a special command. Features, when applicable, should be locked behind permission nodes, rather than access being predetermined by the author. Commands for granting specific, pre-programmed users OP or permissions are not acceptable.