Trinitycore: [7.2] Addons communicating with other clients

[shocky4]

Description:
I've noticed a few addons aren't communicating with other clients/players like it should. Best example is Total RP 3, it doesn't seem to be communicating with other players clients.
Here's how the tooltip should look when you hover over somebody that has the addon, and the bar when you click the player:
https://i.imgur.com/NTGoQun.jpg

Current behaviour:
Currently, when you hover over a player that has the addon, nothing happens, it's just the standard tooltip, and no bar from the addon when you click the player.

Expected behaviour:
It should show the tooltip, as well as the players version of the addon and all their information and customization that they put in their side of the addon.

Steps to reproduce the problem:
2 players have the Total RP 3 addon, if you hover over the player or click them, you don't see what you should with the addon. It affects other addons as well.

Branch(es):
Master

TC rev. hash/commit:
Both the last 7.1.5 commit: https://github.com/TrinityCore/TrinityCore/commit/886e9e839b304b7567dd655e4fa3afb2251c96ca
And latest 7.2 commit: https://github.com/TrinityCore/TrinityCore/commit/a316ba576b4c5316da2960340c4e05274e19b258

TDB version: TDB 720.00

Operating system: Tried on both Windows 10 and Debian 8/Linux

[MrSmite]

This might be a bug with the addon itself:

https://mods.curse.com/addons/wow/total-rp-3?comment=886
Posted 5 hours ago
Huh...the scan for roleplay doesn't detect anyone anymore..in fact it hasn't for a few updates...what's happened?

If it's not that then there may be some relevant info here: Known issue with private servers

[shocky4]

Hmm I don't think it's the addon itself since it works fine on retail for me when I tried on 2 separate accounts like the image, but doesn't seem to work on the latest Trinity. But I didn't know about the info you linked, that's informative

[MrSmite]

But I didn't know about the info you linked, that's informative

Yeah, sorry I don't have a working 7.x client / server yet so even though I understand LUA, I can't do any real debugging to see if it is the addon itself.

[Pixel-Pirate]

TrinityCore don't provide support for a problem with specific addon

[gmillerd]

When you say it doesn't work on the latest tc, when did it last work in master?

I assume that you are running v1.2.8? There addons that are integrated with it have a lot of requirements, none of these are having issues? Does the previous version work? What channels are you subscribed to?

Note there are a number of people that cannot detect other players on curse right now. I would work the addon's forum, it clearly has support and people with the same challenge.

[shocky4]

I've tried from v1.2.0 to v1.2.8, they all have the same issue.
I'm unable to use the addon by itself as it doesn't recognize Trinity's realm function, so I have to use a custom addon for 'GetRealmName()' to work with 'UnitFullName'.
On the master branch (both the last 7.1.5 and latest 7.2), it has the same issue. I enabled debugging on the addon, but it seems to be stuck on broadcasting to the addon channel. It's not working on Legion but I haven't tried the last WoD branch since I can't seem to get any WoD clients working to be able to test it. I'm not sure if it's just this addon or if it affects any others.

[DDuarte]

No need for confirmation in 7.1.5 or WoD, if it is not working in current master (7.2.0) then it needs to be fixed.

I'm unable to use the addon by itself as it doesn't recognize Trinity's realm function, so I have to use a custom addon for 'GetRealmName()' to work with 'UnitFullName'.

Do you have more info about this? Does your realm name have spaces in the name? Can you test with a realm name with no spaces nor special characters outside of A-Za-z?

---

P.S Created a new label, Sub-Addons for issues related to addons.

[shocky4]

The realm name is simply 'trinity', I've tried different realm names with no luck too.
With the addon simply on it's own, you get this error: https://i.imgur.com/RBJ2E7l.png
With the custom addon to show the realm name, the addon loads and there's no error, but here's the addon debug log: https://i.imgur.com/z0mq0CQ.png

It simply spams 'Step 2: Connected to broadcast channel: xtensionxtooltip2. Now sending HELLO command.' around 6-7 times before stopping. I've also changed the addon channel name without any numbers but still the same thing. I've tried fixing it myself since I have development experience but to no avail.

I enabled debugging on retail to see what I get, and I get this: https://i.imgur.com/m0RpBaK.png
It seems to go to 'Step 3: HELLO command sent and parsed. Broadcast channel initialized.'.

Edit: I did some research and seems like it was a problem in WoD too on Trinity, here's an issue somebody posted about the same thing: https://github.com/TrinityCore/TrinityCore/issues/14949

[DDuarte]

I suggest start the sniffer (or use the worldserver.conf sniff option) and look for suspicious data in the chat addon related messages. Also check if the opcodes are enabled in Trinity and that the structure of them exists.

[shocky4]

I've checked that, the opcodes are the same but the broadcasts are different, the SMSG_CHAT parse is different to retail, not showing MSP (Mary Sue Protocol) at all, and the whisper addon opcode is only showing the same thing in the text on Trinity, but shows all the correct details in the parse text and prefix on retail. Also trinity is only showing the MSP (Mary Sue Protocol) once in the whisper addon opcode after it tries to connect to the broadcast channel, then nothing, but on retail it shows several times communicating with the other clients.

I've checked the structures required for it and they all exist and are enabled.

[MrSmite]

Have you ever used this addon with Trinity successfully before? Because in your debug log the addon knows you're on the trinity realm:

[TRP3] The profile trinity - Telenus is loaded

It's either saved to your SavedVariables from an old core where it worked or if this is the first time you've used it then the addon is wrong about:

Cannot have realm name information

EDIT

After looking at the LUA, I still think the addon seems to be the problem:

Line 95 as reported in the debug log is:

    local fullName, realm = UnitFullName("player");
    assert(realm, "Cannot have realm name information !");

The interesting thing is how the wiki describes UnitFullName():

http://wow.gamepedia.com/API_UnitFullName

String - unit's realm of origin, e.g. "TarrenMill", if different from the player's own, or no value if the same as the player's own realm

but then they contradict it with:

This function is equivalent to UnitName if called with any other unitId than "player". When called with "player" as the argument, realm is always returned.

and then this thread indicates it actually does not return the player's realm.

So it's quite possible that either UnitFullName() is described wrong in the wiki or it is actually broken in its implementation by Blizzard.

Also, I don't understand why the addon developer did that. He already has the realm name here:

TRP3_API = {
    r = {},
    formats = {
        dropDownElements = "%s: |cff00ff00%s"
    },
    globals = {
        player_realm = GetRealmName(),

so instead of asserting on realm, he should simply be using player_realm and discarding realm

    -- MrSmite - Fix problem with realm being NIL

    local fullName, realm = UnitFullName("player");
    -- assert(realm, "Cannot have realm name information !");
    assert(TRP3_API.globals.player_realm, "Cannot have realm name information !");

    -- TRP3_API.globals.player_realm_id = realm;
    -- TRP3_API.globals.player_id = fullName .. "-" .. realm;

    -- MrSmite - Note: player_realm_id and player_id are not defined in TRP3_API.globals and may be created
    -- globally (_G) by the LUA engine after assignment. This will fail if Blizzard ever implements
    -- strict mode for LUA which requires declaration before assignment
    TRP3_API.globals.player_realm_id = TRP3_API.globals.player_realm;
    TRP3_API.globals.player_id = fullName .. "-" .. TRP3_API.globals.player_realm;

[Shauren]

@MrSmite no, GetRealmName() returns the name in unnormalized form (with spaces) but UnitFullName gives you the normalized name

[shocky4]

@MrSmite I've checked the coding for the addon itself, I understand where you're coming from. I've not used it with Trinity correctly before without this hackfix addon, I've cleared the Cache and WTF folders previously too. The only way I got it to work with Trinity is with a custom addon using this code:

local factionGroup, factionName = UnitFactionGroup("PLAYER")
function UnitFactionGroup(unit, name)
    return factionGroup, factionName
end

UnitFullNameOld = UnitFullName
function UnitFullName(unit)
    return (UnitFullNameOld(unit)), GetRealmName()
end

It's an addon I found that allowed it to work with it, which is how the addon was working picking up the realm, but the debug shows the addon having an issue getting a response from the channel addon opcode.

[DDuarte]

@shocky4 the realm related errors should be fixed by Shauren's commit linked above. Can you test?

[shocky4]

@DDuarte Just tested the latest commit, that fixed the realm problem, it works on it's own now without the hackfix addon, just have to say you do an amazing job @Shauren.

The only remain issue is it being stuck on 'Step 2: Connected to broadcast channel: xtensionxtooltip2. Now sending HELLO command.'.
I did some checking and when you highlight/click a player, it communicates with them and back again using this code: https://pastebin.com/710nMM77
It's from the file 'register_exchange.lua' from the addon, this code is what allows the communication (I'm sure anyway, as it shows up in the debug on retail when highlighting someone with the same addon): https://pastebin.com/g98SNHTJ

I sniffed both Trinity and Retail and compared them, I did the exact same thing on both, logged in, highlighted/clicked the other player with the addon then logged out, here are the parses of the addon channels, I cut the rest out so it's only the addon opcodes:
Trinity sniff: https://pastebin.com/e8iK3YPR
Retail sniff: https://pastebin.com/Nbki5WuV

It seems to start off the same, but then SMSG_CHAT is completely different between them, I've tried figuring out why but I've been unsuccessful.

[DDuarte]

Solid research, @shocky4, great job :)

I wonder if it is related to this piece of code in HandleChatAddonMessage: https://github.com/TrinityCore/TrinityCore/blob/master/src/server/game/Handlers/ChatHandler.cpp#L512-L514

prefix is never used when the type is CHAT_MSG_CHANNEL.

Suggestion: Add prefix argument to Channel::Say and send prefix in the two packet->Initialize() calls of Say.

This was an oversight of 7cc49aa0ab4b86260b0844b924f787ac63783c6e and d02f4da35540385d1803b52cc1015e9ea1b7a7cb

[shocky4]

@DDuarte I think you're right, I completely missed that part of the code, I didn't notice CHAT_MSG_CHANNEL under that function, I was focusing on SMSG_CHAT. I'll give that a try

[MrSmite]

Just curious, your retail sniff has two ServerToClient responses (SlashCmd: 7 (whisper) and SlashCmd: 17 (channel)) but the Trinity sniff only has one (SlashCmd: 17 (channel)).

Is it because you didn't paste the whole sniff or is it because of what @DDuarte mentioned above? It seems like Trinity didn't process the case CHAT_MSG_WHISPER:

[shocky4]

@MrSmite That's the whole sniff of the addon opcodes relating to the issue (I only had that addon enabled), the only parts I left out were all the other opcodes not related to it.

I noticed the same thing when comparing the parses, which is why I thought it may have been something with SMSG_CHAT, because it wasn't showing the proper structures, like the Language part Trinity parse of SMSG_CHATis 0 (Universal) instead of 255 (255) like the retail one (255 is the addon Language if I remember right).

The Trinity sniff only had 1 SMSG_CHAT, the retail sniff had more afterwards (which I assume is the communication in some way). Retail also had more SMSG_CHAT_MESSAGE_ADDON_WHISPER parses, and showed MSP in the Prefix, Trinity's parse of that opcode all had the same text repeating, and no MSP in the Prefix. If you notice the third SMSG_CHAT parse on the retail sniff, it shows Prefix: MSP. MSP isn't working on Trinity.

[MrSmite]

Trinity's parse of that opcode all had the same text repeating, and no MSP

I noticed too that the retail sniff for SlashCmd: 17 (Channel) had:

Addon Message Prefix: RPB1

but the trinity one had:

Addon Message Prefix:

MSP isn't working on Trinity.

In case this might help, here's some info on MSP packets the client is sending (as linked from the TRP3 implementatin page):

https://moonshyne.org/msp/

Specifically: MSP uses the SendAddonMessage() prefix "MSP" to denote MSP communication. As packets, especially responses, can get longer than the 255 bytes that you can send in a single SendAddonMessage() message, multi-part messages are handled in the same fashion as AceComm3 does: If the packet is more than 255 bytes, split it into 255 byte parts, and use prefix "MSP\1" (where \1 is a 0x01 byte) for the first part, "MSP\2" (where \2 is a 0x02 byte) for subsequent parts (if there are 3 or more), and "MSP\3" (where \3 is a 0x03 byte) for the last part. Upon receiving the final part of a multi-part message chunk, the receiver should concatenate them together and treat them as a single message.

[DDuarte]

We only need to worry about sending the proper ptefix. Once that's done the other messages after the first one should also start appearing.

[Syloxus]

@DDuarte I followed your advice, I added the prefix argument to Channel::Say, it worked and the addon now gets a response back in the debug.
Unfortunately there's another issue, in the parses, whilst the Language in SMSG_CHAT has changed from 0 (Universal) to 255 (Addon), the SlashCmd is staying as just one SlashCmd: 17 (Channel), where it should be SlashCmd: 17 (Channel) then several SlashCmd: 7 (Whisper) from SMSG_CHAT after it, like on the retail parse.

I sniffed again and got some more info:
Trinity: https://pastebin.com/mZLAy3dR
Retail: https://pastebin.com/Mepukua8

If you compare, there's a lot more SMSG_CHAT going on with the retail parse than on Trinity, the Trinity one has no Whisper in SlashCmd. I didn't leave anything out of either parses, those are everything relating to the addon/protocol.

[DDuarte]

I guess you could Pull Request the suffix changes and later on figure out what other changes are needed.

[MrSmite]

Maybe not relevant but why is there no CMSG_CHAT_ADDON_MESSAGE_WHISPER here?

https://github.com/TrinityCore/TrinityCore/blob/master/src/server/game/Handlers/ChatHandler.cpp#L417

void WorldSession::HandleChatAddonMessageOpcode(WorldPackets::Chat::ChatAddonMessage& chatAddonMessage)
{
    ChatMsg type;

    switch (chatAddonMessage.GetOpcode())
    {
        case CMSG_CHAT_ADDON_MESSAGE_GUILD:
            type = CHAT_MSG_GUILD;
            break;
        case CMSG_CHAT_ADDON_MESSAGE_OFFICER:
            type = CHAT_MSG_OFFICER;
            break;
        case CMSG_CHAT_ADDON_MESSAGE_PARTY:
            type = CHAT_MSG_PARTY;
            break;
        case CMSG_CHAT_ADDON_MESSAGE_RAID:
            type = CHAT_MSG_RAID;
            break;
        case CMSG_CHAT_ADDON_MESSAGE_INSTANCE_CHAT:
            type = CHAT_MSG_INSTANCE_CHAT;
            break;
        default:
            TC_LOG_ERROR("network", "HandleChatAddonMessageOpcode: Unknown addon chat opcode (%u)", chatAddonMessage.GetOpcode());
            return;
    }

    HandleChatAddonMessage(type, chatAddonMessage.Prefix, chatAddonMessage.Text);
}

It would seem that with the missing case above, HandleChatAddonMessage() would never be called for whispers and the following never executed:

https://github.com/TrinityCore/TrinityCore/blob/ecda7cef7f93fc01b7a6cd6341e33bb8c7668724/src/server/game/Handlers/ChatHandler.cpp#L473

        case CHAT_MSG_WHISPER:
        {
            if (!normalizePlayerName(target))
                break;

            Player* receiver = ObjectAccessor::FindPlayerByName(target);
            if (!receiver)
                break;

            sender->WhisperAddon(text, prefix, receiver);
            break;
        }

[Shauren]

No, CMSG_CHAT_ADDON_MESSAGE_WHISPER is handled by WorldSession::HandleChatAddonMessageWhisperOpcode

[Syloxus]

Shocky4 here, this is my main account. Shauren is right, the addon opcodes for channel and whisper and handled separately from the others.

I added a pull request fixing the communication issue with the channel opcode, but the client still only requests from the other player/client, but doesn't receive anything back (through CMSG_CHAT_ADDON_MESSAGE_WHISPERand SMSG_CHAT).

[MrSmite]

No, CMSG_CHAT_ADDON_MESSAGE_WHISPER is handled by WorldSession::HandleChatAddonMessageWhisperOpcode

Ah, that's what I get for trying to browse the surce on github.

[Syloxus]

The addon gets a response back now from the broadcast channel, but still only getting one SMSG_CHAT which is SlashCmd: 17 (Channel), nothing after that, unlike retail where it communicates through SlashCmd: 7 (Whisper) in SMSG_CHAT as well as the addon whisper opcode afterwards. Like I said before, the client is requesting information from the other player's client, but isn't getting any response back. I have no idea what the issue could be

[MrSmite]

Like I said before, the client is requesting information from the other player's client, but isn't getting any response back. I have no idea what the issue could be

Are you sure the other client has the addon installed properly? Maybe your client isn't getting a response because it's not being generated on the other cient in the first place. Maybe the other client is blocking whispers or something?

[Syloxus]

Are you sure the other client has the addon installed properly? Maybe your client isn't getting a response because it's not being generated on the other cient in the first place. Maybe the other client is blocking whispers or something?

I've been using the same addon folder and the same client for both accounts, even tried separate folders, different addon versions and even 7.1, all with the same problem.

I know of certain 'servers' that have the addon working on WoD/Legion, but they don't use the addon broadcast channel from what I've debugged, I don't have a sniffer for it though so I can't see how it operates. I'm unsure whether the problem is addon opcode related or SMSG_CHAT related.

[Syloxus]

I've figured out why it's not working, well TRP3 in particular (maybe MSP too). It's reading retail and Trinity differently. On retail it's reading just the player's name without the realm suffix (so it doesn't work with cross realm players), but on Trinity, the player's name and realm suffix is being read together instead of just the player's name (so instead of reading 'Player', it's reading 'Player-Trinity'). At least that's the reason why nothing is getting communicated between TRP3.

[Syloxus]

I forgot to mention. On Retail, realms that aren't cross realm (e.g. your character on the realm Kazzak), the realm suffix isn't added to the player name (it would be Syloxus instead of Syloxus-Kazzak), but on Trinity, it is (like when you shift click their name, it adds the realm prefix to it, like: Syloxus-Trinity).
I'm not 100% sure how to remove the realm suffix from player names regarding anything to do with addon/chat message opcodes (or even player names in general in the who/channel). It's been a while since I've worked with Trinity and I'm still getting used to the way packets are handled now and the codestyle.

Basic terms: There is a discrepancy between how retail handles Realm suffixes and Trinity handles them. On Trinity, it appears that the realm suffix is added despite being on the same realm, so TRP would try to send a message to Syloxus-Trinity but in TrinityCore is literally sending a message to a player named "Syloxus-Trinity" which is why the client never replies because the server never sends it to the right player.