2/1/2024 0 Comments Minecraft forge for 1.13![]() Create a query RegionQuery query = WorldGuard. ![]() This means that the method of testing a flag is now the following, This change means most usages of the API will no longer require getting a copy of WorldGuardPlugin. This is done via WorldGuard.getInstance().getPlatform().getRegionContainer(), rather than the old WorldGuardPlugin#getRegionContainer(). To query for flags in a region, you must obtain the region container from the platform instead of the plugin. This area is the other major change that developers may notice in WorldGuard 7. This change is part of the effort mentioned above to make WorldGuard platform-agnostic. One other change is that flags now use WorldEdit generic classes, rather than Bukkit specific classes. The following code gets a copy of the flag registry in WorldGuard 7, WorldGuard.getInstance().getFlagRegistry(). You can now access this through the core, rather than through the Bukkit plugin. All usages of the class should be easily replaceable, aside from iteration over flags which you should now do via the registry.Īccessing the flag registry has slightly changed in WorldGuard 7. This class handles the flags built into WorldGuard in a more registry-friendly way. The DefaultFlag class is now called Flags. Flagsįor most plugins that integrate with WorldGuard, the first noticed change will be that the DefaultFlag class no longer exists. The core system is accessed through WorldGuard.getInstance(), and the platform-specific code can be accessed via WorldGuard.getInstance().getPlatform(). I explained the reasoning for this above. This change is similar to the way WorldEdit works. We removed all of the old deprecated APIs and moved most major accessors to a 'core' package. Here is where substantial changes start to occur. Everything should work as it did before, with "as good as possible" automatic conversion of configuration files. The Block Parsing section from my previous article also applies here to WorldGuard however, it also extends to entities and game modes.Īside from that, there should be no other known user-facing changes in 1.13. Like WorldEdit, there are as few user-facing changes as possible. Now was the most appropriate time to do this, as 1.13 already broke almost every plugin that existed, and the WorldEdit API is practically 100% breaking. So while it cannot support Sponge at this stage, we can now implement it without breaking every plugin that depends on the WorldGuard API. One major roadblock for this was the requirement to cause API breakages to provide actual feature parity across the platforms. One of the most common WorldGuard questions I get asked is "Can I download this for Sponge?" Sadly, the answer to this is no. While my changes have not made WorldGuard cross-platform compatible, it provides the stepping stones to allow this in the future. However, WorldGuard has a LOT of Bukkit specific code. ![]() WorldEdit and WorldGuard are very similar internally, both abstract away the game concepts to allow for cross-platform usage. Much of the work put into WorldEdit made WorldGuard much easier to update however, we made changes to the plugin's core to allow for future improvements. Updating WorldGuard to 1.13 has been a complicated process, however not as time-consuming as WorldEdit. This article is the third in a series of articles, the first can be found here.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |