// AUTO-GENERATED FILE - DO NOT EDIT
export const html = `<p><strong>Hey creators!</strong></p><p>Over the years, we've taken in lots of feedback regarding how we identify client-side and server-side mods and modpacks on Modrinth. It's a surprisingly nuanced issue, and careful consideration has finally led us to implementing a new system that fixes many of the issues with the old one.</p><h2>What do I need to do?</h2><p>If you want to jump right into what you need to do now, just visit your <a href="/dashboard/projects" rel="noopener nofollow ugc">Projects page</a> and look for any of your mod or modpack projects with an orange warning button next to the settings button. This will take you to the new Environments page in your project's settings with a bunch of different options for configuring your project's environment.</p><p><img src="/news/article/new-environments/env-settings.webp" alt="Screenshot of the new Modrinth Environment settings page. A warning message explains that the environment system has been updated. Options are listed with radio buttons, including Client-side only (selected), Server-side only, Client and server, and Singleplayer only, each with descriptions and sub-options."></p><p><strong>If you do not verify your environments, in the future a warning may display on your project to inform users that the environment information may be outdated or incorrect.</strong></p><p>Read on to learn more about why we've made this change and for a more thorough explanation of each option, in case you find any of them confusing.</p><h2>What was wrong with the old system?</h2><p>Originally, Modrinth's environment metadata came in the form of two fields for Client-side and Server-side compatibility. Each option could be set to 'Required', 'Optional', or 'Unsupported'. This did the job, but it left some ambiguities and led to many confused creators mis-labeling their mods.</p><ol><li><strong>Certain combinations of options don't make logical sense</strong>, such as both sides being 'Unsupported', or one side being 'Optional' and the other being 'Unsupported'. To some people, they may feel that since <em>installing</em> the mod is optional, that might be a logical choice, when users and automated tools might be expecting it to be labeled as 'Required'</li><li><strong>Terms like 'Unsupported' are interpreted differently</strong> by different people. If something is 'Unsupported' on the server-side, does that mean it crashes when installed on a server?</li><li><strong>Most server-side only mods also work in Singleplayer</strong>, even if they don't perform any functions on the client-side directly. Some creators of server-sided mods chose to mark client-side as 'Optional' because of this, even if it did absolutely nothing on the client-side because in order to use it in Singleplayer, you technically install it on the &quot;client&quot;</li><li><strong>Not all real-world combinations even could be represented</strong> by this old system. There are some mods that only make sense in a singleplayer environment, or some that only make sense on dedicated servers and <em>not</em> in Singleplayer.</li><li><strong>Conflicting information is out there</strong> on what exactly these terms meant. The website told creators to treat the client and server as the <em>logical</em> client and servers, but some other people's guides and tooling treated them as referring to the <em>physical</em> client and server. This includes the Modrinth Pack (.mrpack) specification, which confusingly uses the same required/optional/unsupported terminology to refer to the physical sides when defining which files should be installed in the client and server distributions.</li></ol><h2>How does the new system work?</h2><p>The new system enumerates all expected use-cases into distinct options that can be handled in unique ways by tools like launchers, mod managers, and modpack assemblers.</p><p>The new options are as follows:</p><ul><li><strong>Client-side only</strong> (<code>client_only</code>)<ul><li>All functionality is performed exclusively on the client side. Should be compatible with vanilla servers.</li><li>Example: <a href="/mod/modmenu" rel="noopener nofollow ugc">Mod Menu</a>. It only adds a menu to view the list of mods installed on your client, which doesn't need to be installed on the server.</li></ul></li><li><strong>Server-side only / Works in singleplayer</strong> (<code>server_only</code>)<ul><li>All functionality is performed exclusively on the server side. Should be compatible with vanilla clients if only installed on the server. Also works in Singleplayer.</li><li>Example: <a href="/mod/yungs-bridges" rel="noopener nofollow ugc">YUNG's Bridges</a>. It only adds structures which don't need to be present on the client-side.</li></ul></li><li><strong>Server-side only / Dedicated server only</strong> (<code>dedicated_server_only</code>)<ul><li>Only runs on a dedicated server, and not in Singleplayer.</li><li>Example: <a href="/mod/better-fabric-console" rel="noopener nofollow ugc">Better Fabric Console</a>. Its functionality does not work in singleplayer, because it modifies the dedicated server console.</li></ul></li><li><strong>Client and server / Required on both</strong> (<code>client_and_server</code>)<ul><li>Must be installed on both the client and server.</li><li>Example: <a href="/mod/cobblemon" rel="noopener nofollow ugc">Cobblemon</a>. It adds entities, blocks, and items that need to be on both the client and server to work.</li></ul></li><li><strong>Client and server / Optional on client</strong> (<code>server_only_client_optional</code>)<ul><li>Must be on the server, but can be on the client as well for enhanced functionality</li><li>Example: <a href="/mod/polymer" rel="noopener nofollow ugc">Polymer</a>. It functions on the server-side, but if installed on the client it can improve the experience when playing on a server running Polymer.</li></ul></li><li><strong>Client and server / Optional on server</strong> (<code>client_only_server_optional</code>)<ul><li>Must be on the client, but can be on the server as well for enhanced functionality</li><li>Example: <a href="/mod/appleskin" rel="noopener nofollow ugc">AppleSkin</a>. It functions on the client-side, but if installed on the server it can provide more accurate saturation information.</li></ul></li><li><strong>Client or server / Works best on both</strong> (<code>client_or_server_prefers_both</code>)<ul><li>Can be installed on just the client or just the server to function, but functionality is enhanced when it is on both.</li><li>Example: <a href="/mod/no-chat-reports" rel="noopener nofollow ugc">No Chat Reports</a>. The mod functions on just the client or just the server, but each comes with drawbacks. For the best functionality, you need to install it on both.</li></ul></li><li><strong>Client or server / Works the same on either</strong> (<code>client_or_server</code>)<ul><li>Can be installed on just the client or just the server, and either one would enable full functionality. There would be no reason to install it on both.</li><li>Example: <a href="/mod/entity-view-distance" rel="noopener nofollow ugc">Entity View Distance</a>. It lets you perform the same functionality of limiting entity view distance on either the client or the server.</li></ul></li><li><strong>Singleplayer only</strong> (<code>singleplayer_only</code>)<ul><li>Only works in Singleplayer, does not function in a Multiplayer environment.</li><li>Example: <a href="/mod/lan-server-properties" rel="noopener nofollow ugc">LAN Server Properties</a>. It modifies a feature that only exists in Singleplayer, the Open to LAN menu.</li></ul></li></ul><h2>What's next</h2><p>This is a great first step towards us fixing many common issues that have been affecting Modrinth users, such as:</p><ul><li>Client-side mods being installed to Modrinth Servers, causing crashes</li><li>Modpack exporting in Modrinth App and other launchers using the Modrinth API such as Prism Launcher, MultiMC, and ATLauncher not having accurate and reliable metadata to pull from in order to build universal client and server Modrinth Pack files.</li></ul><p>However, this is just the first step. Before we can improve the tooling around creating and using modpacks, we need as many Modrinth projects as possible to have accurate metadata.</p><p>Currently, the new environment metadata is also only available in the experimental API v3, which is <em>not</em> intended for general use. When we're ready, we plan to integrate this metadata into API v2, so that it can be used in production by third parties. For now, developers using the Modrinth API should not worry about these environment changes, just keep them in mind for the future.</p><p>Thank you all for continuing to support Modrinth!</p><p><strong>Prospector</strong><br><em>Founding Software Engineer</em></p>`;