Type of bug

Data loss, Compatibility issue

/ess dump all output

https://essentialsx.net/dump.html?id=22064ddb792f49ffba2275d2344050af

Error log (if applicable)

No response

Bug description

I am using the Towny plugin which uses the EssentialsX economy. The problem I have is that cities with non-Latin letters and the same name length have a common balance when they shouldn't. The developer said that this is due to the way EssentialsX stores balance data. As far as I understand, all characters not used in minecraft nicknames turn into one replacement, for example "ぁい" to "??" or "пр" to "??". Image from towny discord server.

Steps to reproduce

1. Install Towny, EssentialsX, Vault
2. Start server and create 2 cities, for example, with Cyrillic names of the same length
3. If you then deposit money in 1 city, it will be in another. This occurs due to a collision.

Expected behaviour

each city must have a separate balance

Actual behaviour

Due to lack of support for some characters, there is 1 bank account in 2 cities

Additional Information

Towny version - 0.100.2.0
EssentialsX - 2.20.1 (stable)

Not an EssX maintainer, just some guy.

For a little backstory, Vault is the lovely system that allows plugins to share economy data without having to write a bunch of plugin-specific stuff. Vault's economy API is, by their clear documentation, explicitly meant for Player economy data. It refers to the names of account holders as playerName and, for more than ten years, has nudged plugin developers to not even use the methods that take a name but rather to use what's called an OfflinePlayer object: A representation of a player (name and uuid).

From what I can tell, Towny sends the town's name as if it's a Minecraft player's name. This means your town names, containing Cyrillic characters, are being sent as invalid Minecraft account names. If not converting this name (which I suspect is part of a system for dealing with invalid input from various places), another valid response by EssX would be to not track any econ data at all for these invalid names.

If Towny sent OfflinePlayer objects with a consistent UUID based on the town that EssX (and other economy plugins) could store and track the UUID as would be a reasonable approach for the last decade (since 2014 when UUIDs were introduced with the idea of usernames changing), I can see this being an EssX issue to fix. As it stands, though, this looks like Towny is making a critical mistake.

I made a branch a few months ago for Towny that makes it send proper OfflinePlayer objects to vault, although because I got busy with some other things I unfortunately forgot. I'll take a look at it again to hopefully fix this decade old issue.

Is there any UUID version that's preferred for marking that we want to create an npc account? I saw that both v2 and v3 uuids work, so I was thinking of just editing the version byte or generating a v3 from the stringified uuid, or is there no real difference?

Besides that, I also don't think there's any issue here for EssX to fix, so this issue should probably be closed.

Not an EssX issue - closing as this is something Towny has to fix.