Best Practices in separating plugin algorithms from config access? [Much answered]

First, quick tip - You don’t need to specify value in @Setting if the variable name is the same. You only need that for the odd conflict either between HOCON names and Java reserved words (e.g. @Setting("final") ItemType finalStage) or where HOCON naming conventions and Java naming conventions differ (e.g. @Setting("timer-duration") int timerDuration). So stuff like spacing and frequency don’t need the extra value field.

Second, can you do the full class instead of the basic construct? There’s a couple things missing, and I’m pretty sure they matter.

1 Like

In the code you pasted, you never instantiated BatholithDefaults, just declared it. Make sure you use config = new BatholithDefaults() somewhere in your code prior to setting it, because all you are doing is setting the config to null as far as I can see.

EDIT: I should clarify something: when you load the config from the node, your code would look like this:
config = node.getValue(TypeToken.of(BatholithDefaults.class));, whereas when you are setting the default config, you would use node.setValue(TypeToken.of(BatholithDefaults.class), config);. In the setValue call, the config variable should not be null. A safe way to force non-null handling could be like this: node.setValue(TypeToken.of(BatholithDefaults.class), config == null ? (config = new BatholithDefaults()) : config);. That will lazily instantiate config if you are saving defaults, but if you have already loaded a config from file, it will save what is loaded as well.

Hopefully this helps to fix your errors.

1 Like

Also, you’re making a new TypeToken when you don’t need to be. getValue(BatholithDefaults.type)

1 Like

YEP. that did it. Awesome. This is so much better than accessing a specific config node with a hard coded string. @Wundero thanks for the clarification.

Now if i can only get my plugins to have different ID’s…