LibCustomNames support

[mrbuds]

Add support for https://github.com/Jodsderechte/LibCustomNames
I think Jods addon needs a few reviews from addon authors before merging this to be sure interface isn't going to need too much changes

[Jodsderechte]

i basically added the whole set of available UnitName functions incase they are needed in certain spaces https://github.com/Jodsderechte/CustomNames/blob/main/README.md

[InfusOnWoW]

There's actually already a sort-of standard for custom names in the role playing addon community, apparently the common protocol is this: https://github.com/Total-RP/Total-RP-3/wiki/Mary-Sue-Protocol

I haven't looked to deep into it, the protocol is a bit suboptimal for our use cases and the whole functionality is obviously beyond what we need. But maybe we should investigate that a bit.

[Jodsderechte]

I was trying to look into actual implementation of this but trying to find the actual doc for that had me running in circles. i eventually found https://github.com/wow-rp-addons/LibMSP which seems to be the most up to date version. However their wiki is just a parsed version of https://moonshyne.org/msp/ which didn't help me in the first place. However i feel like my database would explode trying to save all the names of the people you were randomly in group with/moused over. I'd also need to add options to turn off that nicknaming which kinda defeats the purpose of the "lib" (thats not a lib) to be very lightweight. It also seems like you can only ever have one addon active that is implementing libMSP or they create conflicts https://github.com/wow-rp-addons/LibMSP/wiki/Original-Mary-Sue-Protocol-documentation#addon-conflicts-and-how-to-avoid-them but i haven't checked that in detail. Maybe contacting those rp addon devs to implementing the saving of names in the databse would be the better bet.

[InfusOnWoW]

As far as I undestood, there can be multiple addons requesting name information, but only one responding to name request information. Which is a pretty reasonable.

With the library/protocol you can request the nickname for a given player/realm but that's an async method, which is a bit problematic for WA's usage of unit formatting functions.

[Jodsderechte]

Also %name text replacements don't work yet unsure if that is something you want to support. Same for condition -> UnitName/Realm and Trigger -> UnitName/Realm (if unit exists ofc. Could also be added for combatlog triggers but you'd need to add Realm if you want to GetName) (either add both or none i guess). I also changed Lib.Get() to also allow for single name fetching (it will assume realm = GetPlayerRealm())

[mrbuds]

Also %name text replacements don't work yet unsure if that is something you want to support. Same for condition -> UnitName/Realm and Trigger -> UnitName/Realm (if unit exists ofc. Could also be added for combatlog triggers but you'd need to add Realm if you want to GetName) (either add both or none i guess). I also changed Lib.Get() to also allow for single name fetching (it will assume realm = GetPlayerRealm())

I think having only text formatters support, without touching aura's triggers & loading, is good enough at least for now
It also add helper functions to your addon for custom coded auras for complex needs

[Jodsderechte]

Did some ingame testing it seemed to work without any issues on retail: do note i do not have classic or tbc installed so can't adhere to how it works there.

Regarding the MarySue protocol i talked to meo here about it and came to the conclusion it's not realy sth worth adding right now.

Adding it would provide 2 issues.

1. since as infus already mentioned requesting data of MSP is async would require adding callbacks to the unit formater.
2. the idea for CustomNames was to give the player controle over how other players appear on his screen. Using information others can set themselfes would result in a mess like with DetailsNicknaming which wasn't the goal.

That being said adding a plugin later on to CustomNames to allow it to fetch info of the MarySue protocol would easily be achievable and be the cleaner solution (as otherwise you'd need to atleast be able to toggle using that info anyways)