Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[katsklaw]

What is the reason that ns update does not emit EVENT_NICK_IDENTIFY?? I mean ns update is a sync tool is it not?

[Jobe]

EVENT_NICK_IDENTIFY means the user identified to his/her nick. Where ns update only updates channel modes relating to the users access and requires the user has ALREADY identified. So for this reason ns update is NOT the same as ns identify.

[katsklaw]

no, ns update does more than just update channel modes, it also does flags, memos, vhost as well as chmodes. So it basiclly resyncs everything else. There is no harm in sending EVENT_NICK_IDENTIFY as well so 3rd party modules can hook ns update as well.

What triggered the question is I'm workning on a db driven UmodeOnID system that allows ServicesAdmins to set usermode that are given upon ID. It would be helpful for that to be resynced during ns update just like NSModeOnID is. I'm sure there are other things that could benefit as well.

[Jobe]

To be honest I disagree with firing EVENT_NICK_IDENTIFY on ns update. It would be far better (and safer for existing modules) if a new event were created.

[Adam]

An event for /ns update does exist and has existed since very early 1.9 development.. and no we don't change 1.8s behaviour and modules expect certain events to be called at certain times and not others.

[Jens Voss]

in 1.8 you can bind to the identify and update command with MOD_TAIL to execute your code.

example:

Code: [Select]


#include "module.h"

int do_on_identify(User *u)
{

    /* stop if nick is not identified */
    if (!nick_identified(u))
    {
          return MOD_CONT;
    }

   
    /* this is a good place */
    /* to add your code     */

    return MOD_CONT;
}


int AnopeInit(int argc, char **argv)
{
   Command *c;   

   c = createCommand("IDENTIFY", do_on_identify, NULL, -1, -1, -1, -1, -1);
       moduleAddCommand(NICKSERV, c, MOD_TAIL);
   c = createCommand("ID", do_on_identify, NULL, -1, -1, -1, -1, -1);
       moduleAddCommand(NICKSERV, c, MOD_TAIL);
   c = createCommand("UPDATE", do_on_identify, NULL, -1, -1, -1, -1, -1);
       moduleAddCommand(NICKSERV, c, MOD_TAIL);

  return MOD_CONT;
}

Because we have already a working solution I dont see any reason to add an additional event to the update command.

[katsklaw]

None of that actually answered my question.

Perhaps its time for me to just fork 1.8 and skip all the red tape.

thanks.

[culex]

Perhaps its time for me to just fork 1.8 and skip all the red tape.

Yes, please. If you think you can do better than the Anope team, please do.

[katsklaw]

Yes, please. If you think you can do better than the Anope team, please do.

Lol! Actually "fork" is the wrong term. What I meant is i'll just edit the source to my needs and not worry about it. It will also save me from creating the module and just make the changes to the core directly.

No, my statement wasn't a claim of being able to do better nor will my modified version be available to the public.