| View previous topic :: View next topic |
| Author |
Message |
paulm Voice
Joined: 28 Aug 2007 Posts: 7
|
Posted: Fri Oct 05, 2007 1:58 pm Post subject: New hostmask set by setuser doesn't seem to be recognized |
|
|
Hi,
I got a problem adding hostmasks using setuser.
Once my script verified that a user is authed to Q, all hosts associated with the user are cleared (I call "setuser <user> HOSTS" without argument) and sets two new hosts (using setuser). When I do a ".match user" the hosts seem to be set correcty. But eggdrop doesn't seem to recognize them (e.g. it isn't autovoicing the user).
Funny thing is: When I add one of the two hosts manually using ".+host" eggdrop suddenly recognizes the user.
Is there a need to commit the changes of HOSTS using setuser or what else is wrong?
paulm |
|
| Back to top |
|
 |
TCL_no_TK Owner

Joined: 25 Aug 2006 Posts: 509 Location: England, Yorkshire
|
Posted: Fri Oct 05, 2007 3:14 pm Post subject: RE: New hostmask set by setuser ... |
|
|
Try re-reading the information from the server, can be done via .resetchan #channel or making the bot cycle. This isn't usally a problem, but sometimes the bot can be desynced. And if all else fails, just have the user cycle  _________________ TCL the misunderstood |
|
| Back to top |
|
 |
paulm Voice
Joined: 28 Aug 2007 Posts: 7
|
Posted: Fri Oct 05, 2007 4:49 pm Post subject: |
|
|
The problem occurs regularly so doing a resetchan every time isn't an option.
This is the routine für Raw330, could you have a look at it?
| Code: |
proc whois {from key text} {
set nick "[lindex $text 1]"
set auth "[lindex $text 2]"
foreach listnick [userlist *] {
if { $auth == [getuser $listnick XTRA QAUTH] } {
setuser $listnick HOSTS
if { [string trimleft [getchanhost $nick] ~] != "" } {
setuser $listnick HOSTS *!*[string trimleft [getchanhost $nick] ~] }
foreach host [getuser $listnick XTRA STATICHOSTS] {
setuser $listnick HOSTS $host
}
setuser $listnick HOSTS *!*@$auth.users.quakenet.org
break
}
}
}
|
|
|
| Back to top |
|
 |
nml375 Revered One
Joined: 04 Aug 2006 Posts: 2857
|
Posted: Fri Oct 05, 2007 5:47 pm Post subject: |
|
|
Apart from using lindex on strings rather than lists, the code seems proper enough.
Just to clarify; does your bot list the user as recognized in .channel output after the host-update?
Your bot will not voice the user upon entering the channel, or after the host-update?
Also, I'm not familiar with the 330 raw numeric... _________________ NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
 |
paulm Voice
Joined: 28 Aug 2007 Posts: 7
|
Posted: Fri Oct 05, 2007 6:55 pm Post subject: |
|
|
k, I will consider switching to lists - thanks for the hint!
The user's nickname is shown as associated with eggdrop's handle when I perform ".channel". But although the channel is "+autovoice" and other users get autovoiced the users that are recognized by Quakenet authentication through my script don't get these rights.
Whenever someone joins I do a whois on the nickname. Raw330 occurs when a whois on the nickname results in some positive Quakenet authentication. So the routine is called some time after the user joined the channel.
As I said, althoug the HOSTS information is shown correctly when I ".match" the handle it won't be recognized until I re-add one of the hostmasks using the ".+host" command on the partyline.
edit: typo |
|
| Back to top |
|
 |
paulm Voice
Joined: 28 Aug 2007 Posts: 7
|
Posted: Sat Oct 06, 2007 6:05 am Post subject: |
|
|
Here some further info:
When I create a new user, the user record looks like this:
| Code: | [11:22][0t(dcc)] dadida no 0 - never (nowhere)
[11:22][0t(dcc)] #channel v never
[11:22][0t(dcc)] QAUTH: dadida
|
After joining the channel the HOSTS are set correctly by my script:
| Code: | [11:23][0t(dcc)] HANDLE PASS NOTES FLAGS LAST
[11:23][0t(dcc)] dadida no 0 - never (nowhere)
[11:23][0t(dcc)] #channel v never
[11:23][0t(dcc)] HOSTS: *Miranda@p5498EF15.dip.t-dialin.net
[11:23][0t(dcc)] *!*@dadida.users.quakenet.org
[11:23][0t(dcc)] QAUTH: dadida
|
When I do a ".channel" the user is being displayed with the 'v':
| Code: | [11:24][0t(dcc)] NICKNAME HANDLE JOIN IDLE USER@HOST
[11:24][0t(dcc)] dadida dadida 11:22 v 2m ~Miranda@p5434EF43.dip.t-dialin.net
|
The channel itself has +autovoice (working on other users with fixed hosts) but user "dadida" isn't autovoiced.
Disturbingly, when I manually do a ".+host dadida *Miranda@p5498EF15.dip.t-dialin.net" (the same mask as already in HOSTS) he suddently gets voiced by the bot. |
|
| Back to top |
|
 |
nml375 Revered One
Joined: 04 Aug 2006 Posts: 2857
|
Posted: Sat Oct 06, 2007 7:31 am Post subject: |
|
|
Well, whenever .channel output shows the correct handle, it basically means that your eggdrop does indeed recognize him/her.
However, as I recall, adding hosts through the setuser interface won't cause a new scan for auto-op/auto-voice. _________________ NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
 |
paulm Voice
Joined: 28 Aug 2007 Posts: 7
|
Posted: Sat Oct 06, 2007 7:46 am Post subject: |
|
|
| nml375 wrote: | | However, as I recall, adding hosts through the setuser interface won't cause a new scan for auto-op/auto-voice. |
This seems to be case. So the HOSTS part of setuser is pretty useless atm at least for auto-opping/-voicing
So I'll add the auto-* myself in the routine because doing a reset on the channel every time would cause quite a lot of traffic and is oversized...
btw: Did you notice that the LAST entry of the .match output says "Never" whereas the JOIN entry of .channel sows the time the user joined? eggdrop seems to be schizophrenic as on part of him knows that the user once joined the channel and the other part denies it.  |
|
| Back to top |
|
 |
nml375 Revered One
Joined: 04 Aug 2006 Posts: 2857
|
Posted: Sat Oct 06, 2007 9:01 am Post subject: |
|
|
Not quite, it's part of the same mechanics...
The join-time is tracked on a "person-basis", while the Last-seen field is directly tied to the handle. And last seen is also pretty much only updated on events such as join/part/quit/kick/etc.
Ideal? Probably not, but been way too long since I dug into that part of the code :p _________________ NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
 |
|