Suggestion: Preference System

[GoodrichDev]

Please explain your feature request to the best of your abilities:

I think Towny could benefit from a Preference System similar to the one I implemented in EarthPol but with some Towny adaptions to it.

1. A Preference System tied to Resident, Town and Nation.
2. Preferences can be boolean, ints, doubles, etc.
3. Towny can register preferences and use them in checks
4. Third-party addons can register preferences to towny and use them in their own checks.
5. Preferences are persistent.
6. Config options to disable certain Towny Registered preferences (perhaps take a playbook from the plot type configs).

Examples:
There exists /res toggle, one I often find myself using is /res toggle ignoreinvites, perhaps this can be moved to a preference and it can stay persistent

What does this solve?

• Items like Suggestion: /T Leave (Remove Trust/Plot Perm) #7895, which could be resolved with a Town Preference such as /t pref removetrustonleave true
• At a top down level, the server admin can setup how they want Towny to interact with their server but in addition, they can leave certain decisions to Residents, Town Mayors and Nation Leaders on how they want towny to interact with them.

What should be considered?

You might want to reconsider the whole res toggle system, it seems like t and n toggle is fine but res toggle is more of what preferences would take over in my opinion.

[GoodrichDev]

I would really like to hear some thoughts about this, I think it would be a great addition for the community overall, especially in a third-party addon aspect.

Example from EarthPol:

[LlmDl]

I'll look into this deeper tomorrow but I couldn't also not point out that:

Examples:
There exists /res toggle, one I often find myself using is /res toggle ignoreinvites, perhaps this can be moved to a preference and it can stay persistent

You can achieve this for yourself by giving yourself a metanode in LP towny_default_modes: ignoreinvites

[SulkyWhale]

I made an add-on plugin that persists the resident modes you have active when you log out: https://modrinth.com/plugin/townypersistenttoggle

[LlmDl]

It would make sense for preferences to be a Mode.

[SulkyWhale]

This could very possibly be done by an add-on using resident, town and nation metadata along with the TownyCommandAddonAPI. If you wish for another add-on to check these settings, that add-on can just get the modes/settings from the ResidentModeHandler. The only thing that would make it more tricky is that towns and nations do not have an equivalent to the ResidentModeHandler. If you want, I could code something like this for you.

[GoodrichDev]

I made an add-on plugin that persists the resident modes you have active when you log out: https://modrinth.com/plugin/townypersistenttoggle

While I like your work here, I do think that it solves a problem that just shouldn't exist in Towny.

This could very possibly be done by an add-on using resident, town and nation metadata along with the TownyCommandAddonAPI. If you wish for another add-on to check these settings, that add-on can just get the modes/settings from the ResidentModeHandler. The only thing that would make it more tricky is that towns and nations do not have an equivalent to the ResidentModeHandler. If you want, I could code something like this for you.

I already have a working preference management system at the Resident, Town and Nation level, the purpose of me creating this suggestion was to bring something like it into Towny and make it a benefit for everyone to enjoy.

I think the strongest case for this is not "add more settings" but "stop solving preference-like behavior with one-off commands and special cases"

Towny already has a growing collection of toggles/modes/preferences in practice:

• /res toggle ignoreinvites
• /res toggle bedspawn
• /res toggle townclaim
• /res toggle adminbypass
• /res toggle townborder
• and recent additions like ignoreotherchannels

Because of that, this suggestion is really about normalization and maintainability.

A proper preference system would let Towny define typed, persistent values on Resident/Town/Nation objects and resolve them through one consistent API instead of continuing to add ad-hoc fields, toggles, and checks.

That helps in a few ways (IN MY OPINION):

1. Core Towny features get a consistent place to store behavior flags.
2. Server owners get more control without needing hardcoded opinions for every case.
3. Addons can register and read preferences through Towny instead of each plugin inventing its own storage/command layer.
4. Requests like Suggestion: /T Leave (Remove Trust/Plot Perm) #7895 become easier to implement as policy decisions (/t pref removetrustonleave true) instead of bespoke feature branches.

Expanding on point #4, this approach would enable more granular control over specific functionality at the resident level, rather than limiting that control solely to administrators.