[Stulle]

Seriously? No offense meant, Tuxman, but seriously? I mean, Wiz said it and I said it. Now you, James, ask Tuxman if we are wrong? Just how desperate and moronic are you?!

[James R. Bath]

Feature request/logging bug. Not that you would ever do anything to modify how things work in the Official logs, but for some unknown reason messages like "User Stulle requested your list of shared directories -> denied" that normally appear in the main log screen get logged in beba's verbose log instead.

[Tuxman]

Hmm, not according to the code?

[James R. Bath]

And I'm not saying the code did it either. I'm sure the code is innocent.

[Tuxman]

So how could this happen if not caused by the code?

[James R. Bath]

Xtended has the same problem, but Katana has it logged where it's always been logged before, the main log. All are 50a. Maybe I'll try another 50a that's not official. Or maybe I'll try providing source code:

From Tombstone Xtended's diff source

emule.rc

    IDS_SHAREDREQ1          "User %s (%u) requested your list of shared directories -> %s"

ListenSocket.cpp

					if (thePrefs.GetDebugClientTCPLevel() > 0)
						DebugRecv("OP_AskSharedDirectories", client);
                    theStats.AddDownDataOverheadOther(size);

                    if (thePrefs.CanSeeShares()==vsfaEverybody || (thePrefs.CanSeeShares()==vsfaFriends && client->IsFriend()))
					{
						AddLogLine(true, GetResString(IDS_SHAREDREQ1), client->GetUserName(), client->GetUserIDHybrid(), GetResString(IDS_ACCEPTED));
						client->SendSharedDirectories();
					}
					else
					{
						DebugLog(GetResString(IDS_SHAREDREQ1), client->GetUserName(), client->GetUserIDHybrid(), GetResString(IDS_DENIED));
						if (thePrefs.GetDebugClientTCPLevel() > 0)
							DebugSend("OP__AskSharedDeniedAnswer", client);
                        Packet* replypacket = new Packet(OP_ASKSHAREDDENIEDANS, 0);
						theStats.AddUpDataOverheadOther(replypacket->size);
                        SendPacket(replypacket, true, true);

resource.h

#define IDS_SHAREDREQ1                  950

[tHeWiZaRdOfDoS]

Official code:

Quote

case OP_ASKSHAREDDIRS:
{
if (thePrefs.GetDebugClientTCPLevel() > 0)
DebugRecv("OP_AskSharedDirectories", client);
theStats.AddDownDataOverheadOther(size);

if (thePrefs.CanSeeShares()==vsfaEverybody || (thePrefs.CanSeeShares()==vsfaFriends && client->IsFriend()))
{
AddLogLine(true, GetResString(IDS_SHAREDREQ1), client->GetUserName(), client->GetUserIDHybrid(), GetResString(IDS_ACCEPTED));
client->SendSharedDirectories();
}
else
{
DebugLog(GetResString(IDS_SHAREDREQ1), client->GetUserName(), client->GetUserIDHybrid(), GetResString(IDS_DENIED));
if (thePrefs.GetDebugClientTCPLevel() > 0)
DebugSend("OP__AskSharedDeniedAnswer", client);
Packet* replypacket = new Packet(OP_ASKSHAREDDENIEDANS, 0);
theStats.AddUpDataOverheadOther(replypacket->size);
SendPacket(replypacket, true, true);
}
break;
}

Xtended code:

Quote

case OP_ASKSHAREDDIRS:
{
if (thePrefs.GetDebugClientTCPLevel() > 0)
DebugRecv("OP_AskSharedDirectories", client);
theStats.AddDownDataOverheadOther(size);

if (thePrefs.CanSeeShares()==vsfaEverybody || (thePrefs.CanSeeShares()==vsfaFriends && client->IsFriend()))
{
AddLogLine(true, GetResString(IDS_SHAREDREQ1), client->GetUserName(), client->GetUserIDHybrid(), GetResString(IDS_ACCEPTED));
client->SendSharedDirectories();
}
else
{
DebugLog(GetResString(IDS_SHAREDREQ1), client->GetUserName(), client->GetUserIDHybrid(), GetResString(IDS_DENIED));
if (thePrefs.GetDebugClientTCPLevel() > 0)
DebugSend("OP__AskSharedDeniedAnswer", client);
Packet* replypacket = new Packet(OP_ASKSHAREDDENIEDANS, 0);
theStats.AddUpDataOverheadOther(replypacket->size);
SendPacket(replypacket, true, true);
}
break;
}

no difference...

[James R. Bath]

@tHeWiZaRdOfDoS, thank you. Keep in mind I took that directly from your DIFF SRC.7z archive. I didn't generate a new diff.

Both of you are right that it was a 50a change from 49c. 49c and earlier had both the ACCEPTED and DENIED cases in the main log. Why would somebody make a pointless change like putting one in the main and the other in the verbose?


@Tuxman & tHeWiZaRdOfDoS - a fix for the IdnetifierDesc logging problem. You could also safely comment out the code since it's part of an incomplete //TODO section, or for that matter complete it for them since they clearly didn't consider it important enough to properly finish.

This post has been edited by James R. Bath: 14 July 2010 - 10:32 PM

[tHeWiZaRdOfDoS]

I think it was changed because a rejected request isn't relevant
About the fileidentifierdesc: I already thought so and removed it (for release builds) in my local sources.

[James R. Bath]

I have a hard time interpreting that smiley, but I'd argue it is relevant, especially if it's the same user doing it frequently. I think the relevancy issue shows more about the particular coder's limited actual eMule use.

[tHeWiZaRdOfDoS]

No, it's not relevant because a rejected attempt has NO impact whatsoever on the users eMule usage - even if there are 1000 of them in your log (btw: that way it's not that annoying to see it over and over again in your log - just in the verbose which is for expert users).

[James R. Bath]

Bug in friend slots, at least in the display. It only allows/shows 1 established slot at a time. If establish another, it looks like you have to once again establish a slot for the one previous (and, of course, all those prior to it). Sadly, this does not involve opinion over what is or is not relevant to log.

[tHeWiZaRdOfDoS]

What information do you think is missing?

[Stulle]

d'oh... ever wondered if all clients allow multiple friendslots!?

on a different note, tux, i think you should consider adding a session ratio because you could focus all upload on just a single self-chosen client and that is not really good, imo.

[James R. Bath]

tHeWiZaRdOfDoS, on 27 July 2010 - 07:29 AM, said:

What information do you think is missing?

There's no way to tell how many friends actually have slots outside of clicking on a particular friend and seeing if the "Establish friend slot" is already checked or not. 2.61 never displays more than one friend slot. It still has the "Remove all friend slots" command. Here's a feature request: add a "Give all friends a slot" command. And another: Remove all friends that use the same mod as the user being clicked on.

[Stulle]

friendslot is not a feature that should be used randomly. this is why the official limited it to just one friendslot at a time. and linking any friendslot function with the client software a remote user is using... that's absurd because either they are friends or you are just misusing the function.

This post has been edited by Stulle: 27 July 2010 - 08:23 AM

[James R. Bath]

For the slow, this is a reminder that this is the mod forum, not the official forum. If you want to limit everything to the official only, return to that forum and preach to your hand there.

[tHeWiZaRdOfDoS]

@Stulle: better bookmark this one!

... I'm sure you'll need it...

[Stulle]

mahahahahaha, ingenious, WiZ!

James: for your information, not all mods are alike. read the code... you might find this (ClientListCtrl but most likely similar in any other list):

			// Tux: Feature: Friend handling [start]
			case MP_REMOVEFRIEND:
				if (client && client->IsFriend())
				{
					theApp.friendlist->RemoveFriend(client->m_Friend);
					Update(iSel);
				}
				break;
			case MP_FRIENDSLOT: 
				if (client)
				{
					bool IsAlready;				
					IsAlready = client->GetFriendSlot();
					theApp.friendlist->RemoveAllFriendSlots();
					if (!IsAlready)
						client->SetFriendSlot(true);
					Update(iSel);
				}
				break;
			// Tux: Feature: Friend handling [end]
			// Tux: Feature: Remove all friend slots [start]
			case MP_DROP_ALL_FRIENDSLOTS:
			{
				theApp.friendlist->RemoveAllFriendSlots();
				break;
			}
			// Tux: Feature: Remove all friend slots [end]

any bells ringing?
and to quote the official code from FriendListCtrl:

		case MP_FRIENDSLOT:
			if (cur_friend)
			{
				bool bIsAlready = cur_friend->GetFriendSlot();
				theApp.friendlist->RemoveAllFriendSlots();
				if (!bIsAlready)
                    cur_friend->SetFriendSlot(true);
			}
			break;

so... uhmmm... feeling stupid?

PS: yes, it is the official board, we are just in the sub section dedicated to mods. it's confusing, isn't it? well, i think not.

This post has been edited by Stulle: 27 July 2010 - 01:54 PM

[Tuxman]

*giggle*

BTW Stulle, as the not existing session ratio is a part of the official eMule, I consider it as a feature, not as a bug. beba tries to be a "better" official client, nothing more.