u/Valdair

I'm running 26.1 on fabric, with latest versions of Iris for shaders (BSL) and Distant Horizons, with Sodium, Xaeros, and that's it for mods.

Sopmetimes when I look at distant water it looks totally normal and fine, but if I change my view angle just slightly enormous swaths of the water disappear and it looks really bad.

Here is another example. Water there. Water gone.

Fiddling with the vanilla render distance does appear to extend the cutoff range very slightly (it's not 1:1) but I couldn't find any setting that fixed it. What's so weird is it is so sensitive to the exact angle you're looking at, and sometimes looking more directly at it helps and sometimes looking more directly at it makes it disappear. I'm stumped.

Largely irrelevant background info

I am managing a small server for a friend who has a small but growing social media following. He doesn't know much of anything about or care for Minecraft but his community is mostly nerdy gamer types so of course it was only a matter of time until it came up.

Server Setup

We have several moderators on the Discord server at various experience levels. I'd like the ones who are more experienced with Minecraft to have more admin-type permissions, the intermediate ones at least have the ability to ban/kick problematic people, and run a few other basic commands (change their gamemode, give themselves items, etc.), and interact with the claiming feature of the server. Another express feature of the server had to be Bedrock compatibility, as we are hosting using Discord's built in game server feature hosted by Shockbyte and I'm not really looking to host this off my personal server unless I absolutely have to. That means we're running Java 1.21.11, on Fabric (just personally what I am most experienced with for vanilla-ish modded Minecraft), with Geyser & Floodgate. Bedrock handshake appears to be working fine.

To handle the permissions we settled on LuckPerms, and for claims we piloted a few mods but settled on Flan. Now the problem.

---

Issue #1: Moderator group won't get specific permissions granted if a lower weight group has a wildcard that sets them to False

What I wanted to do is basically this, for Luckperms groups:

• Default: no perms for anything, just vanilla survival. No inheritance. Meta default = True to force this to be the default join group.

• "Trusted": add in a few bare minimum perms to use flan, namely the ability to create 1 single claim and edit its behavior (choose whether to allow people to use doors and levers on your plot, things like that). Inherits from "Default".

• "Mod": add in all flan permissions (except the "nuke everything" button) and most vanilla Minecraft commands, e.g. ban, ban-ip, kill, give, tp, etc. but not server operating ones like stop. Inherits from "Trusted".

• "Admin": all permissions for vanilla & all plugins exposed and granted. Inherits from "Mod".

• A special category for the social media friend in case he deigns to join us. No additional perms beyond that of a default player, just a special color tag. Inherits from "Trusted".

The weights for the above are set to 0, 3333, 5555, 7777, 9999 respectively.

We discovered to get vanilla permissions exposed in LuckPerms we had to add another mod to the mix, Vanilla Permission, and this is where things get kind of weird.

Testing the Default group with a non-op user, everything worked as expected. No commands exposed. Testing with Trusted, the user does in fact just get the flan perms we want. Where it gets weird is moderator. If someone is in the moderator parent group, they still don't get anything. If we op them, they get access to everything (apparently bypassing luckperms). If they're not op, they get nothing, it's like they're still in the Trusted group.

This seems to only affect the commands exposed via vanilla perms, luckperms.* can be denied at the Default group level and specific perms are exposed to moderators at a higher level with no issue. It seems like for vanilla commands LuckPerms isn't letting an expressly given command (e.g. minecraft.command.ban True) override a generic one at a lower level (e.g. minecraft.command.* False).

To resolve this we tried two ideas. One is that maybe if the permissions are blanket denied at a lower weight, you have to grant the explicit permissions at the individual level, i.e. you can't have

minecraft.commands.* False

at weight 0 and

minecraft.commands.ban.* True

at weight 5555, you have to instead grant

minecraft.command.ban True
minecraft.command.ban.targets True
minecraft.command.ban.targets.reason True
minecraft.command.ban-ip True
minecraft.command.ban-ip.target True
minecraft.command.ban-ip.target.reason True

etc.

along with all the other members of that group. This didn't work. Next we just removed all the blanket denied permissions at the default (weight 0) level, leaving it basically empty. I think the default group shouldn't have access to these anyway by not being server ops, but it seemed safest to auto-deny everything and just incrementally add permissions as we went up in group weight. So it's not clear to me if this is a bug with the communication between Vanilla Permissions and LuckPerms, where a .* False ALWAYS overrides anything other than a True, except another .* True, no matter the weight? I'm a little nervous leaving the default group essentially empty of either positive or negative permissions but the alternative is that there is no difference between a mod and an admin - we have to grant e.g. minecraft.commands.* True at the mod level or else they get nothing. I could use some help or guidance here, I tried Googling and didn't find anything.

---

Issue #2: Is it possible to control the options of a command based on the weight of the command and the weight of the user running it?

This seems like a fairly obvious thing to me but maybe the way permissions are implemented in Minecraft just makes it literally impossible. Specifically what I want is for Mods (5555) to be able to promote users from Default (0) to Trusted (3333), but not be able to promote them to mod or higher (5555+). This is mostly to prevent doing so by mistake, as once anyone has this permission they can elevate anyone else to any role effectively giving them full permissions.

The command I'm imagining is like

Default

luckperms.* False

Trusted

luckperms.* False (inherited)

Mod

luckperms.user.parent.set.* <weights less than 5555> True

Admin

luckperms.* True

So mods could promote default users to Trusted, or demote them I guess, but can't demote each other or promote themselves to admin. The documentation is really sparse on how exactly weight can be used, just that it's a sorting mechanism basically. Is there even a way to do this kind of "you can run this command, but only on these sub-options and not these" ?

---

We could just agree to put all mods in the admin category, but this isn't really a trust issue, it's more of a "why give everyone the 'blow up everything' button if they don't really know what they're doing or even need to know what they're doing?" It's really to cut down on mistakes. We have some players who are Discord side server moderators who should have some authority but just don't have the expertise to make it make sense to give them everything. But currently the mod group is effectively useless and we have to give every mod admin to be functional.