So the short answer is No.
The long answer is potentially.
There was some debate as to whether to allow movement tracking of mobs as well as players.
I might add this in the future. We’ll see.
For now just expand the no-spawn zone. Make a new, larger region if you have to.
That or you can build a wall along with the region to keep mobs out.
Sorry for the inconvenience.
Thanks for getting back to me. The biggest frustrations I’m having in trying to use your plugin is figuring out what flags are needed to achieve a goal. If “hostile enter” or “hostile mob spawn” doesn’t work for example, there is literally no way of knowing this based off documentation, examples (what does “root” even do?), or even searching this forum post. In the documentation available and in your tutorial video you mention “basic” handlers. You say it like there are other kinds but I can’t find any documentation on anything other than “basic”.
The CUI stuff you show you’ve been working on is great and all, but if there isn’t documentation on how to use the most fundamental part of this plugin, it’s not going to do a lot of good being able to click boxes. Don’t get me wrong though, I understand Sponge has issues too and some things aren’t going to work that should be working due to Sponge.
I am offended. xD
What do you mean there’s no documentation?
That page is up to date, and explains almost everything about the flag system.
The rest of the pages may be a little out of date, but are still relevant.
As a quick example,
root debuff block change
In your video you show just “block change” to accomplish the same goal. In all the examples on the documentation, it is not clear that fewer flags are better. Most Minecraft plugins have horrendous command structures so when looking at the examples it’s easy to get confused.
When would you use
root debuff
on their own or at all? The “root”, “buff” and “debuff” flags seem superfluous when combined with =true or =false. Is “block change =false” required to stop players from changing blocks? Seems like just “change =false” would do it and adding “block” is unnecessary based upon the documentation of the “change” flag.
Just did some testing after getting home from work and yes, using “block change” has the exact same affect as just using “change”. I then compared using just “place =false” to “root debuff block change place =false” and get the exact same result. I didn’t mean to imply there isn’t documentation, sorry if it came off that way. It’s just that the documentation is rather obfuscated making it difficult to figure out how to use it properly.
Basically the examples are overly complicated, and using the provided examples of commands leads one to believe that it is the required structure of flag statements. When in reality, the user is better off using the least amount of flags, and adding more on to get more specific. However, it should also be documented which flags are incompatible with each other like mob enter/exit.
Perhaps what would make it clear would be examples of actions and the flags they would produce.
Player placing a block generates the flags: root, debuff, player, entity, block, place, change, modify, secondary
To disallow a Player placing a block: flags<group> add player place =false
To disallow anything from placing a block: flags<group> add place =falseNote: flags
<group> add root =false
will prevent Minecraft from functioning properly as nearly every action generates the “root” flag.
I’m just guessing that this is how it actually works based off testing.
Alright after writing out my example I read over the wiki again (fourth time today) and realized the examples that are being provided are in fact the examples I just recommended. Perhaps it’s just me then. I believe it’s the overly verbose wording that confused me and the lack of command execution examples that ultimately led to my misunderstanding of the wiki.
Perhaps add in some example commands in the example sections?
Alas, I’ll leave these posts of my ignorance in hopes it helps somebody else in the future.
Thanks!
I had the same thoughts and went through the same processes you just did 
It could be more explicit, but the data and commands are there.
Okay, so you bring up a lot of very important points. Don’t feel like you’re being ignorant. Pretty much all you’ve said is correct, short of a few nuanced details.
The current flag system was designed to fix a very big problem.
The problem of inheritance.
Or more annoyingly, the problem of MULTIPLE inheritance.
See, the old flag system was originally a tree hierarchy, with each flag inheriting from exactly one other flag. Each flag would control a behavior, and if a flag’s value was undefined, it would check its parent flag.
However, this introduced a really big problem, specifically with entities.
Let’s say we had a flag entity, which was the parent of all entity related events.
Then we have a flag damage, which was a child of entity, and would cover events where an entity is damaged.
Then we also have a flag player, which covers entity related events where the entity is a player. This flag is ALSO a child of entity.
Now I want to add a flag damage_player. We now run into a problem: Should this flag inherit from damage or player?
The obvious solution is “both”, so then I introduced the concept of multiple inheritance. But then I immediately ran into the diamond problem of multiple inheritance. Google that if you don’t know what that is.
The only solution I could think of was to order the parents in order of priority, and use parent distance as a primary heuristic, and priority as a secondary, “tie-breaker” heuristic.
However this quickly became really unmanageable and even more confusing. It was clear that it was getting out of hand, so I tried a different idea.
Fast forward a lot of thinking, and the current flag system was born. Each event is a set of flags, and each flag represents some property, with the set only containing flags that apply to that event.
This makes the flag list very concise, and allows for control of more behaviors than what would normally be allowed.
What would have normally required you to set a dozen different flags, now you can do with just a single line. This is done using matching sets, or sets of flags that only match other sets if the other sets contains all the flags in the matching sets.
This is why the root or debuff flags feel redundant. It’s because they ARE. However this redundancy allows you to do things like debuff=true, which grants all permissions instantly. This makes it feel like it’s still a hierarchal system, even if it isn’t.
Hope that provides some context.
EDIT: ACTUALLY, have some more context.
FoxGuard is NOT a complete plugin. Honestly it’s VERY far away from completion. In the end product, most users don’t ever have to deal with the underlying flag system. The whole point of FoxGuard is abstraction. A lot of the plugin is abstracted in a way that can be extended later on. The handlers that are available right now pretty much expose the guts of the minecraft server in a very crude way. This is NOT the end product.
Which then leads into…
IF ANYONE WANTS TO HELP ME DEVELOP THIS BEHEMOTH OF A PLUGIN, I WOULD LOVE HELP.
THERE IS PLENTY OF CONTENT-BASED CODE THAT NEEDS TO BE WRITTEN, AND IT’S ACTUALLY FUN TO WRITE IT.
Now that i’m done crying over not having any help with this plugin, I hope you understand why the plugin is written the way it is.
I will probably have much more and much better documentation in the future, but until then, just bear with me.
Dear @gravityfox, is a very useful post. I have, in the beginning, also had a lot of questions. And I understand the newbies. Add a link to this post in the description section flags. This will remove unnecessary questions.
@gravityfox, I would like to see a roadmap for the development of the project!
Sorry don’t know java… just delphi (pascal). 
EDIT: You think about subplugin for casual players?
There doesn’t need to be a subplugin. There just needs to be more handlers.
I’m pretty secure in my assumption that asking this immediately makes me unsuitable to aid but what is content-based code?
If it’s comparable to generic data-entry / something someone with close to a nil-point knowledge of java and class structure can manage I’ve large blocks of free time available 
No.
It’s basically creating regions and handlers to do cool things.
If you aren’t a developer then you can’t help much unfortunately.
Thanks for the update and it really does clarify a lot of stuff. I really appreciate it. When I first installed your plugin my thought process was “This just doesn’t fucking work.” I deleted. A day later I put it back on and stabbed at it again. Still couldn’t figure it out. I kept at it for another day and finally got something to work. Poked at it some more and then made my first post with the screen shot. By the time I was done replying to myself I was thinking, “once you understand how this works, it’s pretty damned great and easy”!
So I really appreciate all your work and it is a really great plugin.
My last question is; does true or false have a priority over the other? If I “change =false” and “place =true”, does the “true” always win out? Typically in a permissions system (non-video game) the deny’s are usually general and the allow’s are specific and have a higher priority than the deny.
Okay. The answer is NEITHER.
Everything is evaluated top-down.
Anything on top of the list trumps anything on the bottom of the list.
You can actually reorder entries, or set them to certain indexes. That is why there is a move command for flags.
This is also why new flags are always put on the top of the list.
Cool. I’m good with that and that’s a great way to handle it. How do I do it?
Neither of these mention how to do that.
Tab complete is your friend.
For sure! So is documentation…
Seriously though I am very willing to help edit the wiki to be user friendly (I deal with UX and support as a day job) in any way I can. I’ve been looking for an excuse to learn Java and have done a cursory look over the source available on git. With a few clarifications I’d be willing to offer some edits in wiki and eventually some pull request in the code.
That there is all of the command code for the basic handler.
The whole thing is basically a tree.
I you can figure out what i’m doing here, you will earn a cookie, as well as access perms on the repo.
Oh this is going to be fun… I see parsing for custom aliases for groups and whatnot… Seems like a feature that requires checking with updates that is better left until the code is stable, or just left out. Was there a reason for this other than being easy enough to add?
??? I have no idea what you mean.