[Feature Request] Opt-In behavior

[dector]

Currently Vane is using opt-out behavior: as a server admin I need to install plugins, make 'em to generate configs and disable all features except few I actually need.

I would be nice either:

• to be able to install plugins and OPT-IN into features that I need (preferable);
• be able to generate / download default config which has all features disabled.

I can help with implementation.

What do you think?

[oddlama]

Thanks for the suggestion! Are you generally talking about all features?

I personally just want to maximize user experience for the general public. The plugin should be easy to install and use.

I do agree with your concerns, but most minecraft server admins are (unfortunately) not very technically experienced. I for example have initially added a (default enabled) option to vane-permissions that deletes all default permissions of players. So I as an admin can set exactly who may do what, without hidden implicits. But I noticed later that this is too complex for the average user, so I made this option opt-in.

Point is: Most admins need a way to get what they need with the least amount of effort. For me that means to enable every feature that the average user might need by default, and have the rest opt-in. I let them choose the main feature set by having them install just the .jar modules they want. Some people like the new enchatments, some don't, so it is a whole module and they don't have to open any config to change that.

So now the admins only need to adjust the config occasionally, if they need to tweak a detail setting. If everything were opt-in, we would require those 95% of inexperienced admins to adjust ~100 config options just to be able to use the plugin as it is now. This wouldn't be ideal.

But I do agree that opt-in is beneficial for more experienced users that only want certain features. Beware though, not everything can be disabled. Some functionality at the core of vane might always be required. (e.g. ProtocolLib dependency).

I'd definitely be open to have a secondary mode that does what you want, if we can find a way to not break the experience for everyone else.

Some thoughts:

• A command /vane allnoconfig (plus a new setting that makes future config updates be opt-in too)
• Some kind of setup wizard (merge all modules into single vane.jar, something i'd like to do anyway), then on first start require the admin to select the modus operandi (default all-on, allow to select modules in wizard, plus option for all-no)
• What would you do with options that are not a yes/no choice per se? E.g. there is a option to disable the resource pack and use server side translations instead, but this is not a yes/no thing because it has a significant tradeoff (custom items cannot work without RP)

As you can see I'm not sure how to approach this correctly. Whatever the solution will be, I want to keep the usability high for the average user. If there is a way to get rid of the 10 jar files in the process, I'm all for it.

I'd be happy to hear your thoughts about this and would be greatful if you were helping to implement it, once we settle on an acceptable solution. Thanks again for brining this issue up :)

[dector]

Hey, thanks for such detailed reply! My idea was not to introduce behavior changes (totally agree with "copy plugin and launch server" approach in this case) but rather something like:

• Add opt_in_mode: false # default false setting into each config.
• If admin sets this setting to true - she/he should manually enable every feature.

The downside is that it makes source code a bit more complicated but I think that if I'll hide configuration behind some interface - impact will not be visible.

Setup wizard / cli tool is an awesome option but at the same time it requires much more effort.

I wanted to play around sources anyway so I'll create prototype and will ask you to validate the direction.

[oddlama]

The downside is that it makes source code a bit more complicated but I think that if I'll hide configuration behind some interface - impact will not be visible.

I'd rather have a proper solution, otherwise this will add unnecessary complexity to the code and at worst require constant maintaining later. I'd like to avoid that.

The spirit of the solution is good though. I think a clean approach would be to add another field to the @ConfigBoolean annotation, maybe called Boolean opt_in_default (Boolean to allow tristate). This could allow setting a second default for all boolean options specifically for the opt-in mode. By default it would be null and then mimic the normal default value. This way all the enable fileds throughout the code can very easily be set to false just for opt in mode.

This has the benefit of not requiring any additional complex logic. You can then also add the opt_in_mode option you described to the config. To make it more usable just have a command /vane enable_opt_in_mode, which just overrides the config values with the associated opt-in values.

This should require the minimal amount of code changes to implement the behavior. And I'd say its a clean solution.

Setup wizard / cli tool is an awesome option but at the same time it requires much more effort.

True. Maybe I will merge the jars one day, then something like that will be necessary. Maybe just enable everything by default and allow a simple command to configure the most basic settings on the fly, like /vane config disable enchantments.

I wanted to play around sources anyway so I'll create prototype and will ask you to validate the direction.

Sure thing. Although I'm already positive that my proposal above will be one of the easiest clean solutions. But I'm interested in what you will come up with! :D

[oddlama]

I don't foresee implementing any big changes like this in vane, so I believe this isn't relevant anymore.

I wanted to play around sources anyway so I'll create prototype and will ask you to validate the direction.

I'm not sure if you actually had time to play around with it, if you want to bring something forward in the future, feel free to reopen or make a PR