Forums Scripts & Popups Audio Highlight Issues

For reasons beyond my understanding, employing built-in Audio Highlight has never worked consistently for me. To further bewilder me, as of right now, the methods I have tried to rectify this in script form have not worked either. These methods are:


Alert works perfectly fine when I actually type /alert, but apparently whenever someone says the alert text, it doesn't actually /alert. All my other remotes work perfectly fine, but for some reason this one absolutely refuses to do so. I've written remotes before and this is no different so I can't figure out what the problem could possibly be.

I believe you need to make an alias for this one:

Well, Alert IS an alias, it's in the aliases section, unless you are referring to an alias that goes in the remotes section, the likes of which I am not familiar with. That's what is so perplexing; it's still not working.

Yes, I was referring to the remote alias. But your case seems odd to me, because I put in my mirc's aliases, while the music.wav is in the folder called sounds at my mirc's directory, it worked for me without an issue...as well as adding the on text event in my remote: I had someone typed in textgoeshere in the channel and I heard the sound loud and clear.

Sadly, that is not working either.

What happens when you replace your script with a simple:

Absolutely nothing. :\

put the above code in your bot's remote and have someone or your other nickname type in the word alert. See if you can see the echo true in red in the active channel via your bot.

P.S. I almost forgot to mention that you need to make sure your remote is on by entering:

Absolutely nothing happened. Remotes have been active this entire time, my other remote-dependant or remote-type scripts work fine.

It seems that you already have an on text event that is halting the script with the /halt command, it would explain why none of this script work for you.
Try to find all your on text event and see if some of them have a /halt, if so, try replacing them by /haltdef

/return is preffered.

Look for a text event like this.

on *:text:*:#:{ }

If this has halt in it it will all halt all other text events after this.

I know what is return and what's halt, but it's a bad common way in script to use halt to stop the default text instead of /haltdef, I think it is the case here.

I ran a search on all of my Remote scripts, eight of them have halt in them but they perform seemingly unrelated functions.

The only halt in the actual script I am putting this alert script in isIt is the first line in the .MRC that this alert script is going into. I suppose that might be what's doing it?

if you have any other ON TEXT event in the same file, the first ON TEXT event matching the text will be triggered and the rest will be ignored. The ON TEXT modification I asked you to make proves that there is nothing wrong with /splay, but rather the event isn't even triggering at all. You need to remove, move or combine the first ON TEXT event. See http://kthx.net/ftb/#52

I didn't mean any disrespect Wims. I've only used haltdef for themes. I see people using halt a lot instead of return or using elseif. I personally think return or elseif is a better option. Unless of course you want to halt an event.

Which is why you want to keep that ctcp event.

argvo is right.

You can only have one text event per file that gathers all info. I'm not sure if you can put another text file after one that has a wildcard for all text. It's been a number of years since I tested that.

Any text event I do like this I have a flood protect. This is just the basic idea behind a text flood protect.

Next, since you use an alias to strip the font, I like to tokenize it with $chr(32), or the space character. Now you can refer to the text as $1- instead of $strip($1-). This way you only run the text through the alias once per event vs. at every comparison until you get the positive match.

And elseif is nice to use to clean up and speed up your scripts. Now it will only go through comparisons until it gets a positive match. (Unless you put an if statement under it.)

A few little changes to make mirc do less processing may not do much, but added up and your scripts can run leaner, faster, and in my opinion, more stable.



There is nothing wrong with using individual text events either, you just have to put them above the event that triggers for all text. i.e.:

on *:text:*matchtext*:#:{ command }
on *:text:*match *:#:{ command }
on *:text:*:#:{ command }

The above works, but only after I took the advice of argv0 and DJ_Sol and put the Audio Highlight script into its own .MRC file. Thanks for the help guys, it works even better than I wanted it to now!