- Source Code
- https://github.com/CubBossa/CommonSettings
CommonSettings ist eine kleine API mit dem Hintergedanken, die Bedienung von Usersettings (Plottitles, Partikel, Chat, Fly, ...) zu vereinheitlichen, sodass mit Einbinden der API einfache Setting GUIs, Webinterfaces oder Commands geschrieben werden können, ohne die "Setting-Provider" als Dependency einzubinden oder zu kennen. Abstrakt, sozusagen 
Nach meiner Erfahrung als Serverleiter hat mich immer wieder geärgert, dass nur das wirklich schön einheitlich ist, was man auch selbst gemacht hat und halt Vault.
Wir hatten unser eigenes Menü um Settings zu verwalten. Settings wie die PlotSquared Toggle Befehle waren leider nicht enthalten und ein einfaches dispatchCommand hätte den Zauber nicht gewirkt, weil unser Settings GUI den Zustand der Einstellung (An/Aus) angezeigt hat und eine Resetfunktion hatte
Der Server ist Geschichte, aber ich dachte für ein wenig Vereinheitlichung kann ich mich trotzdem einsetzen. Die Idee ist, dass es eine schlanke API gibt, die nur eine Übersicht über die existierenden Settings behält. Ein Plugin registriert ein Setting via Interface. Andere Plugins können auf einzelne Settings, alle Settings eines Typs, Settings nach Tags, Settings eines Plugin oder einfach alle Settings zugreifen.
Dinge wie /p toggle titles lassen sich also integrieren ohne Bukkit.dispatchCommand und ohne PlotSquaredDependency. Genau wie PlayerParticles /pp toggle und alle anderen. Da man großen Plugins nicht verübeln kann, sich nicht auf so eine kleine API einzulassen, lassen sich deren Spielersettings ja auch problemlos aus einem eigenen Plugin heraus mit der entsprechenden Codeeinbindung registrieren.
Grundsätzliches Problem ist, dass einige mitmachen müssen, damit sich soetwas nach 10 Jahren Minecraft noch etabliert. Daher möchte ich die Resource hier einmal vorstellen und hoffen. Und gerne auch Feedback der Programmiererfahrenen erfragen Auch über Contributions würde ich mich sehr freuen, ich finde die Idee der API gut und wäre einfach glücklich, wenn es sich mit Hilfe von Zusammenarbeit umsetzen lässt.
Hier ist ein kleiner Codeeinblick, alles andere findet sich dann im angegebenen GitHub Link!
Nach meiner Erfahrung als Serverleiter hat mich immer wieder geärgert, dass nur das wirklich schön einheitlich ist, was man auch selbst gemacht hat
und halt Vault.Wir hatten unser eigenes Menü um Settings zu verwalten. Settings wie die PlotSquared Toggle Befehle waren leider nicht enthalten und ein einfaches dispatchCommand hätte den Zauber nicht gewirkt, weil unser Settings GUI den Zustand der Einstellung (An/Aus) angezeigt hat und eine Resetfunktion hatte
Der Server ist Geschichte, aber ich dachte für ein wenig Vereinheitlichung kann ich mich trotzdem einsetzen. Die Idee ist, dass es eine schlanke API gibt, die nur eine Übersicht über die existierenden Settings behält. Ein Plugin registriert ein Setting via Interface. Andere Plugins können auf einzelne Settings, alle Settings eines Typs, Settings nach Tags, Settings eines Plugin oder einfach alle Settings zugreifen.
Dinge wie /p toggle titles lassen sich also integrieren ohne Bukkit.dispatchCommand und ohne PlotSquaredDependency. Genau wie PlayerParticles /pp toggle und alle anderen. Da man großen Plugins nicht verübeln kann, sich nicht auf so eine kleine API einzulassen, lassen sich deren Spielersettings ja auch problemlos aus einem eigenen Plugin heraus mit der entsprechenden Codeeinbindung registrieren.
Grundsätzliches Problem ist, dass einige mitmachen müssen, damit sich soetwas nach 10 Jahren Minecraft noch etabliert. Daher möchte ich die Resource hier einmal vorstellen und hoffen. Und gerne auch Feedback der Programmiererfahrenen erfragen Auch über Contributions würde ich mich sehr freuen, ich finde die Idee der API gut und wäre einfach glücklich, wenn es sich mit Hilfe von Zusammenarbeit umsetzen lässt.
Hier ist ein kleiner Codeeinblick, alles andere findet sich dann im angegebenen GitHub Link!
Enum-Setting Registrierung via Builder:
SettingsAPI.getInstance().registerSetting(new SettingBuilder<>(Material.class, new NamespacedKey(plugin.getName(), "material"))
.withTitle("String Setting") // or
.withTitle(Component.text("String Setting with Component Title"))
.withDescription("short", "long")
.withPermissionNode(null)
.withFlagNullable()
.withFlagNotThreadSafe()
.withTag("example", "chat", "particle", "cosmetics", ...)
.withGetter(uuid -> ENUM.getOrDefault(uuid, Material.AIR))
.withAsyncGetter(uuid -> CompletableFuture.completedFuture(ENUM.getOrDefault(uuid, Material.AIR)))
.withSetter((uuid, newValue) -> {
ENUM.put(uuid, newValue);
return CompletableFuture.completedFuture(Setting.SettingChangeResult.SUCCESS);
})
.build());