modrinth / labrinth

Our Rust-based backend utilizing the actix-web framework to serve Modrinth's API.
https://modrinth.com
GNU Affero General Public License v3.0
532 stars 74 forks source link

Environment tags should be reworked to be more encompassing and intuitive #895

Open maow-tty opened 6 months ago

maow-tty commented 6 months ago

Is your suggested enhancement related to a problem? Please describe.

Currently, it is believed "environments" describe the logical sides that a distributed mod is intended for, where "client-side" refers to the logical client and "server-side" refers to the logical servers (integrated and dedicated). There are two flaws: this is not immediately intuitive to all users, authors, or developers, and it leaves some environment relationships unrecognized by Labrinth.

It is proper for world generation mods to categorize themselves as "server-only" (assuming "server" refers to the logical servers), as they do not require the functionality of the logical client and at least one logical server must be present for them to function. However, most people will interpret "server" as meaning "physical server," since that is its common, casual definition.

The result is that some may interpret these mods as only being able to be ran through a dedicated logical server. This misconception applies not just to users but also third-party developers or mod authors, which may exacerbate the issue.

Real world examples of projects:

On the topic of the "unrecognized environment relationships," not being able to refer directly to the dedicated or integrated logical servers means singleplayer-only and multiplayer-only mods cannot be represented through Labrinth's environment flags. While singleplayer-only mods are unconventional and not considered by any major mod loader, multiplayer-only mods have some precedence due to dedicated server plugins, which cannot run in integrated logical server environments.

Describe the solution you'd like

We suggest implementing a replacement for client_side and server_side where the integrated and dedicated logical servers have their own flags and, rather than being project settings, are defined per release of the project. Filtering and display of environments takes into account the complete set of environments, similar to how platforms and versions work. This is to allow for the accurate portrayal of environment changes, i.e. a mod may later stop supporting the logical client or may start supporting the logical integrated server, and this is important for third-party tools that work with versions rather than projects.

"environment": {
    "client": true,
    "integrated_server": true,
    "dedicated_server": true
}

This suggestion deems "optional" superfluous. It is useful for users to know strict compatibility, rather than loose preference, especially when that preference should be implemented on the modpack-level.

While the above would be confusing to an end-user who is unaware of the integrated and dedicated differentiation, Modrinth's interface may display different terminology, such as "client," "singleplayer," and "server." Once this alternative system is implemented, new environment information can be derived from the legacy client_side and server_side values, i.e. the following corresponds to a server-only mod:

"environment": {
    "client": false,
    "integrated_server": true,
    "dedicated_server": true
}

The only caveat is that it is impossible to properly re-map to these values on singleplayer-only or multiplayer-only mods due to the limits of the legacy environments system. However, these types of mods are an edge-case; due to their scarcity outside of plugins, it is unlikely the inaccurate information will greatly impact users, especially considering it would be equivalent to the information presented by the legacy system regardless.

Describe alternatives you've considered

An alternative to the above proposal is to define physical client and physical server flags for each release. This may be more intuitive, although it technically provides less information. Most users will only care about physical sides, but it would be unfortunate for third-party tooling that needs the integrated/dedicated distinction.

Additional context

This issue is intended to address problems that have also been presented by #879 and #894. It is not a duplicate.