Quote from mbaxter:
"Vault should be returning the value as the actual in-game String, not the config String."

As it is right now, Vault return colorcodes directly from the PermissionsEX config in "&" format instead of "ChatColor." and so on. This doesn't work with some plugins. VanishNoPacket is one of those plugins. Don't know how to explain it further, but i guess you see the problem. If not, tell me and i'll try to explain it in more detail. :)

Hi @Sleaker!

My issue isn't confusion on handling color codes, just that the method being called in PEX by Vault isn't one that returns a colorcoded String. If PEX doesn't provide a method that returns the prefix in minecraft's chat format (rather than the current plugin-specific code) then it certainly isn't Vault's fault for not returning a String with sectionsign'd colors. Time to write a PR to PEX (and then one here to update the method call), I guess! :D

@mbax - Do other plugins return color coded strings? As far as I'm aware all the implementations return raw data values, generally this is the desired outcome, especially from Vault's perspective, as it's just passing through data values to be interpreted by plugins.

This is not an issue with Vault, Vault simply pulls the data that PEX provides there is no such thing as 'ChatColor format' when returning these values. It is up to the implementing plugin to handle data returned in a way that it wants it handled, and it is up to the implementing plugin (PEX) to return data as necessary. Vault will not do any data pre-processing as this is beyond it's scope.

@mbax
If a plugin developer is confused on how to handle color codes through Vault I suggest taking a look at my other project, WhosThere, which handles them just fine.
Here's some example code:
https://github.com/MilkBowl/WhosThere/blob/master/src/com/sleaker/WhosThere/WhosThere.java#L414

I think you misunderstood slightly. My assumption wasn't that plugins should be storing the section sign in their config, but that whatever method is utilized by vault to return a prefix should be utilizing that character.

I just dislike the idea of having to program in a guessing game to my plugin, rather than getting a consistent output.

Hmm, perhaps. All I'm saying is the prefix returned is whatever the server owner decided to setup. Not much else. If it's &2Admin then that's exactly what you're going to get back from the getPrefix. If the server owner actually tried to put in the special-characters for color codes, then you might get those. The problem is sometimes the special character codes can corrupt yaml files when edited manually, so most plugins I've worked with for prefixing will suggest owners use &# codes and then when getting the prefix they translate these into colors.

Yeah, YAML hates everything.

My hope was that if a permissions plugin was going to provide prefix functionality it would handle the processing on its own :(

If prefixes color coding are going to be defined on a per-prefix-supplier basis, would it not be better for the Vault to specify the format of the output? (eg. in the javadocs stating that it should return in &# format) That way any plugin querying Vault knows what it's getting instead of having to guess at whether it's about to receive a &# $# %# %colorname% etc format.

@Sleaker I honestly have no idea (Nor had I been particularly concerned, thus not even noticing this until now! :D) what plugins return. The problem with the idea of passing raw config data is that it's either forcing plugins to standardize on interpreting colors (When the concept of the section sign for color is somewhat going away internally within minecraft) from their configs, or resulting in a guessing game on the part of the plugins getting that data. The 'standard' of color in minecraft is using the section sign (ie ChatColor's toString()s), so to see a system outputting something else had me a bit puzzled.

The javadocs on prefix fetching within vault didn't particularly indicate any sort of non-minecraft color formatting requirements, which is why I initially pointed at vault as the issue. In case you're wondering where this whole thing came from :)

@mbax - that's because a 'prefix' is just a redirect link to a String info node in almost all implementations. I checked through the major perms, GM, PEX, ZPerms, Privs. and all of them handle it the same. The prefix value is a string that is simply returned back.
There isn't a very good way to handle parsing of the data in a standard format as it's not necessarily a chat prefix, this is it's primary use however, and depending on how a chat plugin handles the codes, they wont necessarily all be written the same. I've seen people use %COLOR% or $1 for example, rather than the old MC &1 codes. Generally though, I've found manually parsing & codes to be the most campatible method. Attempting to use the odd character method can cause character encoding problems with YAML (ASCII vs UTF-8) not handling things properly, and then breaking the whole perm config file.

From what I've seen of chat plugins (which is how this functionality was started) they were all programmed to use &# codes initially due to MC handling these by default (old chat format style). mChat, iChat, PEXChat, etc. I simply followed this formatting standard in my plugins.
Since the prefixes are simply K:V stores, and aren't parsed I don't think this issue can be resolved in either the permission plugin side, or the Vault side. it would be up to server owners to set their prefixes up with color-codes that MC automatically parses.

It could potentially be solved on the perm plugin side. PEX, for instance, says to use the & symbol. It could then provide a method that converts that prefix into MC color code, and Vault could then call that method.

Source: https://github.com/PEXPlugins/PermissionsEx/wiki/Basic-Permissions-Setup#wiki-prefixes

Or we could all just continue to use &# code's like we've been doing haha.

Perhaps, but I can't gaurantee that a server owner wont do something different or that other plugins aren't coded to handle them differently. For instance when I released WhosThere I explicitly told people that it will only use color codes the &# format. You could make this designation for users of your plugin.

The problem is, what if you have multiple plugins on the server utilizing Vault at once? Example list of plugins you could feasibly all have on at once:
Chat plugin (Whatever plugin you use for chat)
VanishNoPacket (Providing faked join/quit messages)
CraftIRC (Providing prefix/suffix on IRC)
dynmap (Er, maybe. Does it do prefix/suffix?)

That requires a standard, and the only standard available is section sign (ChatColor).