Official eMule-Board: Minor Issue Regarding Irc Chat Module (0.49b) - Official eMule-Board

Jump to content

Page 1 of 1

Minor Issue Regarding Irc Chat Module (0.49b) incorrect parsing of /names reply

#1 User is offline   Hoelderlin 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 3
  • Joined: 20-January 06

Posted 13 September 2008 - 11:46 AM

First off, I don't know to what extent smirc represents a "third party" module developed independent of emule. If this report is misplaced - sorry in advance ;)

Short description:
After doing a /names #channel request manually, all nicks with a status prefix appear twofold in the nicklist.
I'm using v0.49b; the issue occurred in older versions as well.

In detail:
Right after joining a channel, smirc (like all IRC clients) sends a /names #chan request (mainly to get the list of nicks for that channel). The Server reply contains the nicknames itself together with adherent prefix symbols ("status" prefix, according to the IRCDs nickmode-prefix definitions, e.g. "owner" = ~nick; "operator" = @nick), if there are any.
Now, if you re-trigger the /names request manually, emule (smirc) apparently parses the /names reply in such a way that it checks for nick (not nick-with-prefix) being present in that channels nicklist - which is false of course - thus adding the "unknown/new" nick(s) - with nick prefix - to the nicklist, resulting in a second nicklist entry for every nick with a nick prefix (or manyfold entries, if you repeat the /names call).

Other flaws caused by the abovementioned /names issue:
The users count (collumn header: digit in brackets) will show a "wrong" value too, as it's representing the number of items in the nicklist. The distortion of the nicklist is affected by successive channel events like status ("prefix") changes, nick changes etc., as one enty of the "doubled" nick gets updated properly, whrereas the other(s) don't.

#2 User is offline   fox88 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4747
  • Joined: 13-May 07

Posted 14 September 2008 - 03:31 PM

Your guess was logical and appears to be correct.

To fix the bug it is enough to slightly rearrange code in the file IrcNickListCtrl.cpp
in the following function
Nick* CIrcNickListCtrl::NewNick(const CString& sChannel, const CString& sNick)

These two lines of code are to be removed
	if (FindNickByName(pChannel, sNick))
		return NULL;

and before the comment //Set user level this piece of code shoul be inserted:
	if (FindNickByName(pChannel, pNick->m_sNick))
		return NULL;

Edit reason: hopefully - clarification :)
Full function text follows:
Nick* CIrcNickListCtrl::NewNick(const CString& sChannel, const CString& sNick)
	Channel* pChannel = m_pParent->m_wndChanSel.FindChannelByName(sChannel);
	if (!pChannel)
		return NULL;
	Nick* pNick = new Nick;

	//Remove all modes from the front of this nick
	pNick->m_sNick = sNick;
	while (pNick->m_sNick.GetLength() >= 1 && m_sUserModeSymbols.Find(pNick->m_sNick[0]) != -1)
		pNick->m_sModes += pNick->m_sNick[0];
		pNick->m_sNick = pNick->m_sNick.Mid(1);

	//This is a little clumsy and makes you think the previous check wasn't needed,
	//But we need the channel object and FindNickByName doesn't do it..
	if (FindNickByName(pChannel, pNick->m_sNick))
		return NULL;

	//Set user level
	if (!pNick->m_sModes.IsEmpty())
		pNick->m_iLevel = m_sUserModeSymbols.Find(pNick->m_sModes[0]);
		pNick->m_iLevel = -1;

	//Add new nick to channel.
	if (pChannel == m_pParent->m_wndChanSel.m_pCurrentChannel)
		//This is our current channel, add it to our nicklist..
		int iItem = InsertItem(LVIF_TEXT | LVIF_PARAM, GetItemCount(), pNick->m_sModes + pNick->m_sNick, 0, 0, 0, (LPARAM)pNick);
		if (iItem >= 0)
	return pNick;

This post has been edited by fox88: 17 February 2009 - 09:42 PM


  • Member Options

Page 1 of 1

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users