mIRC Scripting Tips and Tricks |
|
|
This page was created to give scripters a simple guideline to follow when making a script. These tips are not required, but are only suggestions that could greatly improve your script. When used correctly, these tips could help your script earn a higher score at Hawkee.com. Some of these are just common sense, but are frequently overlooked. general scripts  customize It's a good idea to give the user maximum configurability in all aspects of your script. Try not to let your personal preferences get in the way when designing your script. Not everybody has the same opinion. Give the user an easy to use setting window where he/she may change around various aspects of your script. file locations Before using any file, ie: wav, mid, bmp, etc, always make sure it exists. If the file doesn't exist, give the user some sort of error if necessary. I've come across many scripts that give me errors like: * /splay: no such file 'sound.wav'. It may be a good idea to use $findfile to search for the file in case the user misplaced it. If they did, use the rename command to move it to the appropriate place. variable names Try to begin all of the variables to a certain section of your script with the same letters. If you are making a poker script, try %poker.variable.name instead of %variable.name for all your vars. This makes it easier to unset all of the variables your script was using when it is done. long term values When your script has settings that the user adjusts, try not to use variables. Use an ini file with the $readini and writeini commands to change and get settings for your script. This keeps the variable section from filling up too fast. Treat variables as only temporary storage units and not long term values. parsing .ini files Always use -n when you call the $read or $readini commands unless you want the text to be parsed by mIRC. A frequent error is when -n is forgotten when reading away logs. Somebody may say something or send you a command that you do not want parsed. personal material When releasing your general script, try to make sure you have removed any personal material before zipping it up. I commonly find log files or personal settings that shouldn't have been included with the script. help sections Always provide easy access to the help section of your script. When the user doesn't know what a popup means, make sure a popup for help is near by. It's always good to include help on every option of your script. looping alternative When your script includes a loop that causes mIRC to lock up for any amount of time, it may be good to consider using ".timer -m 1 1 somefunction". With this, you can increment a variable each time 'somefunction' is called and stop the timer once the loop is complete. This will not cause mIRC to lock up. no /who on join Do not write your script to automatically run a /who every time you join a channel. If multiple scripts were to do this, you will be flooded off the server. Instead, check $chan(#).ial to see if another loaded script has sent the /who or not. If this returns $false, you may then send your /who request. echoing text When your script echo's text, it is a good idea to always use the $colour() function. You never want to assume that the user has any specific background color. Using "echo $colour(text) -a" is a good way to avoid any white on white or black on black conflicts. closing colors It is always a good idea to close a color using only the control+k character. For example: "/msg #channel blah 3blah blah" will show the first and last blah's in the default text color while the middle is shown in color 3. This is better than using "/msg #channel blah 3blah1 blah" where you're assuming the user's text color is black for the remaining blah. use $scriptdir Always use $scriptdir rather than $mircdir when writing your scripts. When you need to load a .bmp or another .mrc file, you do not want to assume the user extracted your script to the mIRC directory. text themes It is a good idea to use "on &^*:" for halting text so that you do not conflict with any other themes that may be loaded. Using the "&" character will cause mIRC to ignore your event if another event has already halted the text. background themes If your script loads up background pictures, make sure you save the previous background settings so that the user can regain his/her original settings if necessary. Note: It's always good to include an unload option for your theme. popup menus dynamic popups When a menu option can change, it's a good idea to use an alias or variable under your menu declaration. For example: For nicklist op controls, use something like $opcontrols which returns either "Op Controls" if you're opped or $null if you aren't. This way the user won't see an option to op another user when they cannot do it. multiple menus If you want your window to use multiple menus, you may change the menu while the window is loaded. For example: You have an FTP window open and there are two different menu sets (@online and @offline). You can change the popups from @offline to @online by using "/window @window_name @online". overabundance Try not to use more popups than are necessary. When an option can be switched on or off, use only one popup that dynamically changes according to whether or not the option is "on" or "off". This can be accomplished by either using an alias or a variable for the popup name. general popups When creating a general script, try not to use the popups section any more than is necessary. When the user disables a certain part of your script by unloading it, unload the popups with it (ie: use menu declarations inside the relevent .mrc file). multiple popups When you want to use the same popup menu for various locations, do not copy and paste the menu under each header. You may use "menu status,channel,query {" to make the menu appear in each of the given locations. no "mass" popups Rather than including an entire section in your popup menus for "mass" options, simply use $* under your normal popups. For example: Op:mode # +o $* will op a single person or any number of selected persons. custom windows positioning It my be a good idea to save the position of every window your script uses with the "on close" event. If the size of your window can be adjusted, reopen it with the last size it was opened at. Note: always keep a default value in case the values are lost. monitor resolution It may be a good idea to determine the user's resolution before displaying a window. You can acquire their resolution with $window(-1).h and $window(-1).w. This information can help you place your window in the center of the screen no matter what resolution the user has. control buttons Don't give the user more power than they need. If your window does not display properly when it is maximized, take away the maximize option. If it does not resize properly, remove the resize option. picture windows rgb colors When drawing to a picture window, always try to use RGB colors instead of the normal 16 colors mIRC provides. People change the default colors, and this may give your script the wrong appearance when you asked for 4 (default red) and the user has it set to blue. 256 colors Try not to use RGB colors beyond the 256 color range. Make sure your script looks right under this setting. Many colors may appear speckled under the 256 color setting, so it's always a good idea to use solid colors. Note: If you use a color that falls under the true color range, it may contain many different colors, so $getdot may not always return the same value in a field of a single color. bitmaps Be reasonable with bmp's. Don't include a bmp with your script that can be drawn to a window in just a couple lines of code. I would much rather have a 20k .mrc file than a 10k .mrc file and 20 bmp's to go with it. sockets wildcards Never use wildcards such as "on 1:sockread:*:" in your script. You may grab information that another loaded script is using and trash it before the other script gets to it. Always use a name specific to your script when reading from sockets as to avoid conflicts. Using "on 1:sockread:Sockname*:" is fine as long as "Sockname" is specific to your script. new line You will almost always want to use the -n parameter in the /sockwrite command so it'll append a new line character to the text your sending. Most servers will only deal with the information you send it when it has read in a new line character. This is important for creating scripts for email, IRC, web browsing, etc. |
|