Check Share according to userlevel

[YouKnowWho 0]

I'd love to have the option to check users on join by userlevel, specifically, I'd like the option to exclude OPs and maybe VIPs from the check (protected users).

[spyke 0]

This would go in Feature requests,not client discussion :D

[YouKnowWho 0]

Must have misclicked the forum, somebody move this please so people don't answer off-topic like above.

[Greg 0]

Moved to the appropriate forum.

As for the actual request, it's not something I'd personally see a need for, seeing as often I just manually select the users I would like to check, and therefore exclude those sorts of people anyway.

[Pothead 0]

Plus the Apex cannot tell the difference between Registered Users and Vip Users. Or even unregged users (unless they are not regged in any hub).

Only feasible way is to give all the vip's a prefix. And protect all the people with that prefix. :)

[YouKnowWho 0]

How about doing checking with client side lua script?

[Pothead 0]

How about doing checking with client side lua script?

You still won't know the profile levels.

Only the hub knows them. The only difference the client can tell is between Op and Not Op.

[Zlobomir 3]

You still won't know the profile levels.

Only the hub knows them. The only difference the client can tell is between Op and Not Op.

But when the client receives a message like "The VIP X has entered" (probably it will need a flexible definition for it in settings), can't it remember the status for the respective VIP?

[poy 0]

But when the client receives a message like "The VIP X has entered" (probably it will need a flexible definition for it in settings), can't it remember the status for the respective VIP?

yes, in such a case you can. but all hubs don't send such messages... it would be hub-specific.

[Zlobomir 3]

yes, in such a case you can. but all hubs don't send such messages... it would be hub-specific.

Yes, but since the person doing the checking is usually the hub OP/Owner, this shouldn't be a problem... It's up to him to set the message on hubside and his client. For several hubs there may be several messages, divided by some separator?

Edited September 13, 2006 by Zlobomir

[poy 0]

Yes, but since the person doing the checking is usually the hub OP/Owner, this shouldn't be a problem... It's up to him to set the message on hubside and his client. For several hubs there may be several messages, divided by some separator?

for several hubs, there can be some kind of manager like the one that manages the user commands, etc.

anyway, this sounds really weird to me and i believe such stuff should be done hub-side, but shouldn't be integrated in a client.

[YouKnowWho 0]

Hubs cannot do extended share-checks, only clients can.

[Zlobomir 3]

Hubs cannot do extended share-checks, only clients can.

Yes, but I meant that the OP will possess the hub and the client. And he will be able to set the Welcome message for VIPs and also the (same) extended check share trigger in his client, based on the hub's message. F. ex. I am the OP:

1. Set on hub the VIP Velcome message "Hello VIP protected user"

2. Set in the net client option the trigger "Hello VIP protected user" (actually it will be vice-versa: Check all that are not welcomed with such message).

If you find the idea good, this could be added for all user groups. So you can Protect Owner, OP, VIP and Registered, or only Owner and OP, etc.

[Pothead 0]

That way is a really bad idea. Open to abuse, and a pain in the arse to code. And it floods your hub with welcome messages.

Only feasible way is to give all the vip's a prefix. And protect all the people with that prefix.

Incase you don't understand that . . . . .

[VIP]AUser

[VIP]AnotherUser

[VIP]SomeRandomUser

And protect everybody with [VIP].

[Zlobomir 3]

Well, I agree that the prefixes are a good way, I got the idea at the beginning. But this looks for me like a workaround, not a real solution. Welcome messages are usually shown, regardless of whether your client will use them for trigger or not. I do not insist, I'm not a programmer, but if the welcome messages can be used IMHO it's silly to excuse with coding. Not assigning top priority ok, although it is a function, not GUI.

P. S. What you meant by "open to abuse"?

[poy 0]

But this looks for me like a workaround, not a real solution.

from my point of view, it's your solution (which is based on chat messages) that seems more like a workaround...

P. S. What you meant by "open to abuse"?

dunno what he meant, maybe flooding. just activate such a thing in DC++ (show joins/parts) and you will see the **** it produces when someone has connection problems, and parts/joins every minute...

[Lee 84]

What happens when a Non-VIP puts [VIP] infront of his name? The program will think it is VIP.

[Pothead 0]

Users with [VIP] prefix can easily be blocked in the hubsoft.

Open to abuse . . . . . like if i send the welcome message. ^_^

[YouKnowWho 0]

Personally, I don't need this script for VIPs... I would already be happy if it didn't check OPs :-)

[Crise 26]

Personally, I don't need this script for VIPs... I would already be happy if it didn't check OPs :-)

my apexdc don't do that as far as i can remember ^_^

[Zlobomir 3]

my apexdc don't do that as far as i can remember

Hey, but you aren't going to customize Apex for each single PC/user, are you? :)

[Crise 26]

Hey, but you aren't going to customize Apex for each single PC/user, are you?

Nope, don't think so (but i just checked and on my version op's are not checked... and thus they should not be in 0.2.2 either)

[YouKnowWho 0]

Does that include their filelists? When I activate that option, all filelists are downloaded and checked, even those of OPs.

[Crise 26]

Does that include their filelists? When I activate that option, all filelists are downloaded and checked, even those of OPs.

Seems that on some hubs op's are checked (ptokax) and on some they are not (ynhub/others) Don't ask me why this is happening tho.

[A_Alias 0]

those checks pulled a lot of uneeded file list for regular users.. would be the best to have this future only in OP client.

what if a regular user found a cheat ... he only can start to bark to that user but cannot bite.

and even if it comes a part into the OP version ... it would be nice to have a rightclick to easy ad a trusted level(s) for a NICK but include the curent IP or CID ( yeh include ip or CID to check if user Bob on one hub is the same as the other Bob on the other hub ... as most ops are on multy hubs )

also the check on connect need to be reduced ... for example if an op have a bad connection to a hub and reconnect ... it shows all users as fresh connected and started to pull thier list (( thats what i know from zion++ i did not tested the one from apexdc++0.2.2 yet)) so check the same nick+ip max twice 24 HR would be nice ( even better if those default max check values can be adjusted )

personal i like to have this levels

trusting level 1. unreg reg check on conecting max 2 x into 24 HR

trusting level 2. peeps you think you can trust max 1 x into 48 HR

trusting level 3. vips and oldtimers at the hub max 1 x a week

trusting level 4. ops and above (why not) max 1x a month

bad shares should also be looked for with an advanced ADL search that can do PM users + oproom , kick or even ban for bad files ( a easy way to ad bad TTH strings to ADL search would be great too )

afcourse with setings to limit for search frequences i can imagine to many searches would be bad in the bigger hubs.

A_Alias

PS would it be poseble to write a bot ( for all common hubsoftware ) so that there can be created a trusted list and that that list get loaded to ApexOP client??