The wiki from what I can tell is using a more common header-link slugifying.

While it isn't bad, does it create some ugly to read header links.
As an example, the current header for /lp verbose <on|record|off|upload> [filter] is #lp-verbose-onrecordoffupload-filter and with the Command option added would it become even larger.

That's why I would like to propose an option to allow overriding slugs, if not doable already, to allow more easily to read header links (i.e. #lp-verbose for the verbose command).

Biggest downside would be losing support for the current header links, but this may be mitigated using some redirecting rules or smth... Whatever the Software used for the Wiki would allow.

They accept a duration paramater since LuckPerms/LuckPerms@f893b1c

The General commands page currently only lists the /lp verbose command options on, off, record and upload and leaves out the command option completely.

The only place this command is mentioned in is the Verbose page, which not everyone would check. So for transparency reasons should it imo be listed, tho it could become a bit overloaded/bloated, which is why I personally first want to discuss this here before making a proper PR.

My current Idea:

#### `/lp verbose <on|record|off|upload|command> [filter|<me|player> <command>]`  
**Permission**: luckperms.verbose  
**Arguments**:  
* `<on|record|off|upload|command>` - whether to enable/disable logging, or to upload the logged output, or to perform checks on a command
* `[filter|<me|player> <command>]` - the filter to sort the output, or the player and command to use verbose on when the `command` argument is used

Controls the LuckPerms verbose logging system. This allows you to listen for all permission checks against players on the server. Whenever a permission is checked by a plugin, the check is passed onto the verbose handler.    

If your filters match the permission check, you will be notified.    

`on` will enable the system, and will send you an alert in chat when the filter is matched. `record` will do the same, however you will not be notified of checks in the chat. `off` will simply disable the checking, and `upload` will upload the first results to the web viewer, and provide you with a link. `command` will allow you to execute a command as the specified player and return any permission checks.    

Filters match the start of permissions or the user being checked. You can use `&` (and) and `|` (or) symbols, and `!` to negate a match. Parenthesis `( )` are also supported.   

**For example:**    
* `Luck & (essentials | worldedit)` - matches any checks made against my user starting with "essentials" or "worldedit"
* `!Luck & !anticheat` - matches any checks not against my user and not starting with "anticheat"
* `anticheat & !anticheat.check` - matches any checks starting with "anticheat" but not starting with "anticheat.check"    
  

More information can be found [**here**](Verbose)

A confusion for many inexprienced people with verbose is the undefined status.
The wiki page should explain what all 3 states mean.

When using https://www.spigotmc.org/resources/luckperms.28140/ luckperms it is not working
Any reason or way to fix this?

About the command-usgae.permission-reference page, I suggest change the table into such a format:

The one now using is a bit confusing, as the word "command" appeared in the table seems redundant and could be omitted

On the page, https://luckperms.net/wiki/Verbose
Change hyperlink to, https://luckperms.net/wiki/Permissions

Thanks for the already good documentation. It helps with the most common administration tasks for this plugin. It should be enough for most users, but for more advanced users it lacks documentation of the permission prioritization and what effects the priority calculation.

Example

For permission debugging it's very important to understand which permissions are higher weighted than others.

For example: What is the priority list here for Testuser1 at Server1 in World1:

USER: Testuser1

• test.a with TRUE for GLOBAL ⁽¹⁾
• test.* with FALSE for Server1.World1 ⁽²⁾
• test{a-c} with TRUE for Server1 ⁽³⁾
• group.rang1 (PRIMARY GROUP) [LEVEL: 30] ⁽⁴⁾
• group.rang2 [LEVEL: 10] ⁽⁵⁾

RANG: group.rang1

• weight.30
• test.a with TRUE for GLOBAL ⁽⁶⁾
• * with FALSE for Server1.(World1|World2) ⁽⁷⁾
• test{b-c} with TRUE for Server1 ⁽⁸⁾

RANG: group.rang2

• weight.10
• test.(a|d) with TRUE for (Server1|Server2) ⁽⁹⁾
• test.* with TRUE for GLOBAL ⁽¹⁰⁾
• group.rang3 [LEVEL: 20] ⁽¹¹⁾

RANG: group.rang3

• weight.20
• test.* with TRUE for Server1.World1 ⁽¹²⁾
• test.a with FALSE for GLOBAL ⁽¹³⁾
• test with FALSE for GLOBAL ⁽¹⁴⁾

It's hard (or for me: impossible) to say how the plugin would apply the permissions in the current context, without testing it out first. Of course, that is an extreme example, but it helps to understand how hard the analysis of permission problems can be, especially with the amount of different configuration settings, player contexts and everything else that can affect the calculation.

In this case, I defined the following configuration options:

• Usage of BungeeCord: Yes
• primary-group-calculation: parents-by-weight
• inheritance-traversal-algorithm: depth-first-pre-order (I'm not sure if it's important. Does it only have a performance impact?)
• include-global: true
• include-global-world: true
• apply-global-groups: true
• apply-global-world-groups: true
• meta-value-selection-default: inheritance (I'm not sure how it affects the result.)
• apply-wildcards: true
• apply-regex: true
• apply-shorthand: true
• apply-bukkit-child-permissions: true (It may be only important for the plugin.yml of a plugin. So it has no effect in this case.)
• apply-bukkit-default-permissions: true (It may be only important for the plugin.yml of a plugin. So it has no effect in this case.)

Priority (what we know)

So basically, I know the follow priorities, based on the configuration and the wiki article on https://luckperms.net/wiki/Advanced-Setup as well as my own experience with Minecraft permission systems, especially with LuckPerms:

• PLAYER permission > GROUP permission
• GLOBAL > SERVER > WORLD
• test.* > test (because it is more detailed)
• test.a > test.* (because it is more detailed)
• test.a.* > test.* (because it is more detailed)
• positive permission [TRUE] > negative permission [FALSE] (older version of LP had an option for this apply-default-negated-permissions-before-wildcards)
• group wights: weight.30 > weight.20 > weight.10
• temporary permission > non-temporary permission
• temporary permission for 1 hour > non-temporary permission for 1 day

The article https://luckperms.net/wiki/Advanced-Setup is a good documentation, but it doesn't describe the order of the checks. What happens if I combine two or more of these points (for example: temporary GLOBAL permission for 1 hour vs. temporary PLAYER permission for 1 day)?

Some suggestions for existing wiki articles

https://luckperms.net/wiki/Configuration#meta-value-selection-default and https://luckperms.net/wiki/Configuration#meta-value-selection

I think they need improved descriptions: Is max-homes an example-permission like max-homes.<number> or a meta value like a prefix / expiration time? Maybe first write a definition of meta value and a link to https://luckperms.net/wiki/Meta-Commands or similar would be useful.

https://luckperms.net/wiki/Configuration#apply-bukkit-attachment-permissions

I think you should reference the player.addAttachment(); method in the description to make it more clear what you mean with "are able to add their own »permission attachment« to players".

Ideas for the wiki articles

• A documentation of the calculation process as text or diagram.
• Splitting the https://luckperms.net/wiki/Advanced-Setup article in two sites: Advanced-Setup (= Shorthand Permissions, Regex, Wildcards) and Permission Calculation and sort both to "Features".

Support for multiple languages

(https://github.com/lucko/LuckPerms/wiki/Prefixes,-Suffixes-&-Meta)

I'm not sure how different Velocity is from BungeeCord in terms of installation, but I know that it has some major differences compared to Bungee in terms of API and configuration (i.e. it uses the TOML format and not yaml for the main config)

I open this issue, so that we could perhaps discuss this?
I think it would be worth considering making a separate section in the network installation guide, which explains the key differences between Velocity and Bungee, and perhaps also point out specific differences in configuration of LP, if there are any.

This line of hyperlink leads to nothing. Is this necessary?

For example, https://github.com/LuckPerms/wiki/blob/master/Developer-API:-Usage.md#the-basics-of-cacheddata. In the Obtaining PermissionData and MetaData you can see this line: MetaData metaData = user.getCachedData().getMetaData(contexts);. However in v5's API getCachedData()#getMetaData only accepts QueryOptions as an argument. Additionally, the Contexts class doesn't exist anymore. As a matter of fact, there's not even a MetaData class anymore! I believe that has been replaced by CachedMetaData.

It would be helpful if the wiki could be updated to accurately reflect the usage of v5.

Apologies if this is already being worked on, I don't mean to rush. Thank you :)