BStats overhaul

[sovdeeth]

Description

• every exposed config option now has a pie chart
• the config options with multiple settings have a drill chart, where layer one shows the default value and "other". Clicking on other will show you a pie chart of all the options people chose.
• effects commands also got a drilldown, showing the character people use for effect commands
• there's a new mc and skript version chart that only shows major versions on the top level and can be clicked to see the details for each major version

All the legacy charts will stick around but will be relegated to the bottom of the page after a few versions pass. The new charts will only show users on 2.9.2+, so the legacy charts are still interesting to view, but by the time 2.10.x is out they shouldn't be that useful for us.

Chart changes are live at https://bstats.org/plugin/bukkit/Skript/722, with my test server as the only server running the new charts.

---

Target Minecraft Versions: any
Requirements: none
Related Issues: none

[APickledWalrus]

looks good. as mentioned on Discord, we should add a way to obtain the default value of an option rather than hardcode it here

[APickledWalrus]

great work!

[TheLimeGlass]

Why don't you make SkriptMetrics.java within the ch.njol.skript package so you don't need to manipulate these fields to be public.

These nodes really don't need to be public, but also don't have any real harm being public other than Option#set method.

These field names could also be uppercase now if they are to remain public.

[sovdeeth]

good point, @APickledWalrus thoughts about package location?

[APickledWalrus]

I don't think it really matters whether these fields are public, but it also doesn't matter where this class is. If you'd prefer to keep their access the same, then there would be no issue to move this class.

[sovdeeth]

I think I'd prefer new stuff to stay in the skriptlang package if possible so I'll keep them public and just edit the formatting like you suggested, lime.

[sovdeeth]

well actually looking at it the whole file needs to be updated in terms of formatting, they're all camelCase and PubSF

[TheLimeGlass]

I don't think it really matters whether these fields are public, but it also doesn't matter where this class is. If you'd prefer to keep their access the same, then there would be no issue to move this class.

The file location does matter as it's keeping the file within the ch.njol.skript package to allow the fields to keep their package access.

I think I'd prefer new stuff to stay in the skriptlang package if possible so I'll keep them public and just edit the formatting like you suggested, lime.

Yes, in the case you don't require a class existing from the old packages. This is a new class that requires access to the old class, and will be renamed in the future when the whole ch.njol.skript package gets renamed.

Not a huge problem as other fields are public too.

[sovdeeth]

I think the best route here would be to fix up SkriptConfig in a separate PR (which I will do shortly) so that it doesn't rely on public static fields. This way the metrics class just has to call something like Skript.getConfig().getXYZValue() and there's no package concerns. So for now I'm going to leave it as is, with the knowledge that it will be replaced soon.