self:RegisterComm("GPSLib", "GROUP", "OnCommReceive")
... ** Receiving function **
function GPSEvents:OnCommReceive(prefix, sender, distribution, msg)
** Sending function ** GPSEvents:SendCommMessage("GROUP",SendData)
Problem When I am on a worldmap or inside a dungeon everything works fine. The moment I enter an arena OnCommReceive does not fire at all. I put a simple "received" message to test if it was getting any calls to the function - nothing. Sends keep going, and they work perfectly sending and receiving until I zone into an arena where receiving stops cold.
Since a raid gets formed when you zone, i figured it might be part of the problem, but, it does fine in all the dungeon cases of creating, moving players around, dropping, etc. It just seems like the event gets temporarily unregistered. Which is odd, because my other addons seem to receive addon events when in arenas.
Any help would be GREATLY appreciated, this is the last issue holding me up from moving forward with my addon.
I realize GPSlib was never finished - and i've actually got it working fine in arenas. That's not really the issue. The issue is simply needing OnCommReceive to keep receiving when I enter an arena or why it stops sending (so an AceComm-2.0 / AceEvent-2.0 problem).
I made a bliz event "chat_msg_addon" and was able to see that the outgoing messages being sent by SendComm were coming through (all encoded mind you), but they were not being picked up by OnCommReceive.
Being new to ace, i'm hoping it's something easy I overlooked or there's a way i can kick it in the pants to make it go again. I'm even toying with the idea of trying to just capture the events and decode them in the main loop. However, since I know absolutely nothing about AceComm or AceEvent (and I have been reading up on it) - I figured the knowledge base here could help.
An acceptable solution in 'pseudo code' would also look like this since gps sends a table over and I have no idea what AceComm is doing to it in the background.
Ok, you are using the following function to send messages:
The distribution method is "GROUP" which means that AceComm will automatically select whether to send it to "BATTLEGROUND", "RAID" or "PARTY" depending on your location. AceComm's method is as follows:
local function GetCurrentGroupDistribution()
if select(2, IsInInstance()) == "pvp" then
elseif UnitInRaid("player") then
If you are in an arena, select(2, IsInInstance()) returns the string "arena", while if you are in a battleground, it will return "pvp". This means that AceComm will use "RAID" or "PARTY".
The issue here is whether you are considered to be in a raid or not when first zoning into an arena from UnitInRaid("player"). Are you in a raid when there's only 1 person in the arena? Or is a raid only formed when the second player zones in.
AceComm will only read from one of the 3 channels "RAID" or "PARTY" or "BATTLEGROUND" depending on your location. If you are in a BG, it will only read incoming messages from "BATTLEGROUND". If playerA and playerB are in a party, and if playerA zoned into an arena and its considered a raid in there, he is sending data to "RAID", while playerB haven't zoned in yet, is still in Ironforge, he will only be reading data from "PARTY", so no communication occurs between them until they are both in the same location.
Xinhuan & Orion,
I wanted to thank you both for leading me to a solution. After your breakdown of the GROUP and how it's supposed to send to particular channels based on the situation I did a bit of digging. So I put some catches in to see what event groups were being triggered. As it turned out, zoning into an arena with "GROUP" set did the following.
PARTY--> RAID --> BATTLEGROUND
I joined with 2 people in my party, my party was converted to a raid upon entering even though I had not accepted the port yet. Upon zoning in, the "GUILD" tag showed up briefly before switching to RAID then to BATTELGROUND.
In short AceComm got confused about where it should be sending stuff since one client thought it was in a battleground because the raid was already formed, the other thought it was in a raid.
Since this is a special case i've setup, i've set the registration to be "PARTY" always and that worked.