For most handlers, yes. Unless otherwise specified, either by permissions or by being directly named in a handler group, players will fall under the default group.
What @Inscrutable said is mostly correct. The only correction i’d like to make is that players can be in MULTIPLE groups, where if a player is in more than one group, each group they are in is checked from top to bottom, and the first matching configuration is applied.
In addition, everyone is ALWAYS in the
default group. However membership in other groups can override
default group configuration.
As a note, let’s say you have two groups,
members, where the
default group denies block interaction, and the
members group is empty. Just because you’re in both groups, does not mean that you are exempt from the rules in the
default group. If you want to be exempt, you have to add something like
block =allow to the
Hey gravityfox glad to see you’re still working on FoxGuard!
I’m setting up my server again now that I’m “done” school. I eagerly await a API 7.0.0 release when you take the project off hiatus as I am currently building an experimental server. Hope to see you around soon!
I’M STILL ALIVE
AND SO IS THIS PROJECT
I just wanted to let everyone know that this project is in fact alive.
I know it’s been awhile since I’ve made an announcement so here we go.
Couple of things that people should know
FoxGuard works for API 7. It was being used during State of Sponge XVI this past weekend.
I’ve been working on a very large update that addresses many roadblocks in the project.
Objects now have a concept of owners*
The storage mechanism has been completely rewritten to be much more stable, which means no more random disappearing objects, cause that was getting really annoying.
Objects are now referenced via a more complicated pathing system. For the most part, there’s only one change to existing command syntax that should be pretty easy to pick up.
These changes mean that the following will now be possible:
Owners* provide a sensible structure to make user claims actually reasonable. While these won’t be part of FoxGuard itself, it will be done through an add-on plugin to FoxGuard.
The new storage system won’t break mysteriously or between updates, because I’m actually using a tried and true system from now on. It also means that if you’re brave enough, you can edit the storage format yourself, cause it’s all just JSON files now.
The path system will allow me to implement object grouping, which will look much like a filesystem. This will be a major help to servers that have hundreds of regions that they need to manage by allowing regions to be aliased to various groups.
Progress on these changes can be seen at:
Anyway, this is to let everyone know that I am in fact still alive and working on this project. However, university is really hard and I’m still not able to put as much effort in as I would really like. Updates will be slow, but they will happen.
If anybody feels like lending a hand, I welcome people to contribute, as I’m still a little short on coding power.
Link to my discord here: https://discord.gg/yZPEeS6
*Note: The term “owners” in this case is not related to permissions or access control. It pertains to who (or what) the object is stored under. This allows two handlers with different owners to have the same name. Which means that a user-service addon can allow every player to have a region called “home” with no conflicts.
All existing regions will be assigned the “server” owner, which is a special placeholder owner that represents the server. Objects under this owner are stored in their original locations, while other owners have their own special directories on the filesystem.
Hi there, I’m relatively new to foxguard and had one question. I’ve set up my handler, linked it to my region and I believe I have done everything correctly, yet my players still cannot open chests or interact with objects. Do I need to somehow create a node for the handler and add it to my default group in luckperms? If this question is answered elsewhere, apologies. This is a screenshot of my setup:
Check to make sure they’re not being blocked by minecraft spawn protections. Go to
server.properties and make sure the spawn protection is set to 0.
That was the issue, cheers Gravity!
Is there any flag for decay of ice yet within the newer updates that is not included in block change?
Not yet. Sorry
Hey all, I have a big issue. Play
ers will break blocks and they will automatically come back as block break is set to false, but there is a chance that the item will drop. Does anyone know a fix for this?
This is most likely an incompatibility between Sponge and various mods that don’t behave correctly.
If it’s vanilla blocks doing this, then try updating Sponge. the Sponge Community Server does not appear to currently have issues like this.
We are using Sponge 3206 as I have been told it is the most stable build. I can try updating if need be!
If you mean SpongeForge build 3206, it is rather outdated. The latest recommended build of SpongeForge for Minecraft 1.12.2 is 3361, requiring Forge 2705.
So I have a bit of an announcement to make.
I am rewriting this plugin.
The code has just gotten too big and unweildy to do anything with.
Once some framework code is done I might ask more people to contribute.
If anybody has any design ideas, please join my discord server and PM me.
Hi, do you have any clue when custom region shapes will be added?
The block decay flag does in fact prevent me from decaying, which was broken in previous versions if I remember correctly, however it does not stop the leaves from dropping sapplings frequently despite the leaves not decaying, which causes a lot of ground items over a period of time which, obviously, causes lag, so please fix whenever you can. Thank you.