When I log on W3.....it shows myself 2 times in the channel, does anyone know what might be causing this or if they have had the same problem, how to fix it....It also sometimes adds the operator twice but only when it shows myself in the channel twice.....This is with VB
I can resolve the issue by doing /resign......but I would perfer it to be fixed instead of always doing /resign....Thx
Sometimes on War3 you get statstring updates, which will be sent in SID_CHATEVENT (0x0f) with event id 0x01.. Your parsing needs to be fixed to show stat updates on users... (ex: search your userlist for the user, if it already exists then dont add them to the list, just display a stats update)
Heh, good ol UserLoser always first to reply, and usually most efficient reply too ;D
Quote from: UserLoser. on January 11, 2004, 06:14 PM
Sometimes on War3 you get statstring updates, which will be sent in SID_CHATEVENT (0x0f) with event id 0x01.. Your parsing needs to be fixed to show stat updates on users... (ex: search your userlist for the user, if it already exists then dont add them to the list, just display a stats update)
Just my alternate method since at one time duplicate users happened a lot: I have a boolean, and when I join a channel, I set it to false. Then, as i get the list of users in the channel, if the boolean is false I add them to the list. When I see my own name in that list of users, I set the boolean to true, as you will always be last (well, odds are, anyway). Then when i recieve the EID_USER event and that boolean is true, I treat it as a statstring update.
Quote from: Soul Taker on January 12, 2004, 02:00 AM
Quote from: UserLoser. on January 11, 2004, 06:14 PM
Sometimes on War3 you get statstring updates, which will be sent in SID_CHATEVENT (0x0f) with event id 0x01.. Your parsing needs to be fixed to show stat updates on users... (ex: search your userlist for the user, if it already exists then dont add them to the list, just display a stats update)
Just my alternate method since at one time duplicate users happened a lot: I have a boolean, and when I join a channel, I set it to false. Then, as i get the list of users in the channel, if the boolean is false I add them to the list. When I see my own name in that list of users, I set the boolean to true, as you will always be last (well, odds are, anyway). Then when i recieve the EID_USER event and that boolean is true, I treat it as a statstring update.
Remember that you can receive various chat events from users before you have finished receiving the channel list (I've received a talk from somebody before I was told that they were in the channel, for instance -- this could just as easily apply to a join/leave/inchannel notification). Additionally, the server fairly often sends stats updates for incoming users before sending the join notification to you, so you need to handle that too.
Quote from: Skywing on January 12, 2004, 06:55 AM
Quote from: Soul Taker on January 12, 2004, 02:00 AM
Quote from: UserLoser. on January 11, 2004, 06:14 PM
Sometimes on War3 you get statstring updates, which will be sent in SID_CHATEVENT (0x0f) with event id 0x01.. Your parsing needs to be fixed to show stat updates on users... (ex: search your userlist for the user, if it already exists then dont add them to the list, just display a stats update)
Just my alternate method since at one time duplicate users happened a lot: I have a boolean, and when I join a channel, I set it to false. Then, as i get the list of users in the channel, if the boolean is false I add them to the list. When I see my own name in that list of users, I set the boolean to true, as you will always be last (well, odds are, anyway). Then when i recieve the EID_USER event and that boolean is true, I treat it as a statstring update.
Remember that you can receive various chat events from users before you have finished receiving the channel list (I've received a talk from somebody before I was told that they were in the channel, for instance -- this could just as easily apply to a join/leave/inchannel notification). Additionally, the server fairly often sends stats updates for incoming users before sending the join notification to you, so you need to handle that too.
Yes, well, I don't see how not having the person displayed in the user list until an instant after I get a chat event from them will cause any problems with my system. And since it doesn't rely on checking if the user is already in the list, stat updates before join notifications are handled fine. In fact, since I have a 1/4 second delay before parsing join notifications (for filtering purposes), I see it happen all the time.
Also remember bots see ops as a double join. 1 is it joining and 1 is it joining as ops. I had the same problem for a while too
Quote from: Gangz on January 12, 2004, 07:27 PM
Also remember bots see ops as a double join. 1 is it joining and 1 is it joining as ops. I had the same problem for a while too
Sometimes on you will get statstring and/or flag updates when a user joins a channel, which will be sent in SID_CHATEVENT (0x0f) with event id 0x09.. Your parsing needs to be fixed to show stat updates on users... (ex: search your userlist for the user, if it already exists then dont add them to the list, just display a stats update)
You forgot User, some people cannot read!
Quote from: Soul Taker on January 12, 2004, 12:17 PM
Quote from: Skywing on January 12, 2004, 06:55 AM
Quote from: Soul Taker on January 12, 2004, 02:00 AM
Quote from: UserLoser. on January 11, 2004, 06:14 PM
Sometimes on War3 you get statstring updates, which will be sent in SID_CHATEVENT (0x0f) with event id 0x01.. Your parsing needs to be fixed to show stat updates on users... (ex: search your userlist for the user, if it already exists then dont add them to the list, just display a stats update)
Just my alternate method since at one time duplicate users happened a lot: I have a boolean, and when I join a channel, I set it to false. Then, as i get the list of users in the channel, if the boolean is false I add them to the list. When I see my own name in that list of users, I set the boolean to true, as you will always be last (well, odds are, anyway). Then when i recieve the EID_USER event and that boolean is true, I treat it as a statstring update.
Remember that you can receive various chat events from users before you have finished receiving the channel list (I've received a talk from somebody before I was told that they were in the channel, for instance -- this could just as easily apply to a join/leave/inchannel notification). Additionally, the server fairly often sends stats updates for incoming users before sending the join notification to you, so you need to handle that too.
Yes, well, I don't see how not having the person displayed in the user list until an instant after I get a chat event from them will cause any problems with my system. And since it doesn't rely on checking if the user is already in the list, stat updates before join notifications are handled fine. In fact, since I have a 1/4 second delay before parsing join notifications (for filtering purposes), I see it happen all the time.
It would matter if you didn't treat event 2 specially, which you didn't specify...
Quote from: Skywing on January 13, 2004, 07:11 AM
Quote from: Soul Taker on January 12, 2004, 12:17 PM
Quote from: Skywing on January 12, 2004, 06:55 AM
Quote from: Soul Taker on January 12, 2004, 02:00 AM
Quote from: UserLoser. on January 11, 2004, 06:14 PM
Sometimes on War3 you get statstring updates, which will be sent in SID_CHATEVENT (0x0f) with event id 0x01.. Your parsing needs to be fixed to show stat updates on users... (ex: search your userlist for the user, if it already exists then dont add them to the list, just display a stats update)
Just my alternate method since at one time duplicate users happened a lot: I have a boolean, and when I join a channel, I set it to false. Then, as i get the list of users in the channel, if the boolean is false I add them to the list. When I see my own name in that list of users, I set the boolean to true, as you will always be last (well, odds are, anyway). Then when i recieve the EID_USER event and that boolean is true, I treat it as a statstring update.
Remember that you can receive various chat events from users before you have finished receiving the channel list (I've received a talk from somebody before I was told that they were in the channel, for instance -- this could just as easily apply to a join/leave/inchannel notification). Additionally, the server fairly often sends stats updates for incoming users before sending the join notification to you, so you need to handle that too.
Yes, well, I don't see how not having the person displayed in the user list until an instant after I get a chat event from them will cause any problems with my system. And since it doesn't rely on checking if the user is already in the list, stat updates before join notifications are handled fine. In fact, since I have a 1/4 second delay before parsing join notifications (for filtering purposes), I see it happen all the time.
It would matter if you didn't treat event 2 specially, which you didn't specify...
Didn't really think that I'd need to treat it specially because users don't join channels with the flags of an operator
It varies for me; when I enter Op [vL], I get the user as having entered with ops -- I know this because my bot puts [vL] up at the top right away. When I enter a Warcraft III channel, it enters as a regular user, and then the server sends a flags update.
That's how it works, consistently, for me.
Quote from: UserLoser. on January 13, 2004, 05:46 PM
Didn't really think that I'd need to treat it specially because users don't join channels with the flags of an operator
I don't see how what flags the user is joining with makes any difference. Besides, you're wrong anyway, that happens with server splits. You need to be able to recognize receiving event 1 and then event 2 as a stat change similar to how you need to recognize receiving event 1 and then another event 1 as a stat change [for the same user]. Then, you
also need to handle "real" duplicate users (though these are fairly rare now, I've still encountered them recently). Typically, you would check stuff like the username case and the user's ping to help make your guess more accurate.
um...........Thanks I guess.......*puzzle* ::)