Richtlinien zum Einreichen von Ore Plugins

Warnung

Dieses Dokument bezieht sich auf eine veralte SpongeAPI-Version und wird nicht länger aktiv gepflegt. Die Richtlinien und einige Links haben sich geändert. Bitte gehe stattdessen zur aktuellen Version der Dokumentation.

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 Sponge Projekt handelt (Beispielsweise ist SpongeWarp nicht erlaubt, während Cool Warps for Sponge erlaubt ist).

Haupt-Dokumentations-Seite (Home)

Dies ist die erste Seite, die jeder als erstes sieht, wenn es sich dein Projekt ansieht. Die Informationen auf dieser Seite sollten eine Beschreibung der Features deines Projektes enthalten. Die folgenden Punkten sollten ebenfalls auf der Haupt-Seite dokumentiert werden, sofern sie nicht auf anderen Ore-Seiten beschrieben sind: Die Befehle (commands), Konfigurationsoptionen (configuration) und die Berechtigungsstufen (permission nodes). Außerdem, müssen die nachfolgenden Informationen auf der Haupt-Seite dokumentiert werden, sofern sie auf dein Projekt zutreffen:

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)

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 ein System verwendet, dass den Minecraft Basis Code zur Laufzeit verändert, (beispielsweise Core-Mods und Mixins) müssen ihre Änderungen am Minecraft Code offenlegen und diese begründen. Sponge Plugins müssen die Sponge API verwenden, sofern es möglich ist. Sponge Implementierungen könnten technische Maßnahmen enthalten, die diese Veränderungen standardmäßig verhindern. Es ist nicht gestattet zu versuchen, diese Beschränkungen zu umgehen. Aber es ist gestattet den Nutzer darauf hinzuweisen, dass erweiterte Funktionen über die von Sponge bereitgestellten Konfigurationsoption freigeschaltet werden können.

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).

Ausführung von heruntergeladenem Code

Dies ist ein Sicherheitsrisiko, dass wir nicht tolerieren. Dies schließt das Herunterladen von Jar oder Class-Dateien, die Generierung von Bytecode anhand von Heruntergeladenem Quellcode und die Ausführung von Shell-Skripten mit ein.

Monetarisierung / Werbung

Alle Funktionen, die in deinem Plugin enthalten sind, müssen ohne Einschränkung benutzbar sein und dürfen nicht erst einen Lizenzschlüssel benötigen. Externe Schnittstellen, wie Übersetzungs- und Geolokalisierung-Dienste, die eine Bezahlung für die Verwendung erfordern, könnten erlaubt sein, sofern vorher die Zustimmung des Teams eingeholt wurde. Plugins dürfen keine Werbung anzeigen.

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.