You can directly @Inject a ConfigurationLoader<CommentedConfigurationNode>. In addition to it being another layer of abstraction, it also has a lot of useful settings including being able to pull out anything implementing DataSerializable, anything with a DataTranslator, or anything implementing CatalogType.
Unsure why you’re storing both the Scheduler and a Task.Builder as a member field. You can easily just call Task.builder().execute etc in the creation method. Also, don’t reuse builders! Make a new one when you need a new one. Think of it like an extended constructor.
HOCON naming convention is dashed-lowercase, not TitleCase. Just a formatting thing, won’t affect anything except my sanity.
Rather than code the defaults into your plugin’s source, it’s trivial to make a default config file and embed it in your jar. It can then be retrieved using the Asset API and copied over to a new location easily.
Paths are recommended over Files.
You’re creating a new TextSerializer every time you call sendMessage. There’s a perfectly good, reusable one located at TextSerializers.FORMATTING_CODE (yes, it uses &).
Some people put a brace on the same line as a header. Some people put it on the next line. It decreases readability somewhat if you do both.
notifyPlayer can be rewritten using MessageChannel.permission.
If you have the same action for multiple exceptions, you can do a multicatch e.g. catch (IOException | ObjectMappingException e) {
Rather than casting getX etc to int, call getBlockX etc.
You can replace your initial task with .execute(this::checkDate). You can also replace WriteFile with more of the same.
Task name convention is <plugin id>-<S if sync, A if async>-<name>. So for instance mmclogger-S-DateChecker.
If you change the type of messageList and commands to List<String>, you don’t have to cast to CharSequence or String. Unsure why you didn’t parameterize them normally.
You can also use an iterator for loop instead of an incrementer for loop, since it’s a List.
I usually discourage people using a Util class to send messages; it’s much better to write it out. If you want your complex prefix, you can store that Text as a member variable, and then call append to make a new message.
Thank you so much for taking the time to look over that. It looks like iv got quite a few improvements to make
A lot of the code was shoddily ported over from my bukkit code which wasn’t great but it worked. Gonna see what I can do over the weekend about your suggestions. I have not been learning the Sponge API long so I do not know a lot of the easier ways to do things.
Also I use Maven simply because it is the only one I have experience with, so it is much easier for me to setup. I will probably look into gradle sometime in the near future again.
for my sanity camelCase vs PascalCase, since i see this happen a lot, camel is lowercase first word and then uppercase subsequent first letter of each word, whereas Pascal is uppercase the first letter of every word.
Your point still stands though, conventions are nice when all devs follow the same one for a specific format
I have read over some of it while i was getting information i needed for this plugin. But yes i probably do need to just sit down and read over all of it at some point.
Could you elaborate on the issue here or provide some sort of example? I am assuming it would be related to how the file is written but would like confirmation.
Also is there anything preventing you from updating to one of the latest builds? I am having no noticeable issues on SF-1992
Sorry for that very long response lol. It was working after some sponge updates, kinda forgot to report back. It’s is still working now. Good job on the plugin
