Usage: CLIENT <class> SET ALTWELCOME [on|off]
When logging onto the server you are sent an alternate welcome. The standard message says Welcome to the IRC Network while the alternate message says Welcome to the ConferenceRoom server.
/as client WebMaster set altwelcome on.
Which welcome message you prefer is up to you; it just gives you an additional option.
This command allows you to set a default channel that all members of the specified client class will automatically join when they log into the chat server.
/as client WebMaster set limit 100
Very nice command when used with host matching to allow you to specify default channels for groups to automatically join.
This command allows you to lock clients into specific channel masks. Using this method you can use an NNTP like naming structure to do:
Adding those two masks means that clients will only be able to join any channels that are under #news. and #entertainment. like #news.lobby or #entertainment.shows o #entertainment.event
/as help client set chanlock <channel>
This command set is nice to add a structure to your channel naming conventions.
This setting will relax the flood limits imposed by a multiplier that is set. The multiplier allows server administrators to configure client classes to have a higher flood ration than that of other client classes on the server.
/as client WebMaster set flood 2
You may wish to have certain clients have immunity from harsh flood control settings. A good example are triva or informational bots that are in a multitude of channels.
This command allows you to set a host override that can bypass the channel lock command.
/as client WebMaster set hostoverride <channel>
Nice for hosts that you want to be able to traverse multiple chanlock sets.
This will set the default language used by all memembers of the specified client class. To use the server default just enter the command with no language specified and the default language will be set.
/as client Z-default set lang en /as client Z-default set lang
You can find out more information about multiple language support by going to the LANGUAGE help pages.
This command limits the number of clients that can connect with this profile. Warning: If you do not have any other profiles defined then the number set will be the maximum number of users allowed on the server. You will probably want your z-default to allow as many connections as you can, but remember if a client hits an earlier limit, then they cannot get onto your network.
/as client WebMaster set limit 100
You can use this to limit certain types of users so that other preferred users are more likely to be able to connect. Or you could set your z-default to a smaller value than your total allowed client amount. Then you can have an earlier profile allow on your full amount so that people in that profile can always connect since space is reserved for them. You'd want to place your profiles and set your limits carefully to arrange that.
When this option is turned off clients connecting through this profile will not be sent the information found in a /lusers command when they connect.
/as client WebMaster set lusers on
The lusers info may be considered interesting and useful to some users, but if the motd is long then shortening what is sent to the user upon connecting is probably a good idea. If the motd is very short then the lusers info may give it more of a feel of fullness.
This option will set a specific mode on a client when they log onto your server. To view all the modes available for a client please refer to the user modes section listed in server commands for all users.
/as client Z-default set mode +ix
This becomes a user's starting modes. They can alter them as they choose, except in ways that conflict with a modelock. It is a good idea to start users with a general set of modes that most of them will like. This gets new users started well, and they won't change their modes until they know enough to do so deliberately. On large networks you will probably want to include +i and +x as part of the initial mode. These modes help protect people from spam or other annoyances. Other good modes to consider are +w, if your network tends to send useful information through wallops and +L if you prefer your users to start off with profanity filters.
Much like the MODE option but this locks modes for the clients. This means that a user cannot remove the modes specified for that client class. For example, if you don't want users to be able to see wallops, you could modelock them -w.
/as client z-default set modelock +ix-ws
Modelocks are useful when you want to restrict some or all of your users. If you don't want your users able to turn off host mask munging (+x) then you can mlock it for them. Network operators can change their modes despite whatever modelock might apply to their client class. This means that mlocking something like -w, turns them into an oper-only mode.
When this option is turned off clients connecting through this profile will not be sent a MOTD. Warning: Several clients use the MOTD to trigger their scripts.
/as client WebMaster set motd on
The advantage to turning off the message of the day is that the greeting upon login will be significantly shorter. They can still view the message of the day by using the /motd command.
When set to on this will allow multiple connections from the same hostname. Unix systems quite often have numerous users on the same system. If this option is off only one user from that system will be able to gain access to the server. However, when off it will also limit the number of clones that abusive users can load onto the system. Unlimited (or 0) is the default setting.
/as client WebMaster set multi 20
The reason to keep multi set to 0 (unlimited) is that several people may have a legitimate reason for multiple logins from the same host. The most common being unix systems or cybercafes. But even without this, an extra login is not always a problem. Sometimes someone may want two clients actively chatting. Or they may be running a non-harmful bot. Several people code bots that can run on chat networks and provide amusement. Some typical examples are bar bots that serve virtual food and drink and may say amusing things and trivia bots that can let people play simple games. The people running the bots may then also want to log on as themselves to chat. The benefit to not allowing multiple connections is that you avoid the possibility of clones. You prevent people from wasting connections with unnecessary extra clients. Whether it is worth it will depend on the particular users you tend to have. You can always add a special client class for addresses that tend to need replicas, although this requires more maintenance.
This will lock your server access to anyone who doesn't have the password. In order to connect to your server with most clients users would have to type the following sequence (assuming port 6667 is enabled for your server) /server your.server.name:6667 thePassword. If they do not but match a later non-password protected entry, then they will be able to login with that client class.
/as client z-default set password bleh
With some clients you will need to use a graphical user interface to log in and they may have a field for the password. If that is the case, try logging in using the interface. Some clients may not be able to handle the command properly; so do not use password protected client classes unless you are sure the intended users can access them. When using the text command, make sure to include the port number. While the port is usually not mandatory, if you exclude it then the password will be in the port field, and the login will fail. Password protected client classes allow you to only allow people who know a particular pass to log into your server. This can be used as a security measure to restrict users to those whom you choose, without having to add a mask for each of them. You can also use it if you wish to allow on any java user, but only allow non-java users that you specifically approve. Or your regular clients can be limited to one login per address, but special exceptions can be given a password to log in with. Another possible use is that the main client class can be limited to fewer users than the server can handle, and a password protected earlier client class can have a large number of allowed users. Then these users will have a better chance of being able to log in if your server tends to fill up. Even if the main client class is full, there will be reserved spots for those with the password. Just remember that to use a client class the user must match both the password and a mask set for the class.
The time interval between pings sent to all clients that connect using the specified profile.
/as client WebMaster set ping 90
You probably shouldn't change the ping time without a good reason. The server sends pings to every client to make sure that they are still connected. Sometimes a user's client, computer, or network connection will crash without logging off of the chat network. This creates what is known as a ghost. The server will send pings and if it does not get a pong reply after a suitable wait, it will disconnect the client assuming it to be a ghost. Too high a ping time will flood the client by constantly asking it to reply and may lag users. Too low a ping time will leave ghosts on the network far longer.
This option allows you to specify which type of user you want to be able to join this client class. You can set it to java only or on for all clients.
/as client WebMaster set restricted on
/as client WebMaster set restricted off
As stated under password, if you want to restrict most of your users to the java client, you can make a restricted client class as your z-default client class and add specific exceptions higher up. You can also have this before the z-default if you want java clients to have different settings than other users.