pretty much the title, very annoying since im not 100% sure who is from my realm and who isn't. purging doesnt fix it either

If its adding them then Blizzard is returning true to C_PlayerInfo.UnitIsSameServer which means your realms are connected. And if they're connected then their realm is in your honor pool too.

I notice @kakysha has actually tried to fix this problem before.
f1f3f33
b83b1f8
31492b0
Kakysha, maybe you have some ideas, since you've tried to solve this one before?

I would I go about disabling data collection in Battlegrounds for testing?

To disable data collection in Battlegrounds, I'd just add a "Am I in a BG?" check. It might be as simple as this, but C_PvP.IsPVPMap() doesn't have any documentation and I can't join a BG on Classic to check if it works: https://github.com/teelolws/HonorSpy/commit/255d59a184c68e4a249a4af03e714dc12cc7709b

Edit: I now realise even this won't completely solve the problem, at least not for Classic Era players. That screeny I showed didn't happen while in a Battleground! But at least SOM players won't have players on other servers around them that would cause this.

I noticed this issue last week when Blizzard enabled transfers to other servers on SOM. Although the above function might return true in terms of UnitIsSameServer, for the determination of honor ranking, it did not affect our pool / ranking last week.

As such and since this function no longer enables us to know if the player is from our own server, would it be possible to match / filter per server. Ie. using GetRealmName to make sure the other player is in fact from the same server.

The reason for using UnitIsSameServer is because Classic Era has Connected realms where I actually want them all included. If we can't rely on UnitIsSameServer on SOM then we need to find a solution that works for both.

Can you give me specifics on where UnitIsSameServer is incorrectly returning true on SOM?

We need a way to filer out players from other servers as they are not part of our pool in terms of brackets for ranking. So perhaps add a setting to exclude players not from the same server. Like only show players from my server option.

Example: I am from Nightfall and have players form Jom Gabbar now showing up on HonorSpy. This only stated happening last week since Blizzard enabled transfers.

If you're certain that SOM doesn't have Connected Realms, and never will have Connected Realms, I could just add a simple "Is This SOM" check and exclude all other realms on SOM?

Example: I am from Nightfall and have players form Jom Gabbar now showing up on HonorSpy. This only stated happening last week since Blizzard enabled transfers.

When you're in a BG, and you target a player from Jom Gabbar, and run: /dump UnitIsSameServer("target") what is the output?

Sorry wrong function. This is the one HonorSpy uses currently: C_PlayerInfo.UnitIsSameServer(PlayerLocation:CreateFromUnit("target"))

UnitIsSameServer might just be a synonym for that, I'm not sure.

Currently returns false. I need to find one of those players that does show up on HonorSpy that I know if not from our server.

Another idea I had was periodic re-checks. Maybe it returns true, but you later inspect the player and it returns false. Currently it doesn't nil the connected realm for that. This would change that: https://github.com/teelolws/HonorSpy/commit/6bb1648d4f46af7cf951eb9292a7b180250bea45

In this image many players are not from our server. Player 9 for instance is from Jom and checking using C_PlayerInfo.UnitIsSameServer(PlayerLocation:CreateFromUnit("target"))does return false and yet he shows up. So perhaps this ends up true at some point but not always.

I wonder that this is related to a bug I couldn't figure out a while back? I somehow ended up with duplicate data about the same character saved under both their connected realm, where the character actually is, and the same character name labelled as if its on my server. The one with "-Yojamba" is the correct one; the one without a realm is a character that doesn't exist, but saved anyway. I haven't been able to get the bug to happen again, and so I can't figure out why it happens.

Again keep in mind this started happening when Blizzard enabled transfers to Jom. I suspect that players who were on Nightfall and transferred to Jom are corrupting the data as they potential exists in both or the data files somehow getting mixed. Nukenova never transferred but some corruption is occurring.

I think the "Blizzard enabled transfers" bit is just a coincidence. Thats just the time when I released this fix to support connected realms on Classic Era, and my PR got accepted.

I'm currently on your server on alliance, and I can add Nukenova to friends:

And the player is currently offline, but the character exists:

Talked to you in-game for a bit. A summary:

• For some reason, HonorSpy thinks these characters are on your server when they're not. And so it adds them, treating them as if they're a character on your server.
• It seems like it might be a one-off issue per character. You'll notice that all those incorrect characters were "LastSeen" quite some time ago. As if HonorSpy continued getting data from them, but actually filtered them out properly.
• The character names exist on both Jom Gabbar and Nightfall on the same faction. HonorSpy has a test to make sure the character exists on your server, by adding them to friends briefly, and they're passing that test.
• I'm stumped as to the root cause of the issue. I had it happen to me on Classic Era, once, and haven't been able to get it to happen again. I couldn't even pinpoint when it happened. Did I inspect the player and it didn't show their realm yet? Did they broadcast data to me, and their whisper didn't include their realm? I don't know.
• Maybe its some WoW Caching issue?

I invite other devs to make suggestions cause I'm out of ideas.

Worst comes to worst, there is always the nuclear option: Just disable data collection while in a Battleground?

Worst comes to worst, there is always the nuclear option: Just disable data collection while in a Battleground?

I would I go about disabling data collection in Battlegrounds for testing?

Yeah I remember that x-realms players being added in BGs was a headache for me. Reading your convo makes me certain that its a Blizzard api returning incorrect values, as this is what I encountered many times already. Especially during transfers enabled or pvp and honor system changes.

Yeah I remember that x-realms players being added in BGs was a headache for me. Reading your convo makes me certain that its a Blizzard api returning incorrect values, as this is what I encountered many times already. Especially during transfers enabled or pvp and honor system changes.

Do you think it would be too disruptive if I just added a line of code that disables collection while in a BG? I figure everyone queues from basically the same place in the city and the collection can be done before/after games. Also I can keep self-collection going so players with HonorSpy will keep broadcasting their own data even in a BG.

E: Another idea I have is go off the assumption that this "glitch" is only the first time you see that character. Keep a list of players we have inspected or received messages from since the last login/reload. If its the first time this session, throw it away but store their name. We can save their data the second time we "see" them.

Why can't we filter players in the BGs by the server suffix in their names? If we know the names of all connected servers, we can filter out players from the other ones. I don't really know how pvp pool is working now, but preventing data collection in bgs probably will do more harm than good.

Well thats the problem - it seems we're sometimes getting data claiming the target/mouseover player has no server suffix in their name, when they actually do. I'm trying to find a way to filter out this bad data. Or at least more checks to find out if its bad data.

Does the ingame UI shows the suffix when API doesn't? There should be couple of ways to get the reliable name, if game client can show it, the we should be able to get it too.

I don't know. I've never been able to catch the glitch "live", only see the results show up later.

I could run a verbose debug version to try catching how it happens if you need to !
Let me know

can't remember if this was also reported but i keep getting data from last week which also messes with standings. it tells me i have two different standings but not sure which one is more accurate.

Could we hard-code the different clusters as a temporarily workaround ?

I asked some help on the topic to someone knowledgeable (Meorawr) and here is some highlights.

It is possible - and expected - for C_PlayerInfo.UnitIsSameServer to transition from returning false to true when the same unit is queried over time.
However it will be fairly uncommon; basically for it to happen you need to query a player unit before the game has received their full information
Which usually happens if you're idling and a nearby player logs in or you're at a hearthstone bind point that someone just hearthed to.
Feasibly it could happen in the battleground/arena setup rooms since players are effectively "teleporting" in.

Then I asked if we could add another check to discard unreliable results

Usually GetPlayerInfoByGUID(guid) will return the globalstring constant UNKNOWNOBJECT for their name if given a player guid that isn't yet loaded.
(Same with UnitName(unit))

Its not a problem with UnitIsSameServer returning true when it should be false. Its a problem with UnitName("mouseover") returning "nil" for the Realm Name when there should actually be a realm name there. And so HonorSpy thinks the person is on your server.

As per @Slivo-fr comment, we probably can take "mouseover" unit GUID and check it's GetPlayerInfoByGUID(guid) for being populated correctly before proceeding?

If I'm reading his comment correctly, if that was the bug, UnitName("mouseover") would also return UNKNOWNOBJECT. HonorSpy already checks for this.

This comment #175 (comment) says it's about UnitIsSameServer

By the way, I worked on a dirty fork for french realm before teelo pushed connected realms to official repo and I did not have this issue at all. We may be able to figure this out comparing the branch https://github.com/Slivo-fr/HonorSpy/tree/custom-era-fr ?

It's been working fine for the past months, where today I have player that never been on my realm poping up in the Honorspy Table

You probably didn't have this issue because at the time, free transfers weren't running. HonorSpy checks if the character name exists on your server and is the same faction. In most cases that check would catch this bug. But when a LOT of players have been taking free transfers to a mega-server, their name on the old server remains and you get this bug.

From a quick look at your code, this line might be catching the bug:

if (name == nil or not UnitPlayerControlled(unitID)) then return end

Added to my PR #183

Would be great!

What about the if (name == nil part ?

I'd like to see that actually be a problem before we add that check. I have yet to see "nil" or "UNKNOWNOBJECT" on the standing table.

Its checked against nil somewhere in store_player() anyway.

As an aside, small rant about Blizzards API:
I don't like that there is no way to get the name of the player we currently have Inspect data about. What if two different addons request Inspect data about two different players? One requests it from "target" and another requests it from "mouseover". When we get the INSPECT_READY event, how do we know which player the inspect data is for?
Given it takes about 0.4 of a second to get inspect data, thats enough time for the player to finish loading in. If I could confirm their name, it would be different by this point. Instead of "Dude" it would now be "Dude-Yojamba" and I'd throw the data away.

@kakysha any chance to get this prioritized ? It kinda makes the addon unusable on ERA clustered realms, to the point we may just step back to my dirty fork until it's solved

I mean this is an issue, not a PR :) I stopped playing a year ago and kinda in a bad situation due to latest news, cause I'm russian. So I can't really make changes nor I can test cause Blizzard banned russians from their subscriptions :(
PR are very welcome and I can accept everything, as long as the solution is checked by ppl and working to everyone.

The #183 PR includes a try to fix it (in addition to other things)
I wish your situation gets better, sad to hear !

Did not happen to me since 1.8.7, anyone still experiencing it ?

I do think this issue can be closed