Peace and Protection forum
Not logged in [Login - Register]
Go To Bottom

Printable Version  
Author: Subject: problem with users
black_ps
Junior Member
**




Posts: 3
Registered: 8-1-2009
Member Is Offline


[*] posted on 8-1-2009 at 17:13
problem with users


*** [#underworld] topic- set by X (Thu 8th Jan 2009 05:18p)
*** [#underworld] users- 37 total user(s)
*** [#underworld] users- 39 op(s) 105.41% - 35 other(s) 94.59%

it can't be 37 users on channel and 39 ops,it this a bug ? i`m using latest 4.22.2 , can somebody help me out?
View user's profile View All Posts By User
black_ps
Junior Member
**




Posts: 3
Registered: 8-1-2009
Member Is Offline


[*] posted on 8-1-2009 at 17:16


i mean on networks with UHNAMES,like afternet,or unrealirc i got this problem ...
View user's profile View All Posts By User
craze
Administrator
********




Posts: 19
Registered: 9-10-2008
Member Is Offline


[*] posted on 9-1-2009 at 17:01


SYMPTOMS
- Everyone is counted as an op one more time than supposed to. Ops are counted twice, while everyone else is counted as ops once (too).
- Anyone with more than one mode (op/halfop/voice) is counted equally many times. (For example both as op and voice)
- Being alone with +ohv in a channel will return 1 total user(s), 2 ops, 1 halfop, 1 voice to a /names request.

SHORT ANSWER
Scratching the surface of this, it appears that PnP can't handle UHNAMES messages from server properly.

LONG ANSWER
UHNAMES is different as the whole nick!user@host is returned in addition to every mode (@%+) the user has on channel instead of just a nickname with the first matching prefix.

PnP seem to count every occurrence of defined prefixes when it receives a NAMES reply from server. This includes every usermodes set, plus the @ between ident and ip/host will increase the op count as well. With traditional NAMES responses, this hasn't been an issue.

It's not as much a bug as it is something PnP just wasn't designed to do. Nevertheless, it is still a problem that can - and should be - addressed with a script fix. With PnP no longer in active development, such fixes depends on being submitted by the community.




if ((you tried a solution from these forums) AND (no one else has verified it)) { Please comment if it works. }
- WildCraze, using mIRC v7.52
View user's profile View All Posts By User
craze
Administrator
********




Posts: 19
Registered: 9-10-2008
Member Is Offline


[*] posted on 17-1-2009 at 14:36


I've been experimenting with a workaround, which seems to work for me. If anyone would like to try this and post some feedback, I'd appreciate it.

Using the mIRC remote editor, replace
Code:
hinc pnp. $+ $cid -namec. $+ $mid($prefix,%num,1) $count($4-,$mid($prefix,%num,1))
in rawdisp.mrc line 803 with
Code:
hinc pnp. $+ $cid -namec. $+ $mid($prefix,%num,1) $count($+($chr(32),$4-),$+($chr(32),$mid($prefix,%num,1)))


This workaround works by only counting the prefix if the character in front is a space. It does reintroduce the "issue" with a person only being counted with their highest mode even if (s)he has more than one of op/halfop/voice set.

Good luck! d-(",)z

[Edited on 17-Jan-2009 by craze]




if ((you tried a solution from these forums) AND (no one else has verified it)) { Please comment if it works. }
- WildCraze, using mIRC v7.52
View user's profile View All Posts By User
black_ps
Junior Member
**




Posts: 3
Registered: 8-1-2009
Member Is Offline


[*] posted on 17-1-2009 at 17:21


ok tks , i'll give it a try
View user's profile View All Posts By User

  Go To Top

Powered by XMB
XMB Forum Software © 2001-2012 The XMB Group