exportconsthtml=`<p>With the addition of modpacks, creating new project types has become a lot easier. Our first additions to our new system are plugins and resource packs. We'll also be working on adding datapacks, shader packs, and worlds after payouts are released.</p><p>Don't worry - this hasn't taken away an awful lot of development time from author payouts. Those are still being worked on!</p><h2>Plugins</h2><p>With plugins, we're supporting five loaders and three proxies: Bukkit, Spigot, Paper, Purpur, Sponge, BungeeCord, Waterfall, and Velocity.</p><p>Several new categories have specifically been added for plugins, though mod categories can be used for plugins and vice versa.</p><p><a href="/plugins" rel="noopener nofollow ugc">Go browse our plugin section!</a></p><h3>Why add plugins?</h3><p>This is a question we've received quite often since we first announced our intention to host plugins, so let's break it down a bit.</p><p>Currently, there are three main platforms on which plugins can be downloaded from: Bukkit, Spigot, and Sponge's Ore. Notice the main issue there? These sites are bound to a specific loader. This isn't inherently <em>bad</em> - however, as forks and new projects spawn, there is a noticeable lack of flexibility in what can be hosted on a given platform. For example, Spigot is unable to host plugins which specifically depend on the exclusive features provided by Paper's API. Paper's solution to this is to build their own platform, but this simply perpetuates the same problem.</p><p>The best solution here is to create a separate platform which is unbiased and flexible enough to adapt to a changing ecosystem. Modrinth is the perfect candidate for this - after all, plugins are mods under a different name, and likewise mods are plugins under a different name.</p><p>No matter the situation, authors are always allowed to upload their plugins to multiple sites. Build automation is incredibly easy to set up, especially with "set it and forget it" build tools such as <a href="https://github.com/modrinth/minotaur" rel="noopener nofollow ugc">Minotaur</a>.</p><h3>Will paid plugins be supported?</h3><p>No. Modrinth does not have the infrastructure to support this, and it's not currently planned. Author payouts are still being worked on.</p><h3>What about mods that have plugin versions and vice versa?</h3><p>Modrinth is taking a unique approach to this. While the search pages are separate, in reality, the backend is the same. You can select plugin loaders when creating a mod and you can select mod loaders when creating a plugin. The split only exists on the frontend so that projects like <a href="/mod/chunky" rel="noopener nofollow ugc">Chunky</a> can share a single page across their versions.</p><p>Plugins which also have versions for mod loaders will be displayed under the <code>/mod/</code> URL on the frontend. Plugins without mod loader versions are displayed under <code>/plugin/</code>.</p><h2>Resource packs</h2><p>The other thing we've added support for is resource packs!</p><p>Previously we hinted at Bedrock resource packs being supported in addition to Java resource packs. We've decided not to add Bedrock resource packs until we also add support for other Bedrock resources for various technical reasons.</p><p><a href="/resourcepacks" rel="noopener nofollow ugc">Go browse our resource pack section!</a></p><h3>Secondary categories</h3><p>Resource packs are capable of adding a wide range of different things, like fonts, sounds, and core shaders. We found that the current category system was inadequate to account for all of these, especially with the three maximum limit. Thus, we've introduced a "secondary category" system, for categories which don't display by default but can still be searched. These secondary categories have a limit of 255 instead of three. Please add as many secondary categories as are relevant!</p><p>On search pages, "Features" have been split into their own header. Where categories for resource packs can be accurately described as themes, feature
