Geschlossen

[Quaeso]

Geschlossen.

 

[Chrisliebär❤️]

Das Tutorial an sich überzeugt mich im Umfang nicht so richtig und da könnte man durchaus noch ein paar erklärende Worte dazu packen. Vor allem wird der Command nicht mehr automatisch von Bukkit entfernt, wenn das Plugin deaktiviert wird.

Aber das Ganze wurde immerhin sauber gebaut und ich vermute der Anwendungsfall kommt tatsächlich häufiger vor, so dass ich das einfach mal freigeschaltet habe. Vielleicht magst du noch ein paar erklärende Wort ergänzen.

 

[Igelchen]

Nettes Tutorial, aber: gibt es irgendeinen Grund, warum man nicht einfach zur plugin.yml greifen sollte?

 

[Quaeso]

Nettes Tutorial, aber: gibt es irgendeinen Grund, warum man nicht einfach zur plugin.yml greifen sollte?

Eine gute Frage, natürlich bleibt dies jedem selbst überlassen, ich beantworte diese Frage jedoch an einem Beispiel(Voxelsniper):

  u:
    description: Undo changes made by yourself or other players.
    permission: voxelsniper.sniper
    aliases: [undo]
    usage: Invalid syntax. Use /<command> help to see valid syntax.
  uu:
    description: Undo changes made by other players.
    permission: voxelsniper.sniper
    aliases: [undouser]
    usage: Invalid syntax. Use /<command> help to see valid syntax.
  d:
    description: Reverts all values back to defaults.
    permission: voxelsniper.sniper
    alias: [default]
    usage: Invalid syntax. Use /<command> help to see valid syntax.
  p:
    description: Change the currently active performer for the performer brush.
    permission: voxelsniper.sniper
    aliases: [perf, performer]
    usage: Invalid syntax. Use /<command> help to see valid syntax.

Ich selbst benutze dieses System damit meine Plugin.yml Kompakt wird, ich persönlich mag es nicht wenn in einer File 400 Zeilen drin sind wie man oben sehen kann(Die Voxelsnip Plugin.yml gekürzt), jedoch überlasse ich es dir ob du dieses System verwenden möchtest, da jeder anders arbeitet und somit über eine andere Erstellung seiner Syntax verfügt.

Das Tutorial an sich überzeugt mich im Umfang nicht so richtig und da könnte man durchaus noch ein paar erklärende Worte dazu packen. Vor allem wird der Command nicht mehr automatisch von Bukkit entfernt, wenn das Plugin deaktiviert wird.

Aber das Ganze wurde immerhin sauber gebaut und ich vermute der Anwendungsfall kommt tatsächlich häufiger vor, so dass ich das einfach mal freigeschaltet habe. Vielleicht magst du noch ein paar erklärende Wort ergänzen.

Danke für dein Feedback, ich habe eine kleine Erklärung hinzugefügt und kurz erläutert was diese System genau macht und was dadurch entfällt.

" Vor allem wird der Command nicht mehr automatisch von Bukkit entfernt, wenn das Plugin deaktiviert wird. "
Ich werde mich dem annehmen und in den nächsten den Code updaten.


Lg.

 

[tinyoverflow]

Hallo zusammen,

ich begrüße es, dass du dir die Mühe gemacht hast ein Tutorial zu schreiben.
Allerdings sehe ich hier gleich mehrere Schwierigkeiten an dieser Technik.

Durch das Umgehen der Registrierung der Plugins innerhalb der plugin.yml beschert das einige Probleme. Der Server weiß nicht mehr zu welchem Plugin ein Command gehört. Sie können, wie mein Vorredner bereits erläuterte, nicht mehr entfernt werden, wenn das Plugin deaktiviert wird. Weiterhin wird kein Exception Handling betrieben. Wenn irgendwas passiert, fliegt dir alles um die Ohren.

Die plugin.yml ist für Metadaten zum Plugin da. Dazu gehören nunmal auch Commands und Permissions. Wenn sie 400 Zeilen lang wird, dann ist das so. Dann heißt das aber auch, dass du gute Arbeit geleistet hast dein Plugin ordentlich zu dokumentieren.

Im gleichen Satz gibst du an, dass es ja jedem frei steht dies so zu machen. Das ist absolut richtig. Allerdings arbeitest du hier an der API vorbei. Gerade beim Einsatz von Reflections, wie sie hier genutzt werden, solltest du dir jedoch überlegen, ob das der richtige Weg ist. Siehe Zeile 71-73 deiner AbstractCommands-Klasse. Meines Erachtens nach ist er das nicht.

Viele Grüße
tinyoverflow

 

[JOO200]

Es gibt genug bestehende command Frameworks wie cloud, acf oder piston, die ohne Einträge in der plugin.yml auskommen. Die lösen das auch passend mit dem entsprechenden einklinken in die commandmap. In den aktuelleren Versionen von Paper ist das auch ganz ohne reflections möglich.

Dass das alles in der plugin.yml stehen muss, halte ich für eine sehr verkürzte Antwort, die nicht stimmen muss.