A player has the ranks Builder and Donor.

Builder has the prefix &b.
Donor has the prefix &a.

With PEX, the topmost group displayed is the 'primary' group used to display prefixes when there is no weight defined in the groups or when the weight equals other ranks when you don't want to force any rank prefix to take priority except staff positions.

PEX format.

  uuid-string-blablabla:
    group:
    - Builder
    - Donor
    options:
      name: player

If a user wanted to display the donor prefix instead of builder, you would simply just readjust their groups so donor is on top.

  uuid-string-blablabla:
    group:
    - Donor
    - Builder
    options:
      name: player

With LuckPerms, I can not seem to switch users between group prefixes when they have multiple groups and want to have one over the other. If I use the prefix priority system, prefixes will always be sorted in order and can't be swapped between ladders. When using the same prefix priority between all groups, it uses the meta of the first rank in alphabetical order.

Thus would it be possible to allow specifying which rank track to use for prefixes? Since as far as I know there is no set order of groups added to players and setting priority / weight force overrides prefixes to a defined order of ranks that can't be switched between.

Example idea;

Tracks;
(Track Member) Guest > Member
(Track Builder) Builder 1 > Builder 2 > Builder 3
(Track Donor) Donor 1 > Donor 2 > Donor 3
(Track Staff) Staff 1 > Staff 2 > Staff 3

Prefixes set on each group.
Guest (&8) > Member (&7)
Builder 1 (&b) > Builder 2 (&b) > Builder 3 (&9)
Donor 1 (&a) > Donor 2 (&a) > Donor 3 (&a)
Staff 1 (&d) > Staff 2 (&c) > Staff 3 (&c)

Allow specifying track priority so ranks in that track will always use the groups in that ladder as the priority prefix over other ranks, prioritized by order of rank in that ladder.
(Track Member - 4)
(Track Builder - 3)
(Track Donor - 2)
(Track Staff - 1)

Player has the groups Member, Builder 2, & Donor 3.

Player decides he wants to display his builder rank prefix over donor, so you change the track prefix used with something like /lp user <user> trackprefix <track>?

I totally understand the suggestion, but don't really like the solution you've proposed with tracks - it seems like a fairly complex way to solve the problem.

You're right, there's no way to define inheritance order - here are some solutions though.

• You can set the prefix directly onto the user using /lp user <user> meta addprefix ....

The downsides of this is that if you want to change the prefix, you'll need to make the change in multiple places - this is eased slightly by the bulkupdate command, however it's not ideal.

It also means you have to define the prefix each time you want to set an override.

• The other option is to go down the route of primary groups.

In my opinion, it makes sense to make use of this (in many cases redundant, since LP favours weights) system to define the order in cases were groups have the same weight.

I'll make that change now - I believe this will solve the original issue.

You can simply create two groups of the same weight, and give them prefixes of the same weight, and use the switchprimarygroup command to pick which prefix takes priority.

/lp creategroup donor
/lp creategroup builder
/lp group donor setweight 10
/lp group builder setweight 10
/lp group donor meta addprefix 10 "[Donor]"
/lp group builder meta addprefix 10 "[Builder]"

/lp user Luck parent add donor
/lp group Luck parent add builder

/lp user Luck switchprimarygroup donor

** donor prefix is used **

/lp user Luck switchprimarygroup builder

** builder prefix is used **

Thanks for looking into it. I did test setting primary group with the switchprimarygroup command but it didn't actually seem to switch the order of groups set on the player for me. I'll update dev builds and give it another try with the new commit.

@lucko The logic for switchprimarygroup seems to be inverted.

mibby's Parent Groups:
member
donor

/lp user mibby switchprimarygroup member

Displays the prefix of donor.

/lp user mibby switchprimarygroup donor

Displays the prefix of member.

name: member
permissions:
- meta.rank-ladder.Member
- prefix.10.&b
- weight.10

name: donor
permissions:
- meta.rank-ladder.Donor
- prefix.10.&6
- weight.10

Hmm, strange, ok, I'll look into it.

Interesting. So if I removed all rank values before migrating, would it choose the top-most group on the user as the primary? In the case of this user, these are the rank parameters on PEX before migration.

  Member:
    options:
      weight: '10'
      rank-ladder: Member
      rank: '5'
      prefix: '&b'
    permissions:
  Builder:
    options:
      weight: '10'
      rank-ladder: Member
      rank: '4'
      prefix: '&b'
    permissions:
  Premium:
    options:
      weight: '10'
      rank-ladder: Donor
      rank: '10'
      prefix: '&a'
    permissions:

Ok, should be fixed :)

Thanks. Seems to be working now @lucko. However I have a slight other problem.

When migrating from PEX, would it be possible to use the top-most set group as the primary group to keep the prefix group of users who already had their ranks shuffled around? Currently LuckPerms just seems to set the first group in alphabetical order as the primary group.

i.e.

PEX user.

  e44f4022-7aea-4eb2-87cc-24880df45ab1:
    group:
    - Premium
    - Builder
    - Member
    options:
      name: Panda_girl101

How LP migrated the user.

uuid: e44f4022-7aea-4eb2-87cc-24880df45ab1
name: Panda_girl101
primary-group: Builder
permissions:
- group.builder
- group.member
- group.premium

This means anyone who has both a donor rank and a builder rank (or other ranks that come first in alphabetical order), the builder prefix would be displayed over what they had before since group weight / prefix priority is going to be set the same to allow switching. Whereas before, I always had the donor rank displayed on top with the exception of allowing others to switch to their builder prefix instead if they wanted to show it off.

The PEX migration determines a primary group by selecting the parent with the lowest rank value, checking in the order returned (which is assume is how it is in the file).

Should be fixed by that commit.

@lucko Seems migrating without any rank set in PEX does correctly set the primary group when using yaml flatfile database. However if you are using mariaDB when migrating, the primary group seems to get set to 'default' with the parent groups setting to what groups you had before. So works with flatfile migration, not with sql migration.