Is there any possibility of more flags being added? I would like to disable all explosions and hostile mob attacks in a safezone. Currently players aren’t able to break blocks in spawn but a tnt cannon could be used to grief spawn. I have also had zombies wander into spawn and start attacking.
Any specific flag that allows players to click signs in protected regions? Trying to allow them to click warp signs within the spawn but it will not let them
Anyway to prevent players from claiming regions protected by FoxGuard? i.e a spawn area
FoxGuard was not made for claims.
It was made as a server admin tool.
There will be an addon down the line that will allow user claims to work nicely with it, but for now there is not a claiming function.
He means blocking commands such as using poli claims inside a protected region that was made by Foxguard
ohh, i don’t think so unfortunately.
That is completely out of my control, however if @HassanS6000 wants to add specific support he can…
1 Like
Not sure about that - you can easily claim an area in Polis with SafeZone, preventing other users from claiming it…
Yeah, but you have to walk over each block that you want to claim, its very time consuming to do so 
Welcome to inter-plugin (in)operability.
2 Likes
That is incorrect - you can specify a radius to claim.
2 Likes
Really? Since when? Ive never seen that option
Can we define a server group (with PEX like Citizen), as a member group or must we add manually all players of Citizen’s group ?
I want give ability to Citizen’s group to build on my server and deny for Visitors group.
Use a permissions handler. You can link it to the global region for the world, and grant or deny build permissions to each group using the permissions for that handler. It’s explained reasonably well on the Foxguard Wiki.
So we only use the handler to link it in the permissions file and adding with a “.” with the tag to add or remove to the group ?
It’s all needed ?
That is more or less the case.
When you make a permissions handler of name permshandler, and link it to one or more regions, when some event happens that needs to be resolved, such as a block being broken, the permissions handler will check if the player has the permission foxguard.handler.permshandler.blockbreak.allow
It will also then check the .deny and .pass permissions before going up the hierarchy.
A better explaination can be found at https://github.com/FoxDenStudio/FoxGuard/wiki/Permission-Handler
OK thank’s. It seems working.
So here’s a bit of a status update on the current state of FoxGuard.
I know I haven’t put out an update in awhile, and that I kept promising “soon” to everyone.
So It’s about time I gave an explanation.
Up until the last few days, I have been very busy catching up with school work and pouring time into building a robot to compete in the First Robotics Competition.
At the same time, FoxGuard has become somewhat of a mess.
I have been quite dissatisfied with the structure of the code for quite awhile now, as a lot of the code was incredibly fragile, especially the way everything was saved and loaded, as many of you have witnessed.
I have also longed to add certain features for awhile, but said fragility was making it very difficult to do any major improvements without breaking everything over and over.
So I’ve decided to rework a good amount of FoxGuard, including completely redoing how things are saved and throwing out old code that just doesn’t work right. In the end it should be a lot better.
However this does mean a few things.
- Old FoxGuard data WILL NOT LOAD AT ALL!!! (This is not something i can fix. The format is completely different.)
- The commands will work slightly differently than they used to. (The overall structure was changed slightly, especially in respect to regions.)
- The internal API is fragile and is undergoing breaking changes. If you are a developer that wanted to hook in somehow, I would recommend waiting till the next release.
- It’s going to take more time than I had hoped.
While I am charging at this project full force while I have spring break, there are so many changes that need to happen before I can make a release. At this point it’s all or nothing.
Thanks everyone for being patient and I hope to have something out soon.
4 Likes
This isn’t directed at you, gravityfox, you keep up the good work, this is directed at the mass of FG users that frequent here:
I am using FG as a protection region around the public areas of my server, this means that they are not able to break or modify blocks in any way. I am running into an issue where I have blockplace set to false and blockinteract set true so as to allow my players to access public chests, crafting benches, etc. But this has caused an issue where players can place blocks, regardless of blockplace being set. Do I have to apply these flags in any order? Or is this a limitation of the simple handler and is only solved by using permissions handlers?
TL;DR
Blockinteract is blockplace’s bigger, meaner brother, and doesn’t care what his little, more specific brother says or wants.
EDIT-SOLVED:
The precedence of inheritance matters, so if one is above the other on the list, or is set in the wrong order it will negate the other. See here:
This is the broken setting, with players allowed to place blocks. I cleared blockplace and reset it, which restulted in this:
Which works as desired, and players are no longer allowed to break NOR place, and still allowed to access public blocks such as chests and crafting benches.
I hate to burst your bubble, but the order doesn’t matter at all. The order you see when you show the details is a result of both Java’s HashMap behavior as well as my own laziness to write a better detailing implementation.
There is another issue going on here.
Sponge fires InteractBlockEvent.Secondary before BlockChangeEvent.Place. If EITHER of the two are cancelled, the block place is canceled. This means that for all intents and purposes, the blockplace flag isn’t actually there for some reason.
Which brings me to my next point. That should be impossible. There is no caching going on in any released version of FoxGuard, which means that if the detail command is showing a flag then it MUST exist.
I suspect there is another bug that I can’t figure out just by looking at it.
If you can give me steps to reproduce this bug, please let me know. I would have to look into this very hard to figure out what is going on. HOWEVER, a version would be nice to have, so that at least i know which code I should be looking at.