Version 6 is a MAJOR UPGRADE to WorldGuard so we recommend:
(Periodical backups are recommended anyway.)
You can upgrade from any version of WorldGuard 5.
It is NOT POSSIBLE TO DOWNGRADE after upgrading to WorldGuard 6 without loss of data due to the conversion to UUIDs. Do NOT downgrade WorldGuard once you have installed version 6.
If downgrading becomes necessary, please file a ticket on our issue tracker.
If this is a BETA BUILD or SNAPSHOT BUILD, then you should re-read this document every new release until after you have upgraded to a final release. Breaking changes may be added until the final release.
You have downloaded version 6.0.0-beta-01.
You can report bugs that you encounter on our issue tracker and ask questions on our forum.
Be aware of these breaking changes:
DENY
on SLEEP
will override a BUILD
set to ALLOW
. (The sleep flag only applies to beds.) Possibly the real gotcha is that if you set BUILD
to deny, then it will also override PVP
(remember that DENY
> ALLOW
> NONE
).USE
flag is now much more encompassing so you may find that it blocks things like CraftBook gates (for users of CraftBook). To fix that, you can do /rg flag REGION_NAME use allow
, but be aware that that will also allow the opening of inventories. To block inventories specifically, use /rg flag REGION_NAME chest-access deny -g nonmembers
. The -g nonmembers
makes it so only non-members of the region are unable to use chests, but this is optional.on-place
to water or lava blocks because it will also deny the use of buckets. If you wish to deny the use of just the liquid blocks, use on-use
. This is because WorldGuard now considers the use of a bucket also the placement of a liquid block.wg-invincible
and wg-amphibious
), you now have to enable these features in the config (auto-invincible-group: true
and auto-no-drowning-group: true
). This is because some permission plugins have been causing severe hang ups whenever it is queried for a player's groups, which, in this case, happens to include when the player joins.These plugins are known to be incompatible or have issues unless you update them.
USE
flag is explicitly set to ALLOW
(CRAFTBOOK-3057)Regions now fully support the use of UUIDs rather than names for storing the owners and members of a region. Commands still accept names, but they are translated into UUIDs in the background. For users who already have existing region data, names will be automatically converted to UUIDs on the first run of WorldGuard.
It is still possible to specify names rather than a UUID by using the -n
flag with the region membership commands.
Previously, a pre-determined list of blocks and entities was used to determine whether an action by the player should be blocked. However, this has been reversed so that every action on a block or entity is denied (in a protected region) unless it has been deemed safe (such as, for example, right clicking with steak). Mods are now supported as a result.
The USE
flag has been repurposed as a general "interaction" flag and covers every left click or right click of a block or entity. It also covers interaction that falls outside clicking.
More events are now handled in the protection code. For example,
Even water and lava flow can also be checked, although this requires that it be explicitly enabled in the configuration (flow events are very frequent, so they incur extra CPU cost).
The goal is to provide extremely exhaustive protection.
The performance of spatial queries for regions has been substantially increased at least an order of magnitude. Spatial queries are a necessity for the region code to query the list of regions that apply to a location in the world. There should be a negligible difference between 4, 40, and 4000 regions as long as too many regions are not overlapping.
Region commands are now executed in the background. Notably, saves and loads will not lock up your server while they complete. Additionally, changes to regions are now saved periodically rather than immediately after every change.
MySQL support has been completely overhauled. It should now be faster, no longer crash on foreign key index errors, use transactions, and support automatic creation and migration of tables (including support for table prefixes).
For users of MySQL, WorldGuard now only saves changed and deleted regions when saving region data. No longer does WorldGuard have to rewrite the entire region database on each save.
Multiple flags that apply to an event are now evaluated together if they are similar. For example, if a player right clicks a bed to sleep in it, both the USE
and SLEEP
flag are checked since they are both interaction-related. If one of them is DENY
, then sleeping is denied (remember, DENY
overrides ALLOW
). If one of them is ALLOW
and the other is not DENY
, then sleeping is permitted.
Only one "category" of flags needs to evaluate to true to permit an action. DENY
will not cross categories. For example, if BUILD
is deny, it will not override SLEEP
, so if SLEEP
is set to ALLOW
, sleeping will be permitted. This is fairly similar to how it worked on WorldGuard 5.
While you could always set a group to a flag's value, the functionality was incomplete and did not work most of the time.
Now that groups are supported, you can change a flag so it only applies to a certain group of players. For example, /rg flag example sleep deny -g members
would deny sleeping for only members of the example
region.
Previously, a region only inherited flags and other details from its parents if the parent and the child overlapped at the location queried. This is no longer the case and inheritance is now always applied.
In addition, a new -g
flag for /rg define
lets you create a region with no physical area so that you can assign flags and use this region as a "template region."
It is now possible to change the message that users get when they are prevented from interacting with blocks or entities. This message is defined as a region flag, so you can set it on the __global__
region or override it in a specific region. In addition, the tone and color of the default message has been softened, but you are free to change it entirely.
The blacklist was rewritten to support more than just block and item IDs. The immediate result is that you can now use data values, but as those are in the process of being deprecated by Mojang, it also allows support for Minecraft's new block variants in the future.
Events that tend to reoccur very frequently (such as the ones that occur when you stand on a pressure plate continuously) have been "debounced" to reduce the number of checks that WorldGuard has to perform, reducing the amount of wasted CPU. In addition, the "you don't have permission" message is rate limited so players are not flooded with the message.
A long requested feature was the availability of block place and break flags. These newly added flags work in tandem with the BUILD
flag but can override BUILD
. At the moment, it is not possible to allow explicit types of blocks to be placed or broken yet.
A new optional (disabled by default in the configuration) feature is the checking of build permission nodes. For every block, entity, and item, the following permission nodes are checked:
worldguard.build.block.place.<material>
worldguard.build.block.remove.<material>
worldguard.build.block.interact.<material>
worldguard.build.entity.place.<type>
worldguard.build.entity.remove.<type>
worldguard.build.entity.interact.<type>
worldguard.build.entity.damage.<type>
worldguard.build.item.use.<material>
In addition, the permissions are also checked in the style of worldguard.build.block.<material>.<action>
, so worldguard.build.block.<material>.place
would work too.
The list of usable material names comes from the Material enumeration in Bukkit. For example, the permission for placing the bed block would be worldguard.build.build.place.bed_block
. Be aware that Material contains both item and block names.
For entity names, see EntityType.
The rest of the changes can be found in the CHANGELOG file.