MilkBowl / Vault

Vault of common APIs for Bukkit Plugins
GNU Lesser General Public License v3.0
493 stars 350 forks source link

Feature request: Region information #30

Closed dredhorse closed 12 years ago

dredhorse commented 12 years ago

Hi,

would be cool if vault could also support region information like playerInRegion, and kindOfRegion.

That would help alot in coding plugins which need to do certain stuff different in a region... (well quite selfish I know, but I would help as soon as the framework is there)

Most interesting regions would be:

worldguard regions towny

Sleaker commented 12 years ago

hmm not sure if I want to go adding region stuff into Vault. I'll think about it.

dredhorse commented 12 years ago

I had a similar Idea I talked to xZise (Fabian) with before I found vault. What is missing in cb is an identity storage which gives easy access to all needed information of an identity.

vault does a part of it.

and I agree adding region support is questionable but would ease it for a lot of developers. And vault already does that in the permissions and chat area.

Like I said, I would be willing to code the other bridges if you come up with the initial framework

Sleaker commented 12 years ago

What methods do you need for this to be workable?

currently I can think of:

playerInRegion(player, regionName)

getRegions(player)

canBuild(player) - checks build permission at current location

canUse(player) - checks use permission at current location

dredhorse commented 12 years ago

hmm.. I think we have several areas to cover:

Checking if Player is in an region or a specific region Getting the Name of an Region Getting the Regions of a Player aka Owner Checking some flags Getting the flags as String or similar so that the developer parse it Getting the Region Plugins... as there could be more than one.. which also means we would need to be able to return the RegionKind of the Region.

So perhaps...

.PlayerIsInRegion() boolean .PlayerIsInRegion(RegionKind region) boolean .PlayerIsInRegion(RegionName name) boolean

.getRegionKind(Player player) RegionKind .getRegionName(Player player) RegionName .getRegions(Player player) List

your can Build / Use / Enter(?) mainly what is most common of all the region systems

.getRegionFlags (RegionName name) String / List ??

hmm...

Sleaker commented 12 years ago

I can't return plugin-specific region objects. it basically breaks things. So the only data we can manipulate or deal with is a Vault -specific data object, or String representations. Flags should be able to be handled just like info nodes on a player though.

dredhorse commented 12 years ago

well the region objects would need to be string and than converted back... if possible.. don't know the code of the region plugins..

as long as we only read that shouldn't be the problem, but I agree... we would need to look what the region plugins supply and perhaps afterwards ask the developers to supply us the interfaces we need..

Sleaker commented 12 years ago

@dredhorse - yah it's one of the reasons why I haven't touched specific stuff like this until now. I don't really want to make a 'VaultRegion' object that stores the information just so a plugin can get it. It's almost better to just make a RegionAPI that handles all the region stuff, and make bridge plugins if people want them :-/

dredhorse commented 12 years ago

I think we should put up an interface for sure so that other region plugins can send information about what we need.. there are so many and with the pace vault is being implemented I think it will become useful for them to support it from themself.

This would of course only work for a push from their plugin but I think it is enough for all the minor plugins out there..

and perhaps an easy way to create the bridge and send you the code

TheStriker0995 commented 12 years ago

If you guys do decide to go thru with this could it support all WorldGuard, Residence, Towny, and Regios? As they all have an API to tap into.

Sleaker commented 12 years ago

@TheStriker0995 - my issue currently is that people will want to only interface with one API, whereas the current implementations of Econ/Permissions/Chat only expect the server to have one of these loaded.

Servers most surely will be running more than 1 of the plugins listed.

ghost commented 12 years ago

+1 Nice idea. Would be very useful to have one API for all region plugins. @Sleaker If an unique API is not possible, multiple would be even better than no one. So you would just have to hook into Vault and use it instead of hooking into several plugins. And many methods like inRegion() would be the same for different plugins...

dredhorse commented 12 years ago

so how could that be tackeled?

a HashMap with RegionPlugin, Reference which will than be parsed for information?

would that work with a factory?

Also I don't think we should handle SETTING anything, the class you created looks fine for the start.

But perhaps we should supply an interface which the region developers would need to implement together with a server / listener scheme where vault is the server and the region plugins register for events like get farewell message...

but I guess that would be overkill.

I think this is really ONE big part which is missing in bukkit a customizable event system where plugins can register on and handle the stuff...

ahh... my GRAND IDEA of WORLD DOMINATION.... sigh...

so let's forget the later part and try to get the methods done you created...

developer asks for playerInRegion => we parse the hashmap => we ask the plugins => we return a hashmap with RegionPlugin, RegionName

developer asks for playerCanBuildInRegion (RegionPlugin, RegionName) => we ask the plugin = we return true or false

is that a working idea? how would that codelike look like for ONE plugin like worldguard?

Sleaker commented 12 years ago

I was actually thinking of just storing a list of all active region plugins, then polling each one for the information when someone made a request through Vault.

I think that's pretty close to what you were thinking of. The issue is that there needs to be a Region class in Vault to store this information to pass back to the other plugins, as passing back the region name wont do anyone any good. They'd still have to hook each individual plugin manually and get the region from it if all we did was pass back the region names.

dredhorse commented 12 years ago

well if you add the other methods too it it would make sense... and that's what I meant really..

so instead of hashmap with RegionPlugin, RegionName we return a list(?) of RegionObjects.

the developer than asks the RegionObject if the player is allowed to build..

would that work?

Sleaker commented 12 years ago

possibly, the issue is that you can be in multiple regions at once, from different plugins, so it's easier to poll the API if they can build on that location etc (although this should be done via the bukkit API so it's just an example). This is also why it would be necessary to return a list/set of the regions the player is currently in instead of just one region.

Sleaker commented 12 years ago

I'm going to close the issue for now, it seems like this would be pretty much unreliable or just require a ton of work to get functional in any way. The best thing would be to have some form of region API built into the actual API.

dredhorse commented 12 years ago

yeah that is ok.. if it isn't in bukkit / spout directly it would be a lot of work to keep it up to date with all the plugins as I guess most plugin developers will not really code to the interface

ghost commented 12 years ago

Even though it's closed, I would have to +1 this enhancement. I came here to recommend it but it looks like I was beat by a large time margin. For people building a plugin based in any way on pvp or build rights, hooking all the region management plugins is a real pain. I would be interested in helping implement this sort of region bridge if it's something that you decide is worth pursuing. I have a very basic hook handler class in MoArrows that returns region flags and such for worldguard, towny, factions, etc as well as API to cross reference them against each other. If you want to talk about it some more, pm me (misteraverage) on bukkitdev.

Sleaker commented 12 years ago

there has already been an in-depth discussion on how this isn't feasible (at least for how advanced people would like it to be). unfortunately there isn't a good way to provide the information necessary without causing significant slow-downs in how it's all handled. It might be usable for generic flags, but the initial discussion was about MUCH more than that. in addition, Vault is usually a Many to One hook - Ie many plugins hook one implementation. It's not a Many plugins hook Many converged optionals.

With that being said, if you already have something functional for basic checks that looks at everything I'd be willing to accept pull requests for additions into Vault for it. The only difference for this will be that Vault should be handling the entire process of looking up information, rather than delegating a specific region service to the plugin hooking Vault. (Kind of how I handle the Items class probably with static calls etc)

ghost commented 12 years ago

Right, I completely get what you're saying. I'm not suggesting that Vault should be the end-all be-all for region management. I'm just interested in the possible addition of (as you alluded to) generic area checks common to all region management such as pvp rights, build rights, etc.. flags essentially. For what Vault currently does, I can see how this may leave users expecting more from region management, so I completely understand if that's why this isn't added.

Please don't take me the wrong way. I in no way pretend to know nearly as much about plugin integration as you guys do. I'm no pro coder, and github still puzzles me to some degree. In addition, the class that I use is very basic. Showing you my code would most likely be embarassing in that respect. With that out in the open, feel free to disregard what I say without hard feelings on my behalf. =P

Sleaker commented 12 years ago

@MrAverage - Nope I think it might be beneficial to add what you're saying, if you already have something working that hooks into multiple plugins and provides lookups for simple flags in multiple plugins it'd probably be good to throw up some form of a pull request and then we can work on it from there to refine it or improve on it. I'm all for it (and much prefer working on something that's already been started)