Open IDragonfire opened 11 years ago
It doesn't. At least, atm
Those types of flags, for the most part, don't need to be handled outside of the plugin they belong to. Tho, a way to check them would be nice.
I'll think about how I want to handle this.
I have many ideas to improve your code ... And there are sure more then one solution, to make it better ... Should I comment your code, or try to change it in my repo?
I have a cool idea, but only if you hold an array list of all supported Plugins ... You create a interface ProtectFlag with a method hasFlag(Player p, Location loc) and a template class DefaultFlags ... Each protect plugin has a method, addDefaultFlag, that at a DefaultFlag object to a HashSet ... Protect get some new methos supportFlag (check if hashset contains the flag) and hasFlag(Player p, Location loc) that execute the defsultflag method ... You define enums, like ProtectFlag.PVP, .... If a plugin support a defaultFlag, extend the template and implement the hasFlag method ... Adding the flag happen over the plugin ...
I'm not understanding your idea. Your English isn't so great, lol.
But, there is a HashSet of all the supported plugins in the ProtectionManager class.
Sry, I wrote it late at night on a mobile device xd I made funny mistakes xd e.g. at != add ... If I have time I correct it.
A picture is worth a thousand words
Also possible with my draft:
Advantage: Not so much unimplement stuff in the protect classes and faster, e.g. creating a unsupportet exception takes time ... What is your opionion?
Some Plugins Flags are very common, like PVP, FIRESPREAD, EXPLOSION, MONSTERSPAWN, .... How does Shield manges these Flags?