157 replies to this topic

[BamBam]

add description to adl search properties box.  to rember six month later why searching for that entry

and also search by tth in adl search

entries that stay in search drop down menu after shut down and restart client  

Currently have pwdc++ 0.41, reely happy with it keep all fetures

[curse]

hows about

string ShareManager::translateFileName(const string& aFile, bool adc) throw(ShareException) { 
   RLock l(cs); 
   if(aFile == "MyList.DcLst") { 
	  generateXmlList(); //new string: it copys from files.xml.bz2 
	  return getBZXmlFile(); //new string: it copys from files.xml.bz2 
	  //generateNmdcList(); //string comment
	  //return getListFile(); //string comment 
   } else if(aFile == "files.xml.bz2") { 
	  generateXmlList(); 
	  return getBZXmlFile(); 
   } else { 
	  string file; 
	   
	  if(aFile.length() == 39 && Encoder::isBase32(aFile.c_str())){ 
		 TTHValue tth(aFile); 
		 HashFileIter i = tthIndex.find(&tth); 
		 if(i != tthIndex.end()) { 
			dcassert(i->second->getTTH() != NULL); 
			file = i->second->getParent()->getFullName() + i->second->getName(); 
		 } 
	  } 

	  else if(adc) { 
		 // Check for tth root identifier 
		 if(aFile.compare(0, 4, "TTH/") == 0) { 
			TTHValue v(aFile.substr(4)); 
			HashFileIter i = tthIndex.find(&v); 
			if(i != tthIndex.end()) { 
			   file = i->second->getADCPath(); 
			} else { 
			   throw ShareException("File Not Available"); 
			} 
		 } else if(aFile.compare(0, 1, "/") == 0) { 
			file = aFile; 
		 } else { 
			throw ShareException("File Not Available"); 
		 } 
		 // Remove initial '/' 
		 file.erase(0, 1); 

		 // Change to NMDC path separators 
		 for(string::size_type i = 0; i < file.length(); ++i) { 
			if(file[i] == '/') { 
			   file[i] = '\\'; 
			} 
		 } 
		 // Ok, we now should have an nmdc equivalent name 
	  } else { 
		 file = aFile; 
	  } 

	  string::size_type i = file.find('\\'); 
	  if(i == string::npos) 
		 throw ShareException("File Not Available"); 
	   
	  string aDir = file.substr(0, i); 

	  RLock l(cs); 
	  StringPairIter j = lookupVirtual(aDir); 
	  if(j == virtualMap.end()) { 
		 throw ShareException("File Not Available"); 
	  } 

	  file = file.substr(i + 1); 
	   
	  if(!checkFile(j->second, file)) { 
		 throw ShareException("File Not Available"); 
	  } 
	   
	  return j->second + file; 
   } 
}

[Claust]

Myself i found strongdc which apex is based on to have a lot of features that are common to dcdm, but i agree lua scripting would be an ideal benefit. One thing to keep in mind is not to get caught in the same trap dcdm seems to have got caught in, it was a perfect op client but the coding appears to have anchored it to a particular base client. Above all though an op client needs to be stable while being able to automatically check
1) Clients
2) Files for certain types
but on the whole to fairly acurately run the hub unattended, dcdm used to achieve this pretty well

[A_Alias]

wel right now i use zion++ ( include the shitload off bugs ) i stoped with DCDM a long time ago as it wasnt getting good search results from all clients and even worse have trouble to get file list from newer clients.

an upload limmiter is needed for me to keep my adsl line going smooth ... with out limmiter most clients thake all the power from the line and thats prety bad cause i run my hub(s) from my home line.

afcourse some protection to abuse limmiters is needed.

as all hubs have divrend rules and week points into thier software ( or functions ) an OP client need to have all poseble options to be configured for the need that an op have ... like YNhub is missing out of the box a good fake share checker ... zion solved it. but i know a few hubs that make use from fake shares they bloat thier share size to keep other peeps out of thier hubs with a minium share from a few dozen TB's.

a sripted fake share where an op can adjust the triggers and have options to PM , Kick , time ban , perm ban a user would be good ( some build in fake share checkers into the core from some hubs / clients dont let you adjust the valeu for share into bites ... known isue is the 111111  at the begining of the share in bytes whare you come on if you just share above one TB and the known fake shres have them only at the end at the share in bytes)

it would be handy if there is a gui where you can setup (by faforite hubs) for each hub how to handle file formats/ file names. so it can optional send automatic PMs to users on forbiden share based on " file name " file extension " or even on " TTH string "

if poseble ... a light client for ops better good uptimes than have emotion packs media player suport and all other junk thats just for the funn.

if it get a share list checker .... i like to get it that it check a user only once every xx HR and at login from a hub .. check only a few users at the time ...  on big hubs it hog the hub if an op pulled all share list at once.
cant remember what client it was but there was one that got kicked for flooding at connecting or even more worse crashed the hub by the heavy load on connecting.

i'm a multy hub op so a future to check a sharelist based on username+IP would be great so it dont double or triple check the same users.
afcource an easy to use right click to make regular hubbers a trusted user ( with an optional skip check or less frequent check ) would be nice.

an option how to get cheats reported ... aka in main chat , pm from your client or a PM to the opchat.

for booth OP and regular client it would be good that the BLACK list for other clients is based as an option to turn on for each client type.

its prety sucks if your allowed DC++ MODS into the hubs your on and STRONG DC based clients block others to get even the share list ... DC hubs are to share and should not be a plase where DEV's fight thier war who have the best client and block other mods ( the hubs i'm on are discuse to block all moded client who dont share to all other users)

good suport to write custom RAW commands would be nice ( and afcourse suport for RAW comands , even hub specific by favorite hubs )

A nice future would also be that the client shut down when it get used by a user with out any key ... think it should be able to make that scripted as it showed into the tag that your connected as an op to xx hubs. on that way its not a toy to play with for non ops.

hide the share from ops is a bad thing todo in my opinion .. it let others think its cool to dont have a huge share ...  than i like more the inviseble admin mode that some hubs have ... you can lurk the hub but the dont see you at all.

even some of the ops are morons ... so out of the box every futer should be switched of an a clear help file should guide them to get the advanced futures to work.

i can write some more but maybe i should first run the (regular/op) client to see how it works now on a test PC.

A_Alias

[A_Alias]

Crise, on Jun 7 2006, 07:18 AM, said:

we hope thatwe do


and also about what to base the op-version in the best choice is SDC, because it's core is/will be upto date when RC11 is out (if it ever is). or is there any op-clients that are based on 0.647 or newer DC++? (i don't come up with any, expect zion++ might be, but not sure about it either)

the zion++ bleu op client 1.14 and above was based on DC++ 0.674 ( the latest one before the stoped the project was 2.02 )

if you coppy anything from that source please delete the bug's before you use it.

A_Alias

[Northwind]

A_Alias, on Aug 15 2006, 04:07 PM, said:

the zion++ bleu op client 1.14 and above was based on DC++ 0.674 ( the latest one before the stoped the project was 2.02 )

if you coppy anything from that source please delete the bug's before you use it.

A_Alias

Gigadisk, the author of Stealth Zion has made 2.03 so maybe use some part of it as sourse i think Giga has fixed some bugs of original version...

www.gigadisk.ic.cz

[adrian_007]

hmm... bear in mind that zion/dcdm - maybe others too - have broken bcdc detection. new version of dc++ is detected as bcdc mod. also, zion have czdc/strongdc mod bug, but this is very easy to fix

[Pothead]

adrian_007, on Aug 16 2006, 09:04 PM, said:

hmm... bear in mind that zion/dcdm - maybe others too - have broken bcdc detection. new version of dc++ is detected as bcdc mod.

That's because the new dc++ fails that check.  In DCDM svn this is sorted for the automatic searching (based on dc++ version number, it may be skipped), but unfortunately not got around to prevent people from manually doing this check on them.  

[-BlunT-]

any news on the ApeXop client ... or you keeping it hush hush

[diabolik2186]

An optimal Client OP is Zion++ Blue...sin that its development has been interrupted...

However creed that in the Operating version would have to be included functions of survey Fake Share, Fake TAG and Hacked Clients

A comfortable function would be also the limitation of the Lists and of the Client it controls to you, therefore to avoid possible Crash of the Client�?�

At last creed that can be implemented also a system in order to make to modernize in automatic rifle the IP of a Client situated behind a NAT/Firewall, perhaps through a Situated WEB...

[NadaWTB]

diabolik2186, on Aug 18 2006, 08:55 AM, said:

An optimal Client OP is Zion++ Blue...sin that its development has been interrupted...

However creed that in the Operating version would have to be included functions of survey Fake Share, Fake TAG and Hacked Clients

A comfortable function would be also the limitation of the Lists and of the Client it controls to you, therefore to avoid possible Crash of the Client�?�

At last creed that can be implemented also a system in order to make to modernize in automatic rifle the IP of a Client situated behind a NAT/Firewall, perhaps through a Situated WEB...

I understood the first line about Zion++, I am lost after that

[diabolik2186]

NadaWTB, on Aug 18 2006, 03:58 PM, said:

I understood the first line about Zion++, I am lost after that

ehm...i don't understand you post...I have only described shortly the normal functions of a operating client

[Goralf]

NadaWTB, on Aug 18 2006, 08:58 PM, said:

I understood the first line about Zion++, I am lost after that

Just for you, then:

An optimal Client OP is Zion++ Blue...sin that its development has been interrupted...

- Zion++ Blue was the optimal OP client. It's a shame it is no longer being developed.

However creed that in the Operating version would have to be included functions of survey Fake Share, Fake TAG and Hacked Clients

- Anyway, I think that the OP version should include features for checking Fake share, fake tag and hacked clients.

A comfortable function would be also the limitation of the Lists and of the Client it controls to you, therefore to avoid possible Crash of the Client�?�

- Another useful feature would be limiting functions for file lists and clients, to make sure that the client does not crash due to an excessive number of lists or clients to process.

At last creed that can be implemented also a system in order to make to modernize in automatic rifle the IP of a Client situated behind a NAT/Firewall, perhaps through a Situated WEB...

Finally, I think an automated system for detection of client IPs behind NAT/Firewall should be included, perhaps through a ???? (This sentence was difficult to understand - perhaps you have used an automatic translator? Not sure what is meant by "Situated web" or "automatic rifle"?).

[NadaWTB]

Goralf, on Aug 20 2006, 02:35 AM, said:

Just for you, then:

An optimal Client OP is Zion++ Blue...sin that its development has been interrupted...

- Zion++ Blue was the optimal OP client. It's a shame it is no longer being developed.

However creed that in the Operating version would have to be included functions of survey Fake Share, Fake TAG and Hacked Clients

- Anyway, I think that the OP version should include features for checking Fake share, fake tag and hacked clients.

A comfortable function would be also the limitation of the Lists and of the Client it controls to you, therefore to avoid possible Crash of the Client�?�

- Another useful feature would be limiting functions for file lists and clients, to make sure that the client does not crash due to an excessive number of lists or clients to process.

At last creed that can be implemented also a system in order to make to modernize in automatic rifle the IP of a Client situated behind a NAT/Firewall, perhaps through a Situated WEB...

Finally, I think an automated system for detection of client IPs behind NAT/Firewall should be included, perhaps through a ???? (This sentence was difficult to understand - perhaps you have used an automatic translator? Not sure what is meant by "Situated web" or "automatic rifle"?).

lol, thank you

[diabolik2186]

excuse me...but my english is very very bad...i have used an automatic translator trying to correct the use of english word...but...     

[BamBam]

Hello All!

wot about kick, ignore, ban, time ban peeps in multiple hubs?  Like maybe spammers or flooders.
and ignore in hubs not op in.


what about estimated release date of op client, or is to top secret?
lol

[thegypsy]

I think that a good feutures is the hub bar on the right like zmdc++ and jkdc++

[BamBam]

BamBam, on Aug 22 2006, 03:25 AM, said:

Hello All!

wot about kick, ignore, ban, time ban peeps in multiple hubs?  Like maybe spammers or flooders.
and ignore in hubs not op in.
what about estimated release date of op client, or is to top secret?
lol

Or maybe someone can help me with a user command to do the same thing.  like a global ignore?

[Lansh]

Heeej i am back again

What about look on the Source of zmDC++ it are based on core 0.691 so it will not be so hard to add to ApexDC++, if have the same things as Zion++ but potheads client fdm can apex dev take the autosearch from svn link FDM SVN

[к¢kMåñ�?�]

One of the main things I would like to see is the ability to find the same user in multiple hubs.  I have seen many users tag saying they are in 1 hub and they have 1 slot open.  I know for a fact this isnt true because I can see them in 4 or 5 hubs, all with the same tag.

This would be helpfull since I am an OP in several networks.  

It would help even more if one of them is banned or kicked, then ApexDC++ would kick or ban them in the other hubs at the same time.  This would save alot of time for OPs.

ApexDC++ v0.2.1 is the most stable client I have ever had the pleasure of using.  I am really looking forward to using your OP version.  Keep up the good work guys.

Thank you,
к¢kMåñ�?�