Flags
Flags is an interface plugin designed to bridge the gap between cuboid and other land management plugins and other plugins that would need to access them.
Based on similar concepts of Vault, Flags provides a single unified object or "Area" for developers to have basic access to the information it holds without the need to know which plugin created it. This allows developers to implement per-area features one time and have them work automatically with all the supported land management plugins.
Though it has grown far beyond it's original purpose, Flags gets it's name from it's ability to allow plugins to create "flags" or switches that change the behavior of the game or plugin in specific areas. Flags will automatically maintain the users choices and customizations, and the plugins that created the flags merely have to handle their behavior. Don't let the name fool you, plugins can use the API for hooking into areas without actually creating flags at all.
Features
- Multiple land area plugin support
- Modular flags allow you to choose only what you want.
- Developer API allows anyone to create flag plugins or interface with areas.
- Flags can be set for areas, the wilderness, or new area defaults.
- Trust lists allow you to choose players that can bypass flag effects in each area.
- Customizable player messages allow you to personalize all player flags per area.
- Customizable flag bundles allow you to set multiple flags in a single command.
- Multi-world support allows you to treat each world as a different area, including the wilderness and defaults.
- YAML and MySQL data storage options for flexible servers
- Vault economy support for purchasing flags and messages
Supported Area Plugins (optional)
Flags currently supports Factions, Factoid, Grief Prevention, InfinitePlots, PlotMe, PreciousStones, Residence, and WorldGuard. Flags also has an internal system it uses if no other system is detected. For more details on compatibility and feature sets, please visit the Area Plugins page.
Plug-ins and Modules
Included Modules
Included with Flags is a set of optional flag modules available that operate with just Bukkit. To install them, place the modules you want to use in your plugins folder, along with Flags.jar.
Module | Description |
Block Module | Adds flags based on block control. |
Border Patrol Module | Adds flags based on players moving into or out of an area. |
Core Module | Adds general flags that don't fit with any of the other included modules. |
Creature Spawn Module | Adds flags for stopping creatures from spawning. |
Damage Module | Adds flags for stopping types of player damage. |
Player Module | Adds flags based on player actions. |
Vehicle Module | Adds flags based on boats, minecarts, and horses. |
External Plugins and Modules
Below is a list of known plugins and modules not included with Flags that add their own flags. If you have developed a plugin with Flags support or a module and want it listed here, add a post to the developer forum!
Plugin | Description | Flags |
BlockNotif | Notifies moderators when players break certain blocks, logs it, and prevents it from occurring. | None. Flags is used to report the name or ID of the area defined by the system your using. |
FancyShop | Creates chest shops that trade in physical currencies. | Flags that allow shops to be restricted to specific areas. |
FlyNCreative | Allows server operators to set areas where creative mode and flight are enabled while maintaining inventories for those areas. | Flags to select Flight and/or Creative mode. |
HardcoreClaims | Grief Prevention extension that deletes claims and restores the land when a player dies. | Flags for choosing which claims get deleted and what areas players must die in to cause a deletion. |
PetStore | Manage ownership of tameable animals. | Flags for choosing where animals can be left for sale, give away, or released. |
RocketTeleport | Plugin that adds a new flare to warping/teleporting. | Flags for choosing where players can create rockets and landing zones. |
Flag Usage
NEW: Tutorial: Understanding Area, Wilderness, and Default
To set flags for an area, simply stand inside the area that you would like to set a flag for and issue the command /flag <action> <location> <flag> [value]. For more detailed information, consult the Commands page. Setting a default flag allows you to choose the behavior for all areas in the world that have not had a value previously set. Setting a wilderness flag allows you to choose the behavior for unclaimed areas.
The following examples can be used for the flag or bundle command and can be used with area, default, or wilderness. This is not an exhaustive list.
Command | Effect |
/flag get area Pvp | Retrieves the value of the flag |
/flag set wilderness NotifyExit true | Explicitly set the value of the flag. |
/flag set default SpawnMob | Toggle the current value of the flag. |
/flag help | Display a list of available flags |
Tools
Flags has the ability to use item based tools for some functionality. The items are configurable in config.yml. Below is a list of the tools available.
Tool | Default | Function |
FlagQuery | Feather | Right click in an area to view the flags currently set. Performs the same function as /flag get area or /flag get wilderness. |
Sector | Gold Hoe | If Sectors are enabled, use this tool to create a sector by right clicking to set the corners. Create subdivisions in the same manner inside an existing sector. |
Bundles
Bundles allow you to group flags together so you can set them with a single command. New bundles can be added by command or by the server operator editing the bundle.yml file. Bundles maintain their own permissions system, they do not require a flag permission even if the flag is in the bundle. Below is a list of default bundles which serve as examples and can be edited or removed. These bundles will only function if their respective modules are installed.
IMPORTANT: When adding new bundles by editing the file directly, the name should ALWAYS be lower case. Flag names are not case sensitive, and using or adding bundles with commands in-game are not case sensitive. You may use in-line YAML list format if you wish.
Bundle | Flags |
BuildCreature | BuildGolem, BuildSnowman, BuildWither |
Jail | AllowEntry, AllowLeave, AllowTpIn, AllowTpOut |
Notify | NotifyExit, NotifyEnter |
SpawnMonster | SpawnInvasion, SpawnJockey, SpawnLightning, SpawnMob, Spawner, SpawnChunk, SpawnOther |
Damage | DamageBlockExplode, DamageContact, DamageDrown, DamageFall, DamageBlockFall, DamageFire, DamageBurn, DamageLava, DamageLightning, DamageMagic, DamageMelting, DamagePoison, DamageStarve, DamageSuffocate, DamageSuicide, DamageThorns, DamageVoid, DamageWither, DamageOther |
Updater
Flags contains an automated updater feature that can check for updates and notify the console and players with permission when one is available. For more information on configuring or disabling the updater, click see the Configuration page.
Metrics
Flags reports non-identifying information about your server to MCStats.org. For more information on what is reported and how to disabled it if you would like to, please see the Questions page. To view the full set of data, click the graph below.
Discussion Forum
In order to provide more centralized and effective means of feedback and support for my growing list of plugins, a Discussion Forum has been provided. You don't even need a new account to use it! Please understand that I may not directly respond to comments on this page and I will not respond to plugin questions in the form of PM's. By posting on the forums you help others find answers to the same questions, and I don't have time to continually repeat the same answers if you want new features added! This forum is exclusively for plugins by Alshain01 and discussion of their use and development. For other concerns, please consult the Bukkit Forums.
@mblanchet75
Glad to hear it's working, I haven't done any testing on that feature at all as of yet. What did you mean "checks your messages"?
@Alshain01
I confirm. hasTrust(Flag, Player) is working, and also permission node ;-) But checks yours messages when we try to add and remove a permission node (I know, it is just a dev version!)
Just a warning to everyone, in anticipation of a v1.3 release I will be updating the pages here on BukkitDev. You may find things here that you do not have in the current v1.2.3 release.
Ok, well it wasn't as involved as I thought it would be, the architecture actually allowed it quite easily, so I went ahead and added permission trust. The only way I could think of to differentiate between a node and a player is the period "." character, so any permission node used this way must have a period in it somewhere. (i.e. flags.mypermission)
@mblanchet75 This will all be in the Area class, for convenience I've provided the new hasTrust() method, which check both the implicit player list and the permission nodes for you. I think that is mostly what you will use. The getTrustList() will no longer return the owner names implicitly, but hasTrust() will check them automatically. Note also that it does NOT check the bypass permissions (Flag.getBypassPermission()). The code for the Player module has been updated on GitHub if you need an example.
@GodsDead
Don't quote me on the GP/Permission trust. I thought it did support that, but now I can't find information on it. It might be there, it might not but you can always try it. It would be a nice feature to request if it isn't there but I wouldn't count on it in 7.8 as BC is trying hard to get a final release on that.
Reload command is done. It reloads nearly everything, but will not change the data storage type, or the active land system in config.yml. That requires a plugin reload.
PlaceBoat... as far as I know, the flag should be intuitive. If it's true you can place a boat, if it's false you can't. I took a quick look at the code, I may be getting the wrong item to test against (the item your clicking, not the item in your hand). But I seem to remember testing that and it worked just fine so I'm not sure. I'll run some more tests tonight. Off hand I do see a potential issue where the event might get cancelled if your holding a boat and left click. That shouldn't happen.
EDIT: Nope, checked the Javadocs. The method I'm using is indeed getting the item in your hand to compare against a type of boat (or minecart). It should be working.
@Alshain01
The reload command would be very helpful, Most server owners spend time just in Config files and the command line reloading, restating the server to take effect is a pain! Lucky im still whitelisting for "development"
I didnt even consider SQL support, this is a good idea, Im planning on moving all my plugins to sql after my host fixes my node mysql trouble (Sigh).
Griefprevention has the ability to allow trusts based on permission? This is something I will have to try out, it would be fantastic to auto-rank users to be able to build in specific areas.
I haven't yet used the bundle system, Mostly dealing with spawn only at present, which brings me onto my next question:
PlaceBoat Setting this as True still gives a permission error to users, Do I need to do anything else apart from set the flag in the area claim?
+1 for «1. /flag trust area [Flag] [PermissionNode]» if you can do it soon, then I can move my 2 plugins to Flags ;-)
@GodsDead For the reload command, I think that's something I overlooked when I redid the command structure from GPFlags. Funny thing is there is a reload interface class already built into the data store. Because this is already there, just not accessible, I may break my "freeze" rule an squeeze the command into 1.3.
Regarding trusts, I can share some of my "to-do" list with you. There are a couple of features I want to add, they won't be in 1.3 as it is already feature frozen leading up the much anticipated SQL support release. So, what is on the coming soon page is pretty much final. However the plans I have for making trust easier involve 2 features.
1. /flag trust area [Flag] [PermissionNode] - Instead of trusting each player on each flag, I'd like to add the ability to use your fav perm plugin to trust groups of players all at once. If I'm not mistaken I believe Grief Prevention already has this feature so you can use the same perm nodes in GP and Flags.
2. /bundle trust - This is pretty obvious. Rather than setting trust for every flag, I want to give you the ability to set an entire group of flag's trust lists in a single command. Of course bundles are already customizable. The main reason this hasn't been done already is because not all flags have trust lists (It doesn't make sense to trust people for say SnowMelt, what would that do?) Historically you could set trust for those flags they just wouldn't do anything, but in 1.2.3 I added methods of checking to see if a flag was a player flag (now you get an error message). So for bundles now I have to check each flag in the bundle when you do /bundle trust to see if it can accept trust. Long story short, it's an involved but definitely possible feature and it just falls into when I have the time to get it done.
I think these two features will make the trust system much easier to use. I'm not making promises but if I had to guess they will probably be in 1.4.
@Alshain01 Trusts: This makes a lot of sense having your own trust system; So how about a feature request for more control over specific plugin, The plugin checks for Claim control plugin, detects griefprevention, Creates config variable to turn on Using griefprevention trust system, they have an API and everything, its by far the best claim control and grief prevention plugin there is.
PVP Message: I ended up just having messages set in the Spawn area when you Enter and leave, and its obvious PVP is off in that area anyway, I was just curious how the messages system worked with other flags.
Messages Problem: I couldn't find a way to reload the data.yml in-game, I find it much easier to set the messages then edit them inside the config then re-upload since the in-game chat input is limited and if you're using formatting you are really restricted, I also learnt the hard way about punctuation formatiing inside the data.yml, Pirate talk uses a lot of " ' " characters which break the variable & plugin if uploaded! A reload option would really help setting messages, and formatting guidelines on the docs would be helpful.
AllowTpin: Ok, This makes sence, Thats right for admin claims to not be considered when checking the flag, So admin claims can be differentiated between normal claims, Not everyone does use the plugin the same way, hence why there are configurations! This could be a simple True/False option in the config to let it ignore admin claims for Tpin, or maybe a better method would be to implement that first trusts problem I highlighted, once you can understand the trust system inside griefprevention you could then pass parameters inside the flags system to bypass this problem :) Killing two birds with one stone!
@GodsDead
Ok. I went back and re-read your original post and I think I understand what your saying now. However, what you describe is exactly what it is supposed to do. Using the Default option, you can choose to start with the flag as false for all claims and then set it to true in just the claims you want to allow teleporting into OR you can choose to set the default as true for all claims and then set it to false for just the claims you do NOT want to allow teleporting into (this is the initial behavior).
In your case, there are more claims you do not want them teleporting into, so it's easier to set the default to false and set the claims you do want to allow it to true. In either case you have to tell Flags one or the other.
If I understand what your asking for, it's for admin claims to not be considered when checking this flag, but the problem I have with that is you may want it that way, but some of my users may like being able to turn of teleporting in admin claims. I'm reluctant to make a change that would essentially remove that capability.
Not everyone uses the plugin in the same way, and I try to serve as many as I can. What you want to accomplish is possible, you just have to configure the admin claims to allow teleporting. But if I remove admin claims from the flag, what others might want would no longer be possible at all. I hope this all makes sense, I believe the way it is now best serves everyone.
@GodsDead
"I think you have miss-read or miss-understood my post, The ability to stop people /sethome in other peoples claims by default, Ignoring admin claims, so we can have public areas people can warp to, Why the hell would I want to stop peolpe using /spawn? I had to disable tpin to let people use spawn again!"I'll go back and look at the code as soon as I get the chance, we already found PotionSplash is backward so this is definitely possible (in Java, this is a matter of omitting an "!", real easy to mess up).""Use /flag trust" Why not just implement the trusts that have already been set by greifprevention trusts, instead of confusing players and making them use two seperate commands??? This is a no brainer."
Several reasons why actually. For one WorldGuard, Residence, Factions, PlotMe, InfinitePlots, Regios, and PreciousStones do not have Grief Prevention trusts. I understand from your perspective there is nothing but GP, but I have take a much wider view.
Another issue is that each flag maintains it's own trust list, where as GP has like 4 total. So lets say I use GP's Access Trust for example and you want to allow certain people to bypass the AllowEntry flag but not bypass the Portal flag, you would be out of luck.
If I implement my own trust system I have control over it and its universal regardless of which system your using, which is why Flags was made in the first place.
"And a problem I found today, I cannot set a message for PVP to tell the player that PVP is disabled where that flag is set to false (spawn)."
Well, it's not a player flag. Historically the reason it's not treated as a player flag is because it's handled by an entity event, not a player event. Theoretically it could still be done I suppose, but it would be very "spammy". If you can imagine pvp where you have a sword and you click and hold on a player, every time you swing your sword you would get a message saying "you can't do that", which is kind of obvious if your not damaging the player anyway. Alternatively, you can use the NotifyEnter flag to let the player know pvp is disabled when they enter the claim.
@Alshain01
@Alshain01
"Why would you set the flag if you want them to be able to teleport in using /spawn? If you want players to teleport to the claim, don't turn on the flag."
I think you have miss-read or miss-understood my post, The ability to stop people /sethome in other peoples claims by default, Ignoring admin claims, so we can have public areas people can warp to, Why the hell would I want to stop peolpe using /spawn? I had to disable tpin to let people use spawn again!
@Alshain01 "Use /flag trust" Why not just implement the trusts that have already been set by greifprevention trusts, instead of confusing players and making them use two seperate commands??? This is a no brainer.
And a problem I found today, I cannot set a message for PVP to tell the player that PVP is disabled where that flag is set to false (spawn).
Ya, that was it. Probably should have said "added" instead of "fixed". Sorry about that.
@john01dav
John, I saw a feature request ticket from you. I don't have any issues that need to be fixed on record from you.
Hello, I posted a ticket a week ago and still no response, May I please know if it will be fixed (this is driving me insane).
Thanks matey, that worked.
@Shadow00Caster
By default, inheritance is set to true. Do /flag inherit false while standing in the subdivision.
Using GP 7.8 latest build, latest build of Flags, and MC 1.7.4 server with latest Spigot. Have an issue where setting flags inside subdivisions do not work. I tested in a normal claim and an administrator claim by creating a subdivision inside the claim and setting a flag then getting the flag to make sure it set, then walked outside the subdivision while still in the claim and checked the flag, it was set for the whole claim and not just the subdivision, same behavior as GPFlags and GP 7.7 (subdivision support is listed as GP 7.8 or higher).
I used /flag s a pvp true and /flag g a pvp while inside the subdivision and outside the subdivision (still in parent claim).
@GodsDead "This stops people from teleporting into admin claims, so you cannot use /spawn"
Why would you set the flag if you want them to be able to teleport in using /spawn? If you want players to teleport to the claim, don't turn on the flag.
"It ignores trusted users for that claim"
Use /flag trust
"The deny message is only sent to the recepiant of a teleport too, If I tried to /tpahere a user into my claim it would only notify them that they are not allowed into that claim."
It's a PlayerTeleportEvent, sadly there is no PlayerTeleportingPlayerEvent. It doesn't tell me who initiated the teleport just who is teleporting and very vague cause (i.e. Command, Perl, Portal, Plugin, etc.). This flag only blocks Command, Ender Perl, and "Unknown" causes.
I use 7.8 GriefPrevention and am having trouble with AllowTpIn, Im setting this to false for default claims. /flag set default AllowTpIn false This is to stop people using /sethome in another persons claim warping into it (glitch through walls or sneak in later after looking around) Which works, But It needs amendments, This stops people from teleporting into admin claims, so you cannot use /spawn. It ignores trusted users for that claim, Only the owner can teleport into their claim, trusted and containertrust users should be allowed to teleport in. The deny message is only sent to the recepiant of a teleport too, If I tried to /tpahere a user into my claim it would only notify them that they are not allowed into that claim.