WorldGuard 1.8 problem

Discussion in 'Spigot Plugin Help' started by dadus33, Dec 31, 2014.

Thread Status:
Not open for further replies.
  1. Hi guys, I have a little problem with worldguard and thought you might help me.
    As soon as spigot 1.8 was out, I had to update my server. It was a tricky job, because I had to remove some plugins that didn't work with 1.8 and also update all the others. Finally, I thought everything was done and working fine, but I was wrong... I realized that for some reason, players just couldn't open any containers near the spawn, in the WG protected area (enderchests, anvils, enchanting tables, and even crafting tables). I set the flag chest-acces to ALLOW but this has no effect either...
  2. Cldfire

    Cldfire Retired Moderator

    Are you using this version of worldguard?
  3. This is the version I'm using.
  4. Cldfire

    Cldfire Retired Moderator

    Hmm I use an earlier version and I don't have any issues....

    I'm reading through the flags again, hold on.

    Try /region ID flag use allow

    #4 Cldfire, Dec 31, 2014
    Last edited by a moderator: Dec 31, 2014
  5. Ok, I did that, but I can't check wether it works now... I'm not home right now and I can only access my console. I'll report back in about 1 hour.
  6. Cldfire

    Cldfire Retired Moderator

    Alrighty, let me know what happens.
  7. TheOnlyRealTGS


    Still amazes me how many people doesn't read the "READ_BEFORE_UPGRADING_FROM_V5.html" (included in the dl) file before they upgrade...
  8. Cldfire

    Cldfire Retired Moderator

  9. Oh, I'm feeling really stupid now...
  10. Cldfire

    Cldfire Retired Moderator

    Just make sure you read attached files that are named "READ" in all caps ;)
  11. Well, it looks like I ran into another weird wg problem...
    However, before going ahead, you have to know how my spawn regions look, so here's a model I made in paint:
    Now, the problem is that mobs simply don't drop XP in region 2. However, they drop xp everywhere outside the whole spawn region.
    The flags I use for the 1, 3, 4 and 5 regions are the following:
    build: DENY, chest-acces: ALLOW, mob-spawning: DENY, invincible: ALLOW, exp-drops: ALLOW, snow-fall: DENY, leaf-decay: DENY
    The flags I use in the XP monster drop region are:
    passthrough: DENY, build: DENY, block-break: DENY, block-place: DENY, mob-spawning: ALLOW
    So why can't mobs drop XP inside those regions?
  12. sorry for the bump but I really need help with this...
  13. Thats the latest WG build right? The build deny flag blocks everything, is my understanding...Turn that flag off. Not build allow just off completely.
    Region Protection
    The region protection has been optimized and aggressive caching has been added. That means that the impact of region protection when hundreds or thousands of regions exist has been minimized.

    • UUID support was added. On first server start, your region data will be converted to use UUIDs. Names that lack a UUID (i.e. they refer to accounts that don't exist) will remain, but can be removed by re-running the conversion (see the config) after changing the configuration to remove unconverted names.
    • Build protection for regions is now much more complete, and WorldGuard protects against entities and blocks making changes as if they were players. For example, TNT cannot be flung into a protected region and piston machines cannot push into a protected region. Liquid flow (lava and water) can also be checked, although this is disabled by default.
    • Setting the build flag to deny will break pistons and Redstone. When you set the build flag to deny, you are essentially saying that no one can build at all. Now that blocks and entities are considered the same as players, they get blocked in that case. What's the solution? First of all, you probably do not want to set the build flag: remember, when you create a region, only members can build in it, so there's no need to change the build flag.
    • If you want to deny building "in the wilderness," use /rg flag __global__ passthrough deny. Unset the build flag if you had set it to deny. As you may know, when you create a region, protection is automatically turned on (only members can build). If you don't want that, you can set a region's passthrough flag to allow. In the case of the global region, it defaults to allow, so you have to set it to deny to turn that off.
    • Earlier versions of WorldGuard 6 changed the use flag to be much more encompassing, but this is no longer the case. The use flag now works like it did before in 5.x, only applying to things like doors, pressure plates, and levers. A new interact flag was added instead that controls all right clicks of blocks and entities.
    • By default, the use flag is now set so only members of a region can use levers and doors within a region. If you want to disable this type of protection in all protected regions, use /rg flag __global__ use allow.
    • Region groups for flags now work properly. You can set a certain flag to apply to only a certain group (owners, members, nonmembers, nonowners, all). Before, it only worked correctly for some flags. Region groups can be set like this: /rg flag spawn pvp -g nonmembers deny.
    • In WG 5.9, some flags had a default region group of "non-members." That means that if you did /rg flag spawn chest-access deny, only non-members would be unable to open chests. In WG 6, you have to explicitly specify this: /rg flag spawn chest-access -g nonmembers deny.
    • 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 MySQL code was substantially rewritten to be faster and more efficient. Some changes are needed to the table structure, but WorldGuard is now capable of performing those automatically. However, those who use table prefixes may run into trouble.
    #14 EODSteven, Jan 17, 2015
    Last edited: Jan 17, 2015
  14. Yay! It worked! Thanks!
    • Like Like x 1
  15. Sorry to bump this, but also try using "/rg flag <id> interact allow"

    I did that on my server and it's working for me :D.
  16. This is kinda solved... But thanks anyways for the advice!
Thread Status:
Not open for further replies.