Bukkit

General Questions

Will Flags operate the same way with WorldGuard and Residence as it does with Grief Prevention?

That is the idea, but there are nuances to each system which have to be accounted for. WorldGuard's ability to overlap regions, Grief Prevention's ability to siege or subdivide claims. The plugin's polymorphic design allows developers to add support to their flags without knowing which land system is in use.

Does the plugin use WorldGuard or Residence's built in flag systems?

No, the various land allocation systems are just too different. Trying to support all of them while using their built in flag systems would be too difficult to manage. Flags interfaces with these plugins only as far as to tell if there is a allocated area present at any given location in the world, and retrieve its identification. You will use Flags' commands, not WorldGuard's or Residence's.

Will you add any other land allocation systems?

I am adding new land management systems as I am aware of them. In general, it simply needs to accept a location and tell me if there is an area at that location and give a unique identifier for it. If you have one you want to be supported, request it!

Are there any other requirements for land systems?

Yes. I require it be available on BukkitDev. The BukkitDev system is there to help remove potentially dangerous plugins that could be running code that is effectively a computer virus. Though the system may not be perfect, it is the best we have and I will not trust my development system to plugins that have not been approved by the BukkitDev staff. I encourage server operators to not trust their servers to those plugins either.

Can I use more than one land allocation system?

This isn't planned for the moment. The issue of what happens when a claim overlaps a region that overlaps a residence would have to be resolved. For right now, there will be a configuration option to set the search order for the supported systems, the first one found while using that search order is the one that gets used. The configuration option will be irrelevant if only one system is installed.

Do I have to use a land allocation system?

No you do not. As of v1.4.0, Flags will have a rudimentary system for creating cuboids which can be used for Flag placement. This however will remain simple and will provide no visualization, anti-grief, ownership, or other extensive features. This system will automatically be used when no other can be found, however even when it is enabled, you do not have to use it.

Can you add a flag that would stop a behavior of my Anti-Grief plugin?

As a rule I will not do this. Anti-grief functions are there for a reason and if you want to disable them, you should talk to the developer of that plugin for the ability to allow them to be disabled (if it does not already exist). Under no circumstances will I "un-cancel" and event that has been canceled by another plugin because others might be surprised by it and even consider it malicious, which would only give Flags a bad name. Alternatively you can ask another developer to do this using the Flags API, I don't police the plugins that use Flags, but it will not be included in my package.

MCStats

What is MCStats and what is it used for?

MCStats is a system that creates a compilation of metrics data that the server reports back to a central repository. This data is non-identifying (it doesn't tell me any personal information about YOU) and is generally small in nature as not to cause lag. It is used as a means of targeted development. For example, if I look at the metrics and see that 75% of the servers being logged are using an economy system, then that might mean I should target my development efforts at expanding the economy integration.

What information is sent to MCStats.org?

The MCStats reporting is limited to the following non-identifying information:

Custom Data

• The land system plugin in use by Flags.
• The server's economy status as used by Flags (enabled or disabled)
• A list of flag groups registered on the server (i.e. which plugins are adding flags to the system).
• The auto update configuration of the server (No Updates, Check for Updates, Download Updates)
• The BorderPatrol listener state (Enabled, Disabled)
• The data storage type (YAML, MSSQL, MySQL, etc.)

MCStats Standard Data

• A unique random identification number to ensure the same metrics aren't recorded more than once. This does not identify the server.
• The version of Flags in use by the server.
• The server's status as being online
• The number of players on the server (also sent for custom data with land system type).
• The Java version on the server.
• The operating system and OS version of the server.
• The authentication mode the server is configured for (Online, Offline)
• The revision of MCStats being used by the plugin.
• The CPU architecture of the server (x86, x64)
• The total CPU cores of the server.
• The country the server is in.
• The game version running on the server.
• The type of Bukkit implementation running (CraftBukkit, Spigot, MCPC+, etc.)

Is it sending any other information?

The above list represents the data being sent by the current revision. Depending on the version of Flags your using, there may be some old graph data being submitted that isn't used anymore, however the MCStats system will not record it unless the graph is activated. Furthermore, the MCStats system does not allow developers to see data that general users can not. Therefore, any recorded data can be see by you as easily as it can be seen by everyone else.

How do I disable MCStats?

Open your plugin folder and navigate to the Flags plugin folder. Open config.yml and change the Metrics Enabled value to false. Note that flags does NOT use the metrics global configuration opt-out value.

Flags vs. GriefPreventionFlags

You're the current author of GriefPreventionFlags, is Flags the same as GriefPreventionFlags?

No. While flags holds the same ideals as GriefPreventionFlags, you are only seeing the outside shell of Flags. If you were to examine the code behind Flags and GriefPreventionFlags you would find that very little is the same between them.

Why not just update GriefPreventionFlags with the new code?

Mostly because of the name, the primary purpose of the total re-write was to allow systems including but not limited to Grief Prevention. It didn't make sense for WorldGuard or Residence users to use a plugin called GriefPreventionFlags. Also because the plugins are drastically different.

What makes Flags so different?

GriefPreventionFlags architecture centers around the flag you set on any given area using a linear object oriented approach. Flags, on the other hand, uses a polymorphic architecture and focuses around the area you would be setting any given flag on. It also allows developers to register their own flags without requiring knowledge of the various land management systems.

Does this mean you will stop maintaining GriefPreventionFlags?

No. I intend to keep it running for as long as I am developing Bukkit plugins and as long as I feel there are enough users to warrant it. However, GriefPreventionFlags is "mature" with v1.6 meaning you won't see many new features since there isn't really much more I can think of to add. I will mostly be correcting bugs and keeping it up to date for new Bukkit versions. UPDATE: Due to recent UUID changes that would require a large overhaul of GriefPreventionFlags I will in fact be discontinuing work on the project. It is simply no longer feasible to maintain a project with duplicate features to this one when doing so would require so much work.

If I am using Grief Prevention, why should I switch to Flags? Wouldn't Flags be less efficient?

On the contrary, the polymorphic architecture means that only code that is required by your system gets loaded. In my internal testing with GriefPreventionFlags I found that the two plugins take about the same amount of time in event processing. (With current releases, Flags only monitors one event and it is up to the modules to do the rest). In addition, Flags already has features that GriefPreventionFlags could not support.

What kind of new features does it have?

So far, it allows more consistency in commands. Anything you can do for your claim, you can do for the wilderness or the defaults. This includes messages, trust lists, bundles (formerly clusters), and of course the flags themselves. Speaking of bundles, you can now edit them in game. It also allows a more precise control over that dreaded PlayerMoveEvent that takes so much time, you can customize it's operation in config.yml. Finally, the true power behind Flags is the ability for 3rd party developers to register their own flags in the plugin so you can use the same commands with any flag in any plugin in any area defined by any land allocation system

Can I have both Flags and GriefPreventionFlags installed?

Theoretically yes, but I don't recommend it. Having both means two plugins listening to all the same events and using all your server resources. They work similarly enough that you shouldn't need both, pick one or the other.

Can I go back to GriefPreventionFlags?

Of course, but data will not travel backward. I recommend backing up your server data before installing Flags if you think you might go back. That's always a good idea anyway.

Will Flags import the GriefPreventionFlags database?

Yes, To import an existing GriefPreventionFlags database, follow the steps below.

1. Ensure Grief Prevention 7.8+ is installed in the plugins folder. (Flags works with 7.7, but due to GPFlags, 7.8 is required for an import. It is possible to go backward after the import if you maintain your original Grief Prevention data folder).
2. Install GriefPreventionFlags 1.6.0 and start the server to upgrade the database (if not already done). Flags can only update from the GriefPreventionFlags 1.6.0 format.
3. Remove gpflags.jar from the plugins folder. DO NOT delete the GriefPreventionFlags data folder.
4. Copy the GriefPreventionFlags data folder to a secure location as a backup (just in case).
5. Place the Flags v1.4.x JAR file in the plugins folder. (Newer versions do not support importing)
6. Start the server, the GriefPreventionFlags database world.yml and data.yml will be migrated to the Flags format. Any remaining files in the GriefPreventionFlags data folder will be removed to ensure Flags does not attempt to re-import the same data.
7. Install the latest version of Flags

Is the interface exactly like GriefPreventionFlags?

No, there are some differences in the command structure. Some of the terminology needed to be changed (i.e. "claim") to facilitate the new systems. The commands have been simplified so your help screen isn't quite as polluted and they operate more consistently. In this I've tried to find the right balance between simplicity and power user. Most of the commands are similar but reordered, for example instead of "/setflagglobal spawnmob true" you now have "/flag set default spawnmob true" for power users this equates to "/flag s d spawnmob t".