PX 0.3.5.1
 

News:

29 December 2022 - PtokaX 0.5.3.0 (20th anniversary edition) released...
11 April 2017 - PtokaX 0.5.2.2 released...
8 April 2015 Anti child and anti pedo pr0n scripts are not allowed anymore on this board!
28 September 2015 - PtokaX 0.5.2.1 for Windows 10 IoT released...
3 September 2015 - PtokaX 0.5.2.1 released...
16 August 2015 - PtokaX 0.5.2.0 released...
1 August 2015 - Crowdfunding for ADC protocol support in PtokaX ended. Clearly nobody want ADC support...
30 June 2015 - PtokaX 0.5.1.0 released...
30 April 2015 Crowdfunding for ADC protocol support in PtokaX
26 April 2015 New support hub!
20 February 2015 - PtokaX 0.5.0.3 released...
13 April 2014 - PtokaX 0.5.0.2 released...
23 March 2014 - PtokaX testing version 0.5.0.1 build 454 is available.
04 March 2014 - PtokaX.org sites were temporary down because of DDOS attacks and issues with hosting service provider.

Main Menu

PX 0.3.5.1

Started by ruler, 08 September, 2006, 10:23:08

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ruler

Something strange i found concerning the profiles, here goes...
i deleted all profiles and created a new set in the order as follows

Owner = value 0
NetFounder = value 1
SU = value 2
OP = value 3
KVIP = value 4
VIP= value 5
Reg = value 6

ok here's the fun part...
if a lower rank user tries to kick a higher rank user then the kick is denied but the kick message is still send to the user in PM.
If a higher rank user kicks a lower rank user then the kick is eccepted and user is kicked but no kick message is received in PM.
if you try to kick yourself the kick is denied and no kick message is receiced in PM (this is the only one that is correct).

i setup profiles in that order as i and many others believe that this is the order is should be in. you cant get higher than a hub owner, a netfounder is like an owner but having more responsibility over more hubs. a SU is just a OP but with a few more uninportant extra's and is usually just a brown noser :D
anyway plz feel free to test this out (without scripts) you should find the same results as me.
thanks

ruler

The Direct Connect Global Banlist get protected.

bastya_elvtars

Quote from: ruler on 08 September, 2006, 10:23:08
if a lower rank user tries to kick a higher rank user then the kick is denied but the kick message is still send to the user in PM.
If a higher rank user kicks a lower rank user then the kick is eccepted and user is kicked but no kick message is received in PM.
if you try to kick yourself the kick is denied and no kick message is receiced in PM (this is the only one that is correct).

If you mean the built-in kick of DC++, then this is a protocol issue. THe PMs are sent anyway (and the main messages) regarldless of the actual $Kick.
Everything could have been anything else and it would have just as much meaning.

ruler

yup it's the ' you are being kicked because: ' in PM i mean, but it will send it OP to OP but why would it allow the kick without the message and disallow the kick with the message? thats bizzar? surely it can be fixed is a simple fasion.

the simplest method would be for the client to remove the inbuilt kicks and let the hubsoft do it the same as with all the other commands that it handles. now this is a typical ' spanner in the works ' so to speak  ???

The Direct Connect Global Banlist get protected.

bastya_elvtars

Yes, the kick from DC++ swhould be removed and the hubsoft should be made to send the appropriate usercommand (specific to itself).
Everything could have been anything else and it would have just as much meaning.

ruler

ive devised a work-a-round for this problem, its not quite what i wanted but it will do, now all kicks are checked so that is a kick is received by the hub it will check and compare ranks against kicker and victim so that if the victim is of a lower rank then cick is allowed else blocked and same for PM message ' You are being kicked because: ' and also the anoying ' blabla is being kicked because: ' in main  8)

it would be nice if future hubsofts that were developed were to ' cough cough  ;D ' ignore the $Kick and $OpForcemove commands so that the hub could could have its own inbuilt kick and redirect commands like they have with the ban, tempban, drop etc. maybe that way future clients will no longer use the $Kick and $OpForcemove too as they would no longer be eccepted by the hubsofts :D
just an idea  :P

The Direct Connect Global Banlist get protected.

PPK

#5
"Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris." - Larry Wall

bastya_elvtars

Quote from: PPK on 08 September, 2006, 18:36:01
Missing kick message is bug, actually i have it fixed in my devel version more than week  :P

It does not matter, the builtin client kick still sucks. :D
Everything could have been anything else and it would have just as much meaning.

ruler

i agree with bastya_elvtars, the inbuilt client kick AND redirect suck and also causes a lot of problems for some scripters as they have to work around the anoying message that are sent from the client. maybe if hub developers were to program the next generation of hubs to ignore the $kick and $OpForcemove then the client developers migh no longer include the commands with their future releases saving everyone a headache  ;D its just a thought lol that should give developers a lot less to worry about. its just  a matter of obmitting 2 commands and using the hub to impliment its own kick/redirect commands same as with all its other commnands.
anyway i dont know about you peeps but after about 5 - 6 years of being on DC the ' You are being kicked because: ' and <kicker> is kicking <victim> because: ' gets a bit borring and woulf be nice if we could be able to customise that with a new hubside kick sommand :)
but haviong said all that im not even sure if all that would be posible but i see no reason why now  (if hub an client designers all co-operated together)

thanks

ruler

The Direct Connect Global Banlist get protected.

PPK

I don't see nothing wrong on $OpForce move. Nick, redirect address, reason is in one command and for hub is easy to block it without sending any message  ::)
"Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris." - Larry Wall

ruler

yup you are right but i just think all the commands would be better done from the hubsoft side instead of the client, it does make sence in one respect. when DC was first started the kick and redirect on the client seemed the best option (at the time) but now the hubsofts have become more advanced much like PX i think commands like those would be a lot easier to handle from the hub. i may be totally wrong of course but its only another ticket for the suggestion box  ::)

The Direct Connect Global Banlist get protected.

SMF spam blocked by CleanTalk