|
|
|
|
Joined: Sep 2003
Posts: 149
Vogon poet
|
OP
Vogon poet
Joined: Sep 2003
Posts: 149 |
mIRC still does the event beep even with this in the remotes: This was tested on a clean mIRC 6.16 with no scripts loaded.
mIRC 6.21 - Win XP Pro (SP2) - 2.4 Ghz - 1 GB Mem
irc.x-tab.org
|
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Can't you just turn off beeps in mIRC's options?
That said, I think haltdef would be more appropriate (tho I have not tested it and I'm not positive if the beeps are considered a "default" action).
Invision Support
#Invision on irc.irchighway.net
|
|
|
|
|
Joined: Sep 2003
Posts: 149
Vogon poet
|
|
OP
Vogon poet
Joined: Sep 2003
Posts: 149 |
It did not change at all with haltdef.
I would just deisabe the event beep in mIRC's options, but then I would need to script a beep for everything I wanted to beep, which defeats the purpose.
mIRC 6.21 - Win XP Pro (SP2) - 2.4 Ghz - 1 GB Mem
irc.x-tab.org
|
|
|
|
|
Joined: Dec 2002
Posts: 208
Fjord artisan
|
|
Fjord artisan
Joined: Dec 2002
Posts: 208 |
alt+o -> sounds -> On Event, play sound: Invite -> click the "Event Beep" button, and in the dialog that appears, click cancel. Should say "No Sound". Click OK. That should take care of it.
If I knew now what I will know then... maybe things will have been different...
|
|
|
|
|
Joined: Sep 2003
Posts: 149
Vogon poet
|
|
OP
Vogon poet
Joined: Sep 2003
Posts: 149 |
Remote scripts should still have the ability to halt the sound along with the text, just like it does for things like Notices and Queries.
mIRC 6.21 - Win XP Pro (SP2) - 2.4 Ghz - 1 GB Mem
irc.x-tab.org
|
|
|
|
|
Joined: Sep 2003
Posts: 19
Pikka bird
|
|
Pikka bird
Joined: Sep 2003
Posts: 19 |
This bug still exists in mIRC v6.17.
|
|
|
|
|
Joined: Mar 2003
Posts: 612
Fjord artisan
|
|
Fjord artisan
Joined: Mar 2003
Posts: 612 |
can you /splay stop ? probably not as the event triggering at all causes the sound, probably parsed pre-script...
btk
Last edited by billythekid; 13/07/06 03:49 PM.
billythekid
|
|
|
|
|
Joined: Sep 2003
Posts: 19
Pikka bird
|
|
Pikka bird
Joined: Sep 2003
Posts: 19 |
|
|
|
|
|
Joined: Aug 2004
Posts: 7,252
Hoopy frood
|
|
Hoopy frood
Joined: Aug 2004
Posts: 7,252 |
/splay stop is perfectly valid and available. /help /splay You can use stop to stop a currently playing sound, eg. /splay stop, or /splay -w stop, to stop just wave files.
|
|
|
|
|
Joined: Sep 2003
Posts: 19
Pikka bird
|
|
Pikka bird
Joined: Sep 2003
Posts: 19 |
/splay stop is perfectly valid and available. /splay stop should not be necessary when using a haltdef, and further, it doesn't work. I'm guessing you didn't bother trying it before posting? on ^*:INVITE:#test0000:{ haltdef | splay stop | join # }still beeps. even if it worked, it's an improper workaround to a bugsee my thread for even more invite event bugs
|
|
|
|
|
Joined: Mar 2003
Posts: 612
Fjord artisan
|
|
Fjord artisan
Joined: Mar 2003
Posts: 612 |
if it's expected behaviour then would it not be better to script beeps IN to what you want with beeping turned off in mirc. I don't think it IS a bug... (computers do what you tell them to do, not what you want them to) you set the default behaviour in your mirc and haltdef is a text command, not a sound command. how about
on 1:invite:#:{
var %i $vol(wave)
vol -w 0
timervol 1 3 vol -w %i
}
Last edited by billythekid; 14/07/06 09:00 AM.
|
|
|
|
|
Joined: Sep 2003
Posts: 19
Pikka bird
|
|
Pikka bird
Joined: Sep 2003
Posts: 19 |
Why should mIRC trigger an event beep when there's nothing for the user to see? /haltdef stops event beeps from occuring for other events, such as on NOTICE. The behavior is inconsistent. One of them must be wrong. Let's apply Occam's razor here and go with the simplest option. There are basically three ways an event can be handled. First, the default options (no script). Second, selective replacement of the behavior of an event (say, for example, on INVITE matching only certain channels). Third, replacement of all instances of an event type (on INVITE for every channel). If the user writing the script wanted to replace behavior for every INVITE event, then they could use the mIRC options to turn on or off the event beeps. If they want to selectively replace behavior, then why should they have to modify the behavior of all other instances of an event (not just for the channels they are interested in catching; trigger the beeping manually, having turned off the beeps in options)?
|
|
|
|
|
Joined: Mar 2003
Posts: 612
Fjord artisan
|
|
Fjord artisan
Joined: Mar 2003
Posts: 612 |
i didnt realise haltdef stopped the beeps in other events...
whats the difference with selectively adding a command from selectively removing one as far as scripting it goes? you wouldnt be modifying the behaviour of all other instances as those would be the ones in the script (if $chan != beepchan)
I see your point though, as you have explained with the haltdef working for other events beeps this shows an inconsistency and a bug with on invite.
btk
billythekid
|
|
|
|
|
Joined: Sep 2003
Posts: 19
Pikka bird
|
|
Pikka bird
Joined: Sep 2003
Posts: 19 |
I was referring to the suggestion of turning off beeps in the options and adding them back for every channel other than the ones you are interested in. Something like this: (beeps off in options)
on *^:INVITE:*:{
if ($istok(#one #two, #, 32)) { join # | haltdef }
else { beep }
}instead of being able to use the built in channel matching like: (beeps on in options)
on ^*:INVITE:#one,#two:{ join # | haltdef }My point was, in the first one you're modifying behavior for every possible invite event, not just a few.
|
|
|
|
|
|
|
