If you want your window to use multiple menus, you may change the menu while the window is loaded. This way the user won't see an option to op another user when they cannot do it. 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. When a menu option can change, it's a good idea to use an alias or variable under your menu declaration. Note: It's always good to include an unload option for your theme. 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. Using the "&" character will cause mIRC to ignore your event if another event has already halted the text. 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. mrc file, you do not want to assume the user extracted your script to the mIRC directory. 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.Īlways use $scriptdir rather than $mircdir when writing your scripts. 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. It is always a good idea to close a color using only the control+k character. Using "echo $colour(text) -a" is a good way to avoid any white on white or black on black conflicts. You never want to assume that the user has any specific background color.
When your script echo's text, it is a good idea to always use the $colour() function. If this returns $false, you may then send your /who request. Instead, check $chan(#).ial to see if another loaded script has sent the /who or not.
If multiple scripts were to do this, you will be flooded off the server. This will not cause mIRC to lock up.ĭo not write your script to automatically run a /who every time you join a channel. With this, you can increment a variable each time 'somefunction' is called and stop the timer once the loop is complete. 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". It's always good to include help on every option of your script. When the user doesn't know what a popup means, make sure a popup for help is near by. I commonly find log files or personal settings that shouldn't have been included with the script.Īlways provide easy access to the help section of your script. When releasing your general script, try to make sure you have removed any personal material before zipping it up. Somebody may say something or send you a command that you do not want parsed. A frequent error is when -n is forgotten when reading away logs. Treat variables as only temporary storage units and not long term values.Īlways use -n when you call the $read or $readini commands unless you want the text to be parsed by mIRC. This keeps the variable section from filling up too fast. Use an ini file with the $readini and writeini commands to change and get settings for your script.
When your script has settings that the user adjusts, try not to use variables. This makes it easier to unset all of the variables your script was using when it is done. If you are making a poker script, try % instead of %variable.name for all your vars. Try to begin all of the variables to a certain section of your script with the same letters. If they did, use the rename command to move it to the appropriate place. It may be a good idea to use $findfile to search for the file in case the user misplaced it. I've come across many scripts that give me errors like: * /splay: no such file 'sound.wav'. If the file doesn't exist, give the user some sort of error if necessary. Give the user an easy to use setting window where he/she may change around various aspects of your script.īefore using any file, ie: wav, mid, bmp, etc, always make sure it exists. Try not to let your personal preferences get in the way when designing your script. It's a good idea to give the user maximum configurability in all aspects of your script. Some of these are just common sense, but are frequently overlooked. When used correctly, these tips could help your script earn a higher score at. These tips are not required, but are only suggestions that could greatly improve your script. This page was created to give scripters a simple guideline to follow when making a script.
0 kommentar(er)
