on invite bug - mIRC Discussion Forums

mIRC still does the event beep even with this in the remotes:

Code:

on ^*:INVITE:*:{ halt }

This was tested on a clean mIRC 6.16 with no scripts loaded.

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).

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.

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.

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.

This bug still exists in mIRC v6.17.

can you /splay stop ? probably not as the event triggering at all causes the sound, probably parsed pre-script...

btk

no

/splay stop is perfectly valid and available.

/help /splay

Quote:

You can use stop to stop a currently playing sound, eg. /splay stop, or /splay -w stop, to stop just wave files.

Quote:

/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?

Code:

on ^*:INVITE:#test0000:{ haltdef | splay stop | join # }

still beeps. even if it worked, it's an improper workaround to a bug

see my thread for even more invite event bugs

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

Code:

on 1:invite:#:{
  var %i $vol(wave)
  vol -w 0
  timervol 1 3 vol -w %i
}

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)?

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

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:

Code:

(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:

Code:

(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.