Suggestion: support for multiple prefixes/suffixes

[AggerTV]

Hello, could support for multiple prefixes be added?
Ex. my builder has 2 ranks. Builder and mod, but it will only show either the builder ranks's prefix, or the mod rank's prefix, so could support for both of the prefixes to be shown, maybe be added?

[zml2008]

That's something that would be added in the chat plugin, not in PEX.

[mdcfe]

I think this is asking for a system similar to LuckPerms' prefix and suffix stacking system, whereby you can combine prefixes or suffixes defined in groups on different ladders/tracks into a single prefix or suffix. On Bukkit, Vault's Chat interface doesn't appear to expose any way to access multiple prefixes or suffixes on a user, so this might be worth considering?

[zml2008]

What it really sounds like multi-prefix is used for is to change how options are inherited -- rather than overriding prefixes, they're asking for prefixes from the user and their groups to be concatenated. That is supported in Vault -- you can get the player's own prefix, plus the prefix of their groups. Because you don't have direct control over whether inheritance is handled through Vault, you'd want to deduplicate them, but it is very doable to show multiple affixes without specific permissions support.

[mdcfe]

From the OP's question it seems as though they want to concatenate prefixes from multiple groups that a single user is part of. LP's stacking settings allow for this, with a set of rules that control how prefixes/suffixes are combined and returned as the player's prefix.

Would there be any interest in adding a similar stacking system in PEX 2? While chat formatting plugins certainly could request prefixes/suffixes for multiple groups, it feels clunky to make chat formatting plugins need to be aware of each group that was defined - I can't think of a particularly sane way of doing this that on the formatting plugin side. (For example, right now EssentialsX Chat tries to retrieve the player's affix then tries their primary group's affix - we'd need to add a lot more conditions and complicate our config to build in support for combining non-primary groups' meta on our side.)

[AggerTV]

I'm confused, is this something that is dorable? And if it is, then why not add it?

[zml2008]

I'm sort of reluctant to give this special treatment in PEX -- it would mean inheritance would work differently for one option from every other option, and it would pose some interesting problems with the crossover between context-specific and global prefixes -- like if a player has a global prefix and one that just applies in the nether, should those stack or override? if both the user and the users groups have global and world-specific prefixes, how should those stack?

Either way, because Vault is a fixed API, adding option stacking to PEX would split the configuration of affixes up even more, and make permissions plugins do more data processing than they should. I don't really see how a simple implementation would be particularly complicated -- the scope of EssXChat is more limited than the scope of PEX, so how about something like:

// Where `chat` is an instance of 
public @Nullable String getPlayerInfoStacking(String worldName, OfflinePlayer player, @NonNull String option) {
    final Set<String> values = new LinkedHashSet<>();
    final @Nullable String ownValue = chat.getPlayerInfoString(worldName, player, option, null);
    if (ownValue != null) {
        values.add(ownValue);
    }
    for (String groupName : chat.getPlayerGroups(worldName, player)) {
        final @Nullable String groupVal = chat.getGroupInfoString(worldName, groupName, option, null);
        if (groupVal != null) {
            values.add(groupVal);
        }
    }
    final StringJoiner joiner = new StringJoiner(" ");
    for (String value : values) {
        joiner.add(value);
    }
    return joiner.toString();
}

[mdcfe]

Formatting plugins could just append every affix the user has, sure, but that would lead to nonsense chains like [Admin] [Mod] [Builder] where multiple groups are inheriting each other, which isn't particularly obvious to users who might expect a higher priority group's affixes to take priority. LP allows you to append the highest priority affix per track - so a world-specific prefix could be in a separate group on a separate world track that is inherited by the default group, and so long as both the world track and the default track are included in the stacking settings, both affixes would be combined.

To implement this on the chat formatting plugins would need to contain their own entire affix stacking settings, and then these settings would need to be replicated across any other plugins that want to display affixes (like a placeholder API, leaderboard plugin, tablist plugin etc) in order for it to be consistent across a server. On the other hand, permissions plugins like PEX are already aware of their own ladders/inheritance systems, and it's far easier for a user to configure stacking once in the permissions plugin than to do it several times. (Also to my knowledge Vault doesn't expose ladders, so the only ways I can see this being done are by having specific hooks into each permissions plugin to read their ladders/tracks, which is doable but undermines the point of Vault.)

Ultimately if including stacking in PEX doesn't sound beneficial to users then fair enough. I'm not sure whether more complex chat plugins have alternative solutions or if LP's meta stacking is the norm, but right now for simplistic plugins (I can think of EssX Chat and VaultChatFormatter on Bukkit and gChat on Bungeecord), this is what we rely on for users who want to set up multiple contextual prefixes/suffixes through their permissions plugin.

edit: turns out you should finish writing things before posting, who knew?