Richtlinien zum Einreichen von Ore Plugins

Willkommen bei den Richtlinien zum Einreichen von Ore Inhalten. Dieses Dokument bietet eine Übersicht über unsere Anforderungen sowohl an dein Projekt aus auch an deinen Datei Upload.

Bitte beachte, dass dies nur eine grobe Richtlinie ist und das Ore Team, im folgenden nur „Team“ genannt, bestimmte Aktionen erlauben oder verbieten kann, die hier nicht ausdrücklich aufgeführt sind.

Projekte

Eingereichte Projekte sollten die folgenden Erwartungen erfüllen:

Name

Der Name deines Projektes sollte keine Versionsnummer, Zusammenfassung oder andere Beschreibungen enthalten. Der Name sollte einzigartig und originell sein und darf nicht andeuten, dass es sich um ein offizielles Sponge Projekt handelt.

Beispiele für Namen, die nicht akzeptabel sind:

  • SpongeWarp

  • SpongeHome

  • SpongeEssentials

  • SpongeCloud

Beispiele für Namen, die akzeptabel sind:

  • CoolWarps-Sponge

  • MoneyMiner-Sponge

  • Golfball-for-Sponge

  • Calendar-for-Sponge

Haupt-Dokumentations-Seite (Home)

This is the first page that anyone will see when visiting your project. Information here should include a clear and concise description of your project’s features and goals. The following, if present in your plugin, should be documented on the main page if relevant:

Verbindungen zu externen Systemen

Wenn deine Projekt eine Web-API verwendet, nach Hause telefoniert um Statiken zu sammeln oder sich sonst irgendwie mit einem anderen System verbindet, außer dem Server, auf dem das Projekt läuft, musst du das Vorhandensein des Features, inklusive einer Beschreibung, wie man die Funktion aktiviert bzw deaktiviert, gut sichtbar auf der Haupt-Seite anzeigen. Wenn der gesamte Zweck des Plugins darin besteht, ein externes System zu verwenden (wie beispielsweise ein Sponge Plugin, dass Chat Nachrichten übersetzt), ist eine Option zum An-/Ausschalten der Verbindung nicht von Nöten. Wenn das Plugin Daten/Statistiken (beispielsweise installierte Plugins oder Spielerdaten) sendet, muss ebenfalls auf der Hauptseite angegeben werden, welche Informationen gesammelt werden.

Beispiele von Systemen, die Dokumentation benötigen:

  • Statistiken oder Nutzungsinformationen (‘metrics’)

  • Standort (Geolocation)

  • Übersetzungsdienste

  • Webserver, die im Plugin laufen und Informationen für Benutzer bereitstellen

  • Server, die im Plugin laufen und auf Anfragen von anderen Diensten lauschen

  • IRC/Discord/Telegram/WhatsApp Bots oder Weiterleitungen (Relays)

Examples of systems that do not require documentation:

  • Local databases or database connections specified by the end-user

Kategorie

Die von dir gewählte Kategorie sollte präzise und so genau wie möglich sein. Anstatt das du jede Kategorie auswählst, die auch nur einen Hauch auf dein Projekt zutrifft, solltest du nur die am Besten zutreffende Kategorie wählen. Wenn keine Kategorie zutrifft, solltest du die Miscellaneous ( Verschiedenes) Kategorie auswählen.

Monetarisierung / Werbung

Einreichungen dürfen nicht verkauft werden noch dürfen zusätzliche Features gegen Bezahlung freischaltbar sein. Werbung oder andere Gewinn generierende Links (z.B. Adfly) sind nicht gestattet. Die Dokumentation darf einen Link zu einer Seite enthalten, auf der man für das Projekt oder dessen Beitragenden mit einer Spende danken kann, aber diese Seite darf keine zusätzlichen Features oder Plugins/Mods zum Kauf anbieten.

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

Projekte die ausdrücklich angeben, dass sie für diesen Zweck entwickelt wurden, sind nicht erlaubt. Manche Projekte, wie zum Beispiel Authorisierungs Systeme, dürfen Funktionen enthalten, die unabhängig von der Einstellung des Server bzgl. der Verwendung der Mojang Authentifizierung nützlich ist, allerdings dürfen sie diese zusätzliche Funktionen nicht anwerben. Außerdem dürfen sie nicht speziell für Server entwickelt werden, die die Authentifizierung durch Mojang umgehen. Projekte, die als Proxies gedacht sind und online-mode=false benötigen sind erlaubt, solange sie nicht geschrieben wurden, um den Besitz eines Minecraft Accounts zu umgehen.

EULA

Wir versuchen vollständig der Mojang EULA zu entsprechen. Deshalb können alle Plugins, Dienste, Dienstleistungen, Posts und/oder Links, die möglicherweise nicht der EULA entsprechen, durch uns oder auf Verlangen von Mojang AB entfernt werden.

Forks

Forks sind erlaubt, solange sie alle der folgenden Punkte einhalten. Die endgültige Entscheidung darüber, was ein akzeptierter Fork ist, obliegt den Team-Mitgliedern. Folge auf jeden Fall den Lizenzbestimmungen des Hauptprojektes.

Entweder:

  • Habe wesentliche Änderungen, die die Erstellung eines neuen Projektes rechtfertigen. Dies soll verhindern, dass jemand nur ein paar Farben in Plugin X geändert hat und nun Ansprüche stellt. Oder

  • Führe ein Plugin fort, das nicht mehr weiterentwickelt wird, bei dem offensichtlich ist, dass der Autor die Nachrichten nicht mehr beantwortet oder er angegeben hat, dass er das Projekt nicht länger aktualisiert.

Erkenne die Leistungen des vorherigen Plugins und Entwicklers an oder schreibe ihnen das Plugin zu. Im besonderen gehe nicht daher und behaupte, dies sein ein neues Plugin, das ausschließlich von dir entwickelt wurde.

Dateien

Die eingereichten Dateien sollten die folgenden Erwartungen erfüllen:

Verschleierungen (Obfuscation)

Eine Datei, die Verschleierungstechniken (Obfuscation) einsetzt, wird abgelehnt, es sei den sie fällt unter die folgenden Ausnahmen:

NMS Obfuscation

Dies trifft nur auf Plugins zu, welche Minecraft oder einen Forge Mod referenzieren. Beispiele wären ein Plugin, dass Mixins benutzt oder ein Plugin, dass auch ein Forge Mod ist (Hybrides Plugin). Unter der Voraussetzung, dass nur die Referenzen auf verschleierten Code verschleiert sind und mit ForgeGradle oder VanillaGradle erstellt wurden, darf das Plugin weiter durch die Überprüfungsprozess gehen.

Core Mods und Mixins: Modifizierungen am Minecraft Basis Code

Plugins und Mods, die eine System benutzen, dass den Minecraft-Basis-Code zur Laufzeit verändern, (wie zum Beispiel ein Core-Mod oder Mixins) müssen die Änderungen, die sie am Minecraft-Code vornehmen offenlegen und begründen, warum diese benötigt werden. Sponge Plugins sollten immer die SpongeAPI verwenden, sofern möglich. Sponge Implementierungen implementieren möglicherweise technische Beschränkungen, die verhindern, dass derartige Modification standardmäßig angewendet werden. Dateien, die versuchen diese Begrenzungen zu umgehen, sind nicht gestattet, aber können den Nutzer informieren, dass erweiterte Funktionalität mit Hilfe der von Sponge bereitgestellten Konfiguration aktiviert werden kann.

Verbindungen zu externen Systemen (Web API, nach Hause telefonieren, etc.)

Viele großartige Funktionen können durch die Verbindung zu externen Systemen geschrieben werden. Neben einer deutlichen Dokumentation in der Projektbeschreibung, sollten diese Funktionen standardmäßig deaktiviert sein. Wenn der einzige Zweck des Plugins die Verwendung des externen Systems mit einschließt (beispielsweise bei einem Sponge Plugin, dass Chat-Nachrichten zwischen verschiedenen Sprachen übersetzt), dann ist eine Abschaltfunktion für diese Verbindung nicht von Nöten. Sollte das Plugin Informationen (wie zum Beispiel eine Liste von Plugins, Spieler-Daten oder Informationen über die Karte) an ein externes System senden, so sind die gesammelten Daten auf der Hauptseite des Plugins aufzulisten (Siehe oben).

Metrics (Data Collection)

Whenever data collected about the server (often referred to as „stats“ or „metrics“ data, such as server or plugin versions, as well as usage information) is to be sent to an external service, the plugin must first query the Sponge API MetricsConfigManager. Documentation on doing so can be found Here. This API must be checked each time data is sent, not only once. Plugins may not modify the values the API returns, but may encourage users to make the decision to enable the collection and sending of this data for their plugin.

Bemerkung

This API was added in API 7.1.0. Plugins built against older API versions must instead check against a variable in a configuration file unique to that plugin for the enabled/disabled status, which must also default to disabled.

Ausführung von heruntergeladenem Code

We cannot ensure that content that is downloaded and executed at runtime is safe and complies with our guidelines. Any project that performs downloads and execution of code will have warnings on the project page and a warning prior to download to ensure users know the risk.

The following conditions must be also be met by the project:

  • Downloaded content must have hard-coded SHA256 (or better) based hash checking

  • Downloaded content must be explained in the main project page as to what is downloaded and what purpose it serves

  • Downloaded content must be performed over HTTPS connections

  • Downloaded content must not be hosted in a location that will limit downloads (e.g. DropBox, Google Drive)

  • Downloading another plugin must go through Ore’s API in the same fashion as Update Checking

Monetarisierung / Werbung

All functionality present in your plugin should be usable without restriction, and cannot 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-Prüfung

Überprüfungen, ob Updates verfügbar sind, sollten über die von Ore bereitgestellte API durchgeführt werden. Dein Plugin darf nur auf Ore verweisen, wenn es den Benutzern neue Versionen zum Download anbietet. Bitte beachte, dass die Überprüfung auf Updates als externe Verbindung zählt und daher dokumentiert sein muss ebenso wie es eine Konfigurationsoption geben muss, dies zu deaktivieren.

Vergabe von Privilegien

Plugins dürfen nicht vom Plugin Entwickler bestimmten Benutzern oder Gruppen Zugriff auf ein bestimmtes Feature geben oder verwehren. Dazu zählt unter anderem, dass sich der Autor einen besonderen Anzeigenamen oder Zugriff auf einen Befehl gibt. Funktionen sollten, sofern möglich, über Berechtigungen verwaltet werden, anstatt vom Autor vordefiniert zu sein. Befehle, die bestimmten, vorher festgelegten Benutzern OP oder sonstige Berechtigungen geben sind grundsätzlich nicht erlaubt.