LuckPerms | An advanced permissions plugin

Plugins Plugin Releases
162

@Rasgnarok
Hi, sorry for the huge delay. I’ve been kinda occupied with real-life things & other features, but I’ve finally now got time to have an attempt at implementing this.

I’m struggling slightly with what the best approach is.

My thoughts are that you could just specify in the config how many prefixes you want to show, and it will pick the highest x prefixes from all of the ones a user has.

For example, if a user has/inherits the following prefixes:

100 - [Mod]
50 - [Builder]
20 - [Some high level donator]
10 - [Some low level donator]
5 - [Member]

And the config is just set to pull the top 3, they’d get:

[Mod] [Builder] [Some high level donator] Luck: Hello

Is that high enough control for what you’re looking for, or would some way of filtering the nodes be better? Perhaps a way to select from a list of priorities? Or is that too complicated?

I’m open to any better ideas if you have any. :slight_smile:

163

I’m obviously going to be biased here because I write Nucleus, but I’ll throw my tuppence in anyway.

I’d like to just see weighted options or meta, so that each option is given a weight and the highest weight wins in case multiple groups has the same option. I feel that chat plugins should control how it displays prefixes and what options it uses, so you shouldn’t worry about special treatment of prefix options, that should be left to the chat plugin in question, because if you throw your own handling in there, it could just make things more confusing for the server owner. Besides, I don’t think what you suggest would give the control a server owner would like.

The way Nucleus works to provide multiple prefixes/suffixes is to just allow any option to be a prefix or suffix. If you look under “Custom Prefixes” at http://nucleuspowered.org/docs/modules/chat.html, you should be able to see that Nucleus can display any option/meta as a prefix.

So, setting the Nucleus chat “prefix” to {{o:rank:s}}{{prefix}} {{displayname}}&f>: would try to read both the “prefix” meta and the “rank” meta (ignore the o: and :s for now). If one of @Rasgnarok’s players (let’s pretend that it’s me, because why not?) was in the Mod group (with “prefix” meta set to [Mod]) and the Builder group (with “rank” meta set to [Builder]), I would expect Nucleus to output the following when I said “hi”:

[Builder] [Mod] dualspiral>: hi

In this case, no weighting would be needed.

If @Rasgnarok now has a BuilderPlus rank, with “rank” meta set to [Builder+], but for some reason doesn’t like inheritance, then what would be good is to be able to set a weighting to the meta/option too, where the highest weight wins. So, if the rank meta for Builder had a weight of 1, and BuilderPlus gave a weight of 2, then the result of getting the “rank” meta/option for a player with both groups would be [Builder+]. Not sure what you’d do in the edge case of the same weights being assigned, but as long as it’s predicitable, that should be good enough.

When I originally asked for Support permission options other than prefix/suffix · Issue #23 · lucko/LuckPerms · GitHub it was to support chat and other things in Nucleus. It would be cool if you’d consider weighting options/meta, even outside of this use case, I think it would be incredibly useful for bother server owners and developers, who have to worry less about what the permissions plugin might return, which can be a headache sometimes!

3 Likes
164

Thanks for the reply - incredibly helpful in a number of ways.

Shortly after asking, someone on my Discord informed me of the way Nucleus handles chat - and I agree, it certainly makes much more sense than permission plugins handling things. @Rasgnarok I think just using different option names alone could probably solve your needs? I guess that would be possible with PEX too - so you wouldn’t even need to switch if you didn’t want to.

Anyway, going back to option weights. I already do implement a similar system in LuckPerms.

(Just remember, things for me are made so much more complicated, as I also support Vault. (I know…))

Prefix & Suffix data is stored differently to normal options. Each prefix/suffix has a priority attached to it. Whenever a Subject’s prefix or suffix option is queried, the nodes inherited from their parents are flattened, and the prefix/suffix with the highest priority is returned.

You can see that happening here:
https://github.com/lucko/LuckPerms/blob/master/sponge/src/main/java/me/lucko/luckperms/sponge/service/LuckPermsUserSubject.java#L140-L150
https://github.com/lucko/LuckPerms/blob/master/common/src/main/java/me/lucko/luckperms/common/caching/MetaCache.java#L40

This probably isn’t entirely in-line with the option implementation seen with other providers, however it’s the best way I could manage whilst supporting both Sponge & Vault at the same time, under the same system.

Despite the superior system you have in Nucleus, I’ll probably still end up implementing this for the Bukkit version. (I’ve had requests from my users there too…)

As for implementing weights for other options, I think the only end result would be making things incredibly difficult to understand for end users. Additionally, storing the data in that form would be hard too. (although I realise that probably only applies to me & my twisted methods of data handling)

Anyways, yeah. Thanks for your help - I had no idea of the system you had in place prior to this. :wink:

165

So, I actually came to this because after trying multiple times (with tickets to prove it), I still cannot make that system work - and so, thinking that PEX is notoriously outdated, I wanted to see other possibilities in terms of multiple ranking. There could be something I am missing, however in following your directions, @dualspiral I was not able to make anything showup but the {{aprefixoption}}. Now, I am quite certain it is not something on Nucleus’ end, and so I think my current dilema is either a consequence of human error, or PEX’ own fallacies.

The option in the chat module does not show the actual prefix, but a {{prefixStaff}} to all players, regardless if they have the option or not. This has once again led me to use nicknames to palliate, as I have not been able to make it function as it is supposed to.

Regardless, any help with this would be appreciated, as I do plan on jumping to LuckPerms sooner or later, and it seems that for all the hours spent on this, I am still missing something. Thanks guys.

166

You have the format wrong.
http://nucleuspowered.org/docs/modules/chat.html#Custom_Prefixes

Custom Prefixes
Nucleus, as of 0.9, supports custom tokens other than “prefix” and “suffix”. In the chat formatting string, you can add the following tags:

{{o:[option-name]}} - replaced by the text in option “rank”, if any.
{{o:[option-name]:s}} - replaced by the text in option “rank”, if any. If there is text in the option, adds a space afterwards.
In both cases, the option name is whatever you called the option. So, if you wanted a token called rank on a moderator with the string [Rank] before the prefix using PermissionsEx, you would run the following command:

/pex group mod option rank [Rank]
then have the following template:

"{{o:rank:s}}{{prefix}} {{displayname}}&f>: "
If you also had a default group with the tag “[Default]”, this would display “[Rank] [Mod] name> chat” for moderators, and “[Default] name> chat” for default players.

167

I know, it is what I did. I forgot the o in the post, you are correct. The point remains, that formatting only displayed the prefix as shown in the Nucleus config, not as an actual option.

EDIT: I’ll be testing this again tomorrow, and properly file another issue on it, with screenshots and config.

168

Hey there, I recently started using your plugin. I use the json data storage but I can’t seem to figure out where the “parent” inheritance is stored? eg. if I make “default” the parent of “builder” there is nothing in either of the json files that shows the inheritance link

169

It’s stored an explicit permission - ie. group.default or similar.

1 Like
170

thank you, didn’t even notice :slight_smile:

171

I looked around this post didn’t see this question asked but do you have a migration command to convert pex over? Or is that extremely hard to do?

172

You’re looking for /lp migration permissionsex :slight_smile:

173

release page and stable version can not download.

174

Latest downloads can be found here

https://ci.lucko.me/job/LuckPerms/

1 Like
175

How to set option in Luckperm ? In wiki do not have set option

176

/lp user Luck meta set option value

177

How to change default group to member ?
I read wiki. I tryed. I can not change default group.

178

You can’t - that’s explained in the wiki, and alternate means of setting a so-called “default” are outlined.

179

Could you update to API 5? It currently gives some insane error messages in console.

180

I’m not sure if this has been answered previously, however in the config of LuckPerms, I cannot find the debug option nor the allow/disallow OPs (I think this is an option?). I have tried to find “debug” within the file but no results are shown. If it helps, I am using LuckPermsSponge-2.15.17.jar as the version.

181

How set permission group in another world ?
I need mini example for command.