Noctis

Yes, I already know that, and make a lot of and good use of it. But then all type of the commands appears everywhere, and this is what I'd try to avoid. I suggested three type of hubsofts but in case of you need more, 4-5, your RC will be quite crowded... And no need for apologies Zebedee, you're trying to help. :P

Hi, I got something in mind, I know this is very targeted to an OP-version of the client (if there will be one), but I'm gonna post it anyways. As you know different hubsofts use different hub commands. My idea would be: (a bit similar to the 'Hub IP / DNS' field) the possibility to sort user commands by hubsofts (the reason I said this if for OP-version, because this mostly involves raw command, not chat commands, and I am not talking about raw manager / raw profiles here :thumbsup:), so if someone is OP in hubs running different hubsofts, this could come in handy. And I guess YnHub, PtokaX and Verlihub recognition would be enough in most cases.

Yeah but as he said I guess that was another post...

(Do you have an internet connection?) This is morning here and I'm leaving in ten minutes, hope this may help...

A little correction for the last part: <%[myNI]> !kick %[userNI] !AUTO KICK --> %[userCS] <--- Share:%[userSSshort] <<< TYPO (%[userSS] B)| Thanks Balder. ;)

File's THH (supposedly), but only in the beta version.

Aztek, please try %[userAT] in your version, works only with ADL...

I don't know. But what does this string stand for anyways?

Very funny... :)

How come there was no answer on this one? I guess you figured out the new raw, but here it is: $To: %[userNI] From: %[myNI] $<%[myNI]> AUTO KICKED BECAUSE BAD SHARE: %[userCS] Share:%[userSSshort] (%[userSS] B)|$To: #[KickReport] From: %[myNI] $<%[myNI]> AUTO KICKED --> Nick:%[userNI] IP:%[userI4] Client:%[userCT] Tag:%[userTA] Share:%[userSSshort] (%[userSS] B) CD: %[userCS]|<%[myNI]> !kick %[userNI] !AUTO KICK --> %[userCS] <--- Share:%[userSS] (%[userSS] B)| I haven't tested it, but it should work. I hope I haven't made any typos.

The PMs are on their way, have fun guys :P

You are quite welcome. I can PM you all the raw strings of Zion++, if you are interested...

Zion++ Blue also supports the strings cheating description and client type, just you need to use the new method: %[userCS] for cheating description, and %[userCT] for client type. Due to DDMD++ old based, it has problems with checking newer segmented clients, unless you have a stripped one.

Yeah checking is a must for a decent OP-client. Easiest way to do it, that by default when you turn it on it starts checking in the hub you are currently viewing, so you can do checking in couple of hubs, where you want... and to start checking in all hubs.

What string do you use in your raw command? If it is %[fileFN], then that's the problem. Try changing it to %[userCS], that will contain the full path, and the ADLS comment (if there is one). About the cloned IP detection... Yes it is a good feature, but I think only the OP version needs it.

I am forced to do that too, but if this simple feature would be availabe, you wouldn't have to wait for all the results from all the hubs, and you wouldn't get lost in lot of results, and it would be more comfortable. And I also guess it is not a hard thing to implement.

One way or another, I still think that the most straight way to solve different share is by using more than one client... :)

That is stealing users, you can (and most likely will) get banned for that if someone finds out...

Oh, yes, and it is also quite annyoing when you the user just reconnects, for example, after changing nicks. It would be also good, that 'check on join' could be turned on/off per each hub, already told this to Crise, but there's a glitch actually implementing it. And about the prefixes... you either use wildcards ===> a question mark for a single character, and and asterix for more (any) character (for example in TGO: [Apex-VIP]* should be enough, I'm not sure if it is case sensitive, in zK++ it is, but this is ApexDC++ forum ), and you need to separate them with semicolons in Apex ; ; ; Or you can use RegExp but that is more complicated, wildcards are fine and working (thanks to Crise for the help with these)

Not the same point if you delete a file so you are not able to share it anymore, or when you just change share (can be simply because you don't want to share that much in that specific hub).

Yes, but if you delete it, you probably do that on purpose - you do not need the file anymore, there's no free space on your hard drive etc. But if you simply change your share, you could upload it, and maybe you don't know that the user was trying to download it from you, but you are blocking it in a way.

Yes, I agree it would be good, however I won't really use it. But it is quite complicated if you think about it a bit... How many share would you use? You would need to keep different filelist/hashes for each share. How would you sort it - which hub, which share - in favorites? Would you set a 'default' share to use when entering a hub first? And having different share could result in some conflicts: you log onto a hub with your 'default' share, someone grabs your list, begins downloading from you, then you change your share for that hub, and the file that was downloaded from you happens not to be in the other share...

Yes, and it is really annyoing, when you are in a lot of hubs, and you want to select only a few or only one...

If you turned Auto Priority off you can set the priority of queued files in Download Queue.

File\Settings...\Downloads\Queue >>> untick 'Use Auto Priority by default'