- /** Adds an extended mode letter which is parsed by a module and handled in a list fashion.
- * This call is used to implement modes like +q and +a. The characteristics of these modes are
- * as follows:
- *
- * (1) They are ALWAYS on channels, not on users, therefore their type is MT_CHANNEL
- *
- * (2) They always take exactly one parameter when being added or removed
- *
- * (3) They can be set multiple times, usually on users in channels
- *
- * (4) The mode and its parameter are NOT stored in the channels modes structure
- *
- * It is down to the module handling the mode to maintain state and determine what 'items' (e.g. users,
- * or a banlist) have the mode set on them, and process the modes at the correct times, e.g. during access
- * checks on channels, etc. When the extended mode is triggered the OnExtendedMode method will be triggered
- * as above. Note that the target you are given will be a channel, if for example your mode is set 'on a user'
- * (in for example +a) you must use Server::Find to locate the user the mode is operating on.
- * Your mode handler may return 1 to handle the mode AND tell the core to display the mode change, e.g.
- * '+aaa one two three' in the case of the mode for 'two', or it may return -1 to 'eat' the mode change,
- * so the above example would become '+aa one three' after processing.
- */
- virtual bool AddExtendedListMode(char modechar);
-
- /** Adds a command to the command table.
- * This allows modules to add extra commands into the command table. You must place a function within your
- * module which is is of type handlerfunc:
- *
- * typedef void (handlerfunc) (char**, int, userrec*);
- * ...
- * void handle_kill(char **parameters, int pcnt, userrec *user)
- *
- * When the command is typed, the parameters will be placed into the parameters array (similar to argv) and
- * the parameter count will be placed into pcnt (similar to argv). There will never be any less parameters
- * than the 'minparams' value you specified when creating the command. The *user parameter is the class of
- * the user which caused the command to trigger, who will always have the flag you specified in 'flags' when
- * creating the initial command. For example to create an oper only command create the commands with flags='o'.
- * The source parameter is used for resource tracking, and should contain the name of your module (with file
- * extension) e.g. "m_blarp.so". If you place the wrong identifier here, you can cause crashes if your module
- * is unloaded.
- */
- virtual void AddCommand(command_t *f);
-
- /** Sends a servermode.
- * you must format the parameters array with the target, modes and parameters for those modes.
- *
- * For example:
- *
- * char *modes[3];
- *
- * modes[0] = ChannelName;
- *
- * modes[1] = "+o";
- *
- * modes[2] = user->nick;
- *
- * Srv->SendMode(modes,3,user);
- *
- * The modes will originate from the server where the command was issued, however responses (e.g. numerics)
- * will be sent to the user you provide as the third parameter.
- * You must be sure to get the number of parameters correct in the pcnt parameter otherwise you could leave
- * your server in an unstable state!
- */
-
- virtual void SendMode(char **parameters, int pcnt, userrec *user);
-
- /** Sends to all users matching a mode mask
- * You must specify one or more usermodes as the first parameter. These can be RFC specified modes such as +i,
- * or module provided modes, including ones provided by your own module.
- * In the second parameter you must place a flag value which indicates wether the modes you have given will be
- * logically ANDed or OR'ed. You may use one of either WM_AND or WM_OR.
- * for example, if you were to use:
- *
- * Serv->SendToModeMask("xi", WM_OR, "m00");
- *
- * Then the text 'm00' will be sent to all users with EITHER mode x or i. Conversely if you used WM_AND, the
- * user must have both modes set to receive the message.
- */
- virtual void SendToModeMask(const std::string &modes, int flags, const std::string &text);
-
- /** Forces a user to join a channel.
- * This is similar to svsjoin and can be used to implement redirection, etc.
- * On success, the return value is a valid pointer to a chanrec* of the channel the user was joined to.
- * On failure, the result is NULL.
- */
- virtual chanrec* JoinUserToChannel(userrec* user, const std::string &cname, const std::string &key);
-
- /** Forces a user to part a channel.
- * This is similar to svspart and can be used to implement redirection, etc.
- * Although the return value of this function is a pointer to a channel record, the returned data is
- * undefined and should not be read or written to. This behaviour may be changed in a future version.
- */
- virtual chanrec* PartUserFromChannel(userrec* user, const std::string &cname, const std::string &reason);
-
- /** Forces a user nickchange.
- * This command works similarly to SVSNICK, and can be used to implement Q-lines etc.
- * If you specify an invalid nickname, the nick change will be dropped and the target user will receive
- * the error numeric for it.