Forums Scripts & Popups need help with a script D:

hello all, it's been years since i've used mIRC and i want to use it again for my twitch stream. i forgot A LOT of what i already knew (i'm so sad) but for now i just need a simple script for a twitch chatbot command that people can type a command and it'll give them a random word from a .txt file list of words on my pc. for example, they would type !word and it'll respond with a random word from that file. i'm not too sure how to do that anymore, been trying to figure it out since late last night

Try using this:

The simplest way would be to use the $read() identifier within an on TEXT event — for instance: ... where your_channel_here and path_to_words_list_file_here.txt would be replaced appropriately; assuming your file is comprised of a list of single words per line, this simple one-command event script should do what you're asking. Since you seem to've hinted that you at one point used to have some scripting knowledge, I'll give a quick in-depth breakdown of what's happening to try to refresh your memory, starting from the inside out:

- The $read() identifier will return a random line from a file so long as you don't use a scanning type switch in the second parameter — i.e., r, s, or w.

- The n switch acts as a safety feature by preventing mIRC from attempting to evaluate any potential identifiers or variables within the line, instead treating the line as plain text.

Unless you know what you're doing and have a very good reason not to, you should always supply $read() with the n switch. (Why attempting to evaluate a line rather than assuming plaintext is the default behavior, I'll never know, but unfortunately it's far too late at this point to have it changed.)

- The t switch is less about safety, and instead simply forces mIRC to assume the first line is text, even if it happens to be a number. Without this switch, if the first line does happen to be a number, mIRC will assume that that is the number of lines in the file instead.

Note that case matters for command and identifier switches — N and T would not be the same as n and t.



- The /msg command (written here without the leading / since mIRC assumes all lines within a script are commands when appropriate) is a command built into mIRC that sends a message to the target specified in the second parameter, whether that be a channel or a nickname. In this case, the target is #, which just serves as a shorthand for the channel from which the event was triggered. (You may also see the unparameterized $chan identifier used instead in other scripts, which achieves the same result.)

- The ! prefix in front of the command forces mIRC to use the built-in version of a command in the event that an alias exists to otherwise overwrite that command. For most casual scripters who only ever use their own personally-written scripts, this prefix probably isn't strictly necessary, but it certainly doesn't hurt to use it whenever possible, and can act as a small safety feature of sorts. Naturally, this prefix cannot be used with your own custom-written commands.



- The { } braces around the commands (or in this case, the command) comprising the body of the event groups those commands together. In this example's case, the braces are optional, as the script could simply be written on a single line as such: ... although I would recommend using the braced version instead as it is easier to extend and, imo, easier to read. (In fact, command-grouping braces are quite often technically optional thanks to mIRC's | command-separation operator — e.g., something like: ... could be written as: ... but as the default, I would again strongly recommend just using braces and placing each command on its own line, even in cases where a group is comprised of a single command, as this is, imo, far easier to read, maintain, and extend.)

- One other thing to note about braces is that unlike many other similar programming and scripting languages, the opening { brace cannot* appear on a line on its own in mSL, and instead must appear at the end of the thing to which the commands are being grouped. In cases where the delimiting and terminating character of that thing is a : (colon), such as an event header or menu item, a space before the brace is optional — i.e., it can be touching the closing :. With a control flow statement like an if (...), elseif (...), else, or a while loop, however, a space must be present before the brace. For consistency and readability, I would personally recommend just always placing a space before any opening braces.



- As I've hinted at above, the parts of the event header — in this case, on *:TEXT:!word:#your_channel_here: — are primarily delimited/separated by : characters.

- The on at the beginning of the header simply denotes this line as the beginning of a remote event, and can be interpreted as something like "on the event that X occurs..., do Y". Though this may seem like a silly technicality, you may see some people attempt to "disable" a remote event by replacing the word on with off. While this technically does "work" in a sense, the reason it does is because mIRC will see that as a syntax error, and consequentially ignore the entire script belonging to that event header. If you do wish to enable or disable a script at will, there are facilities for that which won't result in syntax errors and will allow you to do so without modifying the script file itself - namely groups, which you can learn more about by using /!help Groups in mIRC, or searching for Groups in the help file.

- The * before the first : represents the access level needed for a user to trigger an event. In this case, * indicates that any user can trigger the event, regardless of their access level, and in my experience will be by far the most common type of access level. If you're interested in more specialized access-level based control of your events, you can use /!help Access Levels in mIRC, or simply search for Access Levels in the help file. It should be noted that access levels are completely independent of the mode of a user on a channel or network, so if you want to limit an event to, say, channel operators, you will need to do so via other means, such as an if (...) statement utilizing the isop operator.

- The TEXT between the first and second :s, as the name would suggest, identifies the event as an on TEXT remote event. The name of an event, as with most things in mSL, is case-insensitive (i.e., can be written in UPPERCASE, lowercase, or any combination of the two), but by convention, you will most likely see it written in all uppercase letters.

- The !word between the second and third :s represents the matchtext need to trigger an event. In this case, the line must consist of !word, and only !word (case-insensitively), in order for the event to trigger. If you wanted to allow for other text to appear before or after the !word while still triggering the event, you could use the ?, &, and * wildcard characters to represent a single character, word, or arbitrary text respectively. For even finer control, the matchtext can be written as a regular expression (often abbreviated regex) in conjunction with the $ event prefix, though regexes can be complicated, so I won't go into detail about them just yet. Just know, however, that they do allow you to easily check for case-sensitivity of a matchtext trigger, in case that's important to you, as well as provide a means for allowing an event to trigger irrespective of any control code formatting used in the line (which in the case of Twitch would probably be a non-issue, but still...)

- The #your_channel_here, as should be obvious, represents the target, or location from which an event can be triggered - in this case, the target would be exactly #your_channel_here, so as I've stated above you should replace that portion with the actual name of your channel (keeping the # prefix). Other target types include the standalone # to represent any channel, ? to represent your queries/DMs, or * to represent any valid target. You can also list multiple targets by separating them with , commas.



As a general rule of thumb, you should always aim to make your scripts as specific as possible, and avoid generic "master events" such as on *:TEXT:*:#: unless you have a very specific necessity to do so. This specificity-oriented approach is far more maintainable and flexible, as it will allow you to add other events of the same type to the file in the future, and will help to ensure that mIRC isn't attempting to trigger and perform an event's commands unnecessarily. It also saves you a nesting level.

Please be aware, also, that the versions of the script provided above do not have any kind of flood protection built into them, and the best you could hope for would be for them to somehow trigger mIRC's internal flood-protection system (which they very well might not). If you did want to provide flood protection, a very basic implementation might look something like: ... which, after performing the command to read and send a random line from path_to_words_list_file_here.txt to #your_channel_here (again, replace accordingly), would use the /hadd command to create a hash table (a type of associative data structure whose details are unimportant at this time) called floodprot on the fly via the m switch of the - prefixed first parameter, with a key-value pair / "item" consisting of the key global and the value 5. This value will then automatically be decreased via the z switch until it reaches 0, after which the item will automatically be deleted from the hash table.

If the global item of the floodprot hash table already exists when the event gets triggered, then the if ($hget( floodprot , global )) guard clause, in conjunction with the /return command, will force mIRC to exit the event early, preventing the aforementioned "read and send" and "start flood protection" portions of the event from being executed at all.

One final thing to note about this example is that the ! prefix before the if is strictly unnecessary, as if is a keyword which cannot be overwritten by an alias anyway. I like to include it anyway for personal preference, as it helps to keep things a little more visually aligned, but whether or not you do so is entirely up to you.



Anyway, I realize that this might be a bit of a lengthy read, but hopefully I've provided enough information to help you get back into mIRC scripting . If you need any other help or have any questions with anything I've written here, just let me know, and I, or someone else, will surely do our best to assist.



* technically, you can emulate this in a sense by using the $& operator, but it will mess with the indentation of the brace, which for most people would probably defeat the purpose of putting it on its own line anyway.