Is there a way to only inherit group permissions and not group prefixes/suffixes as well?

Here's an example:

  Group1:
    options:
      prefix: '[Group1] '
    permissions:
    - perm.permission
  Group2:
    inheritance:
    - Group1
    options:
      suffix: ' [Group2]'

If I now assign the group "Group2" to a user, the chat would end up looking like "[Group1] User [Group2]: Message" instead of "User [Group2]: Message" which i initially wanted.

Unfortunately PermissionsEx is currently unmaintained and no further updates are planned. Because of this, all pull requests are being closed. If you are looking for an actively maintained permissions plugin, take a look at LuckPerms. It is compatible with major server platforms and can import data from PEX.

A couple of things to keep in mind when using PEX:

• The display of Prefixes/Suffixes in-game is handled by a chat management plugin; PEX just gives you a place to store that information.

• PEX doesn't allow a group to "inherit" another group's Prefix/Suffix, but a user in multiple groups will display the Prefix/Suffix of the latest group they were added to unless you use weight: values. Take a look at this example file. If a user on this server were in the "Member" and "Admin" group, the chat management plugin would display the "Admin" group's prefix and suffix because the "Admin" group has a more powerful weight: value— the lower the number, the more powerful the group is.

Does that help?

That's pretty weird since I have the same problem even when using the "weight" system... I'm using EssentialsChat, butI don't think it's causing this problem since I'm only displaying player's "displayname" in chat.

It's probably a config issue then.

The {displayname} variable in EssentialsChat and EssentialsXChat is actually prefix+username+suffix, and would still conform to the "latest group" thing I mentioned, until weights are assigned to the groups.

If you'd like to Pastebin your complete Essentials\config.yml, your complete PermissionsEx\permissions.yml, and give me a specific user that's being problematic, I can look through everything to find the problem.

Also, it's very important to be specific— are you using "EssentialsChat" or "EssentialsXChat"? The files required for each plugin are different; "Essentials" was discontinued at Minecraft 1.8.0 and "EssentialsX" was the continuation of the "Essentials" plugin (up to Minecraft 1.12, so far), specifically for Spigot servers.

Okay, thanks! Yeah, forgot to specify that I'm using EssentialsX, with EssentialsXChat. Build 472 to be exact.

Pex permissions.yml: https://pastebin.com/QAtBuLWV
EssentialsX config.yml: https://pastebin.com/0hEUDgX6

Ok, looks like the EssentialsXChat hasn't been properly configured.

Take a look at this excerpt of my example config.yml file. There are a few changes you'll need to make to your file. With this setup, you'll be able to more directly control how your groups' chat is displayed.

Line 666 of your file does the same thing, in a simpler way, and you can keep that method if you prefer. I expect neither method would function correctly because of the lines that were "ignored" by EssentialsX in the top half of the "excerpt" I linked above.

With the top-half lines corrected, and given your permissions.yml file, your chat should look like this:

    [Prefix] AfkF24: message

Your color codes between the config and permissions files need to be fine-tuned. If I'm reading everything correctly, the config wants to begin with gray (&7), then the prefix (but the pex file changes the color to pink with '&d[Prefix]' in the permissions.yml file), username (still pink because the prefix changed the color to pink), suffix (still pink), then the config changes the color to dark gray (&8) for the double-arrow character (») which may not be usable in Minecraft (test it), and back to gray (&7) for the text a user sends. And keep in mind that dark colors tend to be hard to read on dark backgrounds.

Many edits in my previous comment.

I've changed the "top section" of my Essentials config.yml values according to your example, but I still have the exact same problem... http://prntscr.com/fl7msm

Since I've been using GroupManager for 2-3 years now, I'm pretty new to PEX and I'm trying out the plugin on my test server, so colors aren't a big deal at the moment.

Can you show me, exactly, what is being displayed in-game? Got it.

Are you using any other plugins at the moment? Some plugins, like Multiverse and Towny, also have built-in chat management features that can cause some problems.

Using Vault, EssentialsX with EssentialsXChat, PEX, and other plugins that don't affect the chat by any means. I've linked you the picture in my previous comment.

What are the plugins, though? I'd never have expected a plugin that controls teleporting between worlds or a plugin that makes cities to control chat too. ;-)

You're literally only in one group, as far as PEX and EssentialsX are concerned, so something else is doing the naughty here.

Damn, okay.. Haha

] Edit by Stormbow: redacted the plugins list, for sever privacy. [

Check the Factions plugin config. Is there anything chat related in there? (I've never used it on my server.)

I've actually just started the server with only EssentialsX, EssentialsXChat, Vault and PEX loaded, and the same issue occurs

Here's something interesting though: If I set the suffix of the group Rank2 to be something like "&r" then everything works fine

groups:
  Default:
    options:
      default: true
      prefix: '&7'
      weight: '10'
    permissions:
    - essentials.kits.Color
  Rank1:
    options:
      suffix: ' &c[Suffix]'
      weight: '9'
    permissions:
    - essentials.fly
  Rank2:
    inheritance:
    - Rank1
    options:
      prefix: '&d[Prefix] '
      suffix: '&r' #HERE
      weight: '8'
    permissions:
    - essentials.kits.Notch
    - permissions.*
schema-version: 1
users:
  f603b6d2-6f8b-3b28-8544-0ec35435add6:
    group:
    - Rank2
    options:
      name: AfkF24

http://prntscr.com/fl7ski

I hate to say this— and I've said this less than 5 times in the last 5 years or whatever that I've been the official PEX guru —but after all we've talked about, I have no idea what is causing this problem.

Going back to at least Minecraft 1.6.4, PEX hasn't allowed a user in one group to to "inherit" the prefix/suffix of another group. (He may not reply here, but @zml2008 is the programmer for PEX and he can confirm or deny this.)

Looking at this issue, from the top, we have one user, in one group, displaying the prefix of one group and the suffix of another, seemingly inherited. To the best of my knowledge and based on all the years that I've used PEX (which goes back a couple years before I became the guru), inheritance is strictly tied to permissions; it can be either global, world-based, or a combination of the two, but never included prefixes or suffixes.

I am, unfortunately, stumped.

The only other thing I can think of is give the group this option:

    suffix: ''

(That's 2 apostrophes. That gives the group an "empty" suffix.)

http://prntscr.com/fl7ski

That works, too. :-)

Believe it or not, I've actually tried to set the suffix to suffix: '' , but that displays the suffix from the inherited group again... mind blown So "&r" is the only way.

That's also a very non-PEX-like thing. O_o?

I'm about to say this must be a server host issue; maybe they're giving out some bogus files. (Your server's startup log could confirm or deny this. If you want to copy the entire mess, from the moment the server starts, until text stops printing to the console and you see a message similar to "Done!" to Pastebin, I can take a look at that for you too. Many server hosts give out the wrong versions of Essentials files because they don't know the difference between "Essentials" and "EssentialsX".)

I'm actually hosting the test server on my PC, locally, so there probably aren't any issues realted to that stuff
And for the startup logs, everything looks fine, so..

Anyways, thank you for your time & assistance! Cheers! :)

You're welcome.

I'm going to leave this open and tag it over to @zml2008 to see if he can give us any additional insight as to what's going on here.