Seriously we need to be able to control player pvp, more than silly toggles.
Global options for this would be cool as well
/ocm enable - turns on 1.8 pvp server/world wide
/ocm enable - turns off 1.8 pvp server/world wide

I think for the original use-case, this only actually needs to be a temporarily-applied override, with no need to write it back to file.

You just want to change whether people have combat cooldown or not? You can already do that on a global and world-wide level through the config.

i believe the idea is that you want to be able to do this live in-game without having to touch configs, right? and also to be able to control the PVP of other players via the command?

Well I technically already found a way to do this by simply disabling and enabling the plugin, but a cleaner implementation would be nice.
It mostly about being able to do it in game, live. I have no problem with configs.

The issue with doing it in-game (for the global toggle) is that we can't write it back to the config without completely mucking up the formatting and annihilating all the comments, due to Bukkit's YAML implementation. So it could only ever be temporary until the next reload.

Then it doesn't need to be done. I'll stick with my current way of doing it. If you guys find a way to get it done, I'll be keeping an eye out.

or the alternative is we put this in a separate file from the config.yml, one that we don't care about losing formatting in.

this would also be a good start point to begin allowing more per-player settings. i vaguely remember some other issues that required us to build a per player persistent data store, so we could use it for those too.

no need to rush ahead and close this, i think there's a very plausible chance that this can be implemented

Alright, we'll keep it open. I'm sure no one would mind more customizability. Would separate storage of data allow for others features to be added? Sounds like a lot of work for just one request.

At that point I'd use some sort of database to store that information. @rayzr522 there was indeed issue #179 about letting players choose whether to be in 1.8 or 1.9 combat mode. However this would include more than just attack speed. If we wanted the plugin to remember what they chose between logins we would have to store the data somewhere.

an easy initial implementation could use a JSON/YAML flatfile, but if we use a database things get tricky. for performance we would need to cache in memory, but then if we use a database we have to worry about desyncs between multiple servers on a bungee network. i think people assume they can use the same database for all their servers. so then the in memory caches would become an issue.

possible solutions:

1. redis (really only helps if all servers are on the same box, otherwise it's probably not much faster than just dumping the whole cache idea to begin with)
2. a bungee cord companion plugin to propogate changes to the cache or at least invalidate the cache thus triggering a re-query across all servers that have OCM
3. not caring and just having the cache expire at a configurable interval, thus meaning the cache would never be out of date for more than X seconds when switching between servers

#2 is probably the most reliable and smooth experience, and should work in all situations, but will likely result in issues if people (a) don't realize they need to install the plugin on bungee or (b) don't keep their OCM versions in sync across all versions

I'm actually not sure if a bungee plugin is necessary, maybe you can broadcast from one node in the network to all the others via the bungee API (but from the server, not the proxy)

but the versions being out of sync issue would probably require (a) versioning our playerdata schema and then (b) having a proxy plugin that keeps track of the OCM version on all nodes and freaks out if the schema versions are inconsistent

@rayzr522 Why would the data need to be synced across servers? Surely they can just choose their combat mode for each server individually?

Actually I wonder @rayzr522 whether we need a database at all or whether a simple flatfile would do. If we just use a different set of files to load/store on plugin enable and disable there shouldn't be too much of an overhead. We could then store information on each player UUID such as what combat mode they are in for each world etc.

The only problems I see is the file getting too big, which can be solved by having separate files for different worlds, and the data being lost if the server crashes, which can be obviated by having the plugin save at regular intervals.