implemented a persistent ability-use disabled flag on the PlayerProfile

[BlvckBytes]

Hey there!

Some players on our server prefer to have the ability-use-mode (/mcability) disabled long-term. Currently, they have to run the command after each login, so I implemented a persistent flag on the PlayerProfile, using the already-existing UniqueDataType.

The reason as to why I went with a disable-flag is that it does not break backwards-compatibility. The default-value of the flag is zero, thus ability-use is not disabled, just as it wasn't in the past, after logging in. The only difference is that the setting now sticks long-term.

I hope I explained the use-case well enough. Always happy to further discuss!

[nossr50]

Perhaps I'm missing something, but would this not need to be written to the DB to be persistent? I thought Spigot was throwing away this metadata upon player logout.

[BlvckBytes]

Hey - and so sorry for the late reply!

The PlayerProfile is a datastructure that you introduced, and it is intended to store data persistently, which is the whole reason as to why it tracks a dirty-flag. All I did was to add another UniqueDataType enumeration constant but now that you've mentioned it, I tracked down how you save/load these values and actually, I would have to treat the new constant manually (I assumed you used name/ordinal to map automatically - my bad).

See

mcMMO/src/main/java/com/gmail/nossr50/database/FlatFileDatabaseManager.java

Line 510 in 1ae0816

appendLong(out, profile.getUniqueData(UniqueDataType.CHIMAERA_WING_DATS));

In any case, I'd be happy to extend the missing save/load handlers - I've heard from many players and different servers by now that they'd be happy if toggling was persistent.

[BlvckBytes]

I've just had another look and noticed how UniqueDataType is really intended for cooldowns (got mislead by the name), so a separate boolean related to huds settings would probably be a better fit. Honestly, why not simply use the player's PDC? That's exactly what it's for, and it would save a lot of headache, seeing at how low of a level DB and file persistence are implemented.

I'm going to create a new PR, as I don't deem this route viable.