Stricter event matching - mIRC Discussion Forums

I'd like to see some additions to events to allow for stricter matching. Such as

A prefix making the matchtext case sensitive.
A spot in events for CIDs. Ex: ON *:Join:#channels:CIDS: I don't think many would put an actual number in this field. Most would put a variable there and change the variable within the on connect event.
A spot for the users modes, and $nick's mode in channel related events

The last one probably needs an explanation. In addition to the CID field I'd like to add 3 more fields.

My Mode: Rather than use the mode's letters use the modes prefix such as @%+. Event will trigger if you are those modes. "@%+" would mean trigger if the user is opped, voiced, or halfopped on #.
NickMode: Works like MyMode except it applies to $nick.
NickNotMode: Works like MyMode except it applies to $nick and matches when $nick is NOT those modes.

If someone were to put @ in both the NickMode and NickNotMode section then they should cancel out as if someone did "if (($nick isop $chan) && ($nick !isop $chan))" The final result for an event like ON TEXT would look like this:

ON *:TEXT:matchtext:#:CIDS:MYMODE:NICKMODE:NICKNOTMODE: { }
ON *:TEXT:*bitchx*:#mIRC:5,6:@::@%+: { }

If you are opped in #mIRC on CIDs 5 or 6 and Somenick types "bitchx rules!" and somenick is NOT voiced, opped, or halfopped. I know the extra 3 fields can easily be scripted but I like to specify as much as possible in the event itself and let mIRC do the matching up internally. Events that this would apply to are: ACTION, BAN, CTCP , DEHELP , DEOP, DEVOICE, HELP , JOIN, KICK, MODE , NOTICE ,OP , PART, RAWMODE, SERVERMODE, SERVEROP, TEXT, TOPIC, UNBAN, and VOICE. Some of those events would have no use for NickMode or NickNotMode (like serverop, servermode, and Join) so you wouldn't specify them. With the mode events NickMode and NickNotMode would apply to the person setting the modes. These addtions should be able to be done without breaking older scripts. "On *:Text:*:#: " would be treated like "On *:Text:*:#:*:*:*:: {".

Code:

on *:start: { unset %cidlist }
on *:connect: { 
  if ($network == SomeNet) { %cidlist = $addtok(%cidlist,$cid,44) } 
  else { %cidlist = $remtok(%cidlist,$cid,1,44) }
}

ON *:text:*badword*:#MyChannel:%cidlist:@%::@%: { kick $chan $nick Don't say badword! }

vs 

on *:text:*badword*:#MyChannel: {
  if (($istok(%cidlist,$cid,44) &amp;&amp; (($me isop $chan) || ($me ishop $chan)) &amp;&amp; (($nick !isop $chan) &amp;&amp; ($nick !ishop $chan))) { kick $chan $nick Don't say badword! }
}

I like this suggestion. It would make things both easier and faster. I don't see any major compatibility issues either, except for things like this:

Code:

on *:text:*:#[color:red]:[/color]msg # you said[color:red]:[/color] $1-

The new mirc would probably interpret msg # you said as the CIDS field. Only a very intelligent parser would be able to guess the scripter's intention, and not always.

Yeah. I thought about that. I see two ways around it.

1) A new prefix (like ~) to let mIRC know you are doing it the new way.
2) Redo the events. Instead of ON *:something, do EVENT *:something

A new prefix is probably the easier, less painful way.

why not just use if statements? why invent the wheel twice?

Why not "just use if statements?" Simply for speed. Sure you COULD script it, however this modification to the language would simplify most scripts as well as speedup the scripts. His suggestion was not to "invent the wheel twice", only to improve upon the already invented wheel.

You should learn to think about things before you criticize them.

But once you have a wheel that works the way you need it to, whats the point of trying to improve it?

*sigh* As I said in my post: I believe it's both faster and easier to let mIRC do as much matching as possible.

The @ prefix does the equivalent of "if ($me isop $chan)" The ! prefix does the equivalent of "if ($nick != $me)" We could use $level instead of specifying a level. We could replace matchtext with if (matchtext iswm $1-). We already have ways to limit how and when an event is executed. This just adds more.

The MyMode field simply expands the ability to include other modes besides @. Halfops can do a lot of what ops can do in the channel. Let's say you run a swear kicking script. You'd probably want it to work if you are opped or halfopped. There is a @ prefix but no % type prefix. This could replace both.

The CIDs field allows you to make an event work only on specific servers. This is much easier then putting "If ($network == SomeNet)" in every event.

The NickMode and NickNotMode fields allow you to narrow things down even further.

I'd prefer to be as specific as possible in an event so it is executed as few times as possible.

As for the wheel analogies, I'd like to think of it as improving the wheel, not reinventing. I think most can agree that mIRC currently works yet we have this whole forum for improving it. How many releases of mIRC have been purely bug fixes? This working wheel is constantly being improved.

So once GM make a car, why bother improving it? It works doesn't it?

Well, I didn't say that, I said wheels. Look at the wheels on a 1967 car, and a 2004 car, there won't be too many differences between the two.

Huge difference actually, 1967 tires used "real" rubber from trees, where 2004 tires would use synthetic rubber. Runflat technology, studded tires, computer-aided tread design.

Tons of differences. One more thing too, Chrome has become stainless steel. (Only bad thing)

You're missing the point, and I'm not really in the mood to keep trying to explain it.

CID's change... if you connect to all your servers the other way around the server which you have first normally now get's the highest CID...

so $iif($network,$network,$gettok($server,-2,46)) still works best imho (I use this code because of networks who don't have $network support (which are few, I know) and the -2 is to pick up a 'unique' name from the $server... mostly the -2 is the server name ( irc.somenetwork.com someserver.irc.somenetwork.net etc...) ofc all have exceptions...)

the fact no '@' prefix exists for half-op is a good point though

besides the way you want it it create much problems for the scripting engine to understand the event because the triggers varies in lenght too much, or you should give the rest all $null values

Quote:

CID's change... if you connect to all your servers the other way around the server which you have first normally now get's the highest CID...

That is why I said that the CID field would be most useful as a variable. Change the variable within the ON CONNECT event and you have yourself a more specific match. See the example snippet from my first post on this thread.

Quote:

the fact no '@' prefix exists for half-op is a good point though

Ok, we can add a prefix for halfop and eliminate the MYMODE part. That will work until someone wants a prefix for voice, or perhaps one for protected, owner, or somefunkynewode.

Quote:

besides the way you want it it create much problems for the scripting engine to understand the event because the triggers varies in lenght too much, or you should give the rest all $null values

Ok, instead of putting nothing put $null. I am fine with that.

Code:

ON *:text:*badword*:#MyChannel:%cidlist:@%:$null:@%: { kick $chan $nick Don't say badword! }

I personally use this identifier instead of $network, though your $gettok idea is nice for a last resort... so I've added it.

Code:

ALIAS -l NetName {
  if ($server($server).group) return $ifmatch
  elseif ($network) return $ifmatch
  elseif ($len($gettok($server,-2,46) &gt; 2) return $gettok($server,-2,46)
  return $gettok($server,-3,46)
}

I always go by the Group name first, because smaller servers often return $network with DalNet because its default in their config file. Even servers on larger networks will return some default network name.

I also added $len checking for your -2 method, in case the address is someserver.irc.somenetwork.co.uk

- Raccoon

My point was this.

If you create something, and know you can do better, then you are more than likely going to want to improve it.

So what's different about this. Whether it's a good idea or not is another matter, but if it helps to improve mIRC, then perhaps it should at least be looked into, instead of just smacking it down.

And whats the point of improving said tyre? To make it better. Sure, the first version may have worked, and you may have liked it, but you can always improve on it.

It's the same with software. There is no perfect application/design/code piece.

Agreed, but thats because apparently you think this will make mIRC better, I think it will make mIRC scripts harder to read. There are 3 mode params "mymode, nickmode, nicknotmode" you know how many hundreds of people are going to be posting "my script doesn't work!" and the reason is because they had the order of those parameters wrong? I see such a feature as making mIRC more bloated, not better. It doesn't solve problems really, and it is confusing. Maybe it's just me, but I don't see the current way being so difficult/slow/etc. that it requires a rewrite.

I think what codemastr is trying to explain to you is that when the wheel was invented it was the same shape as it is today, round. If you can change the shape of the wheel to improve on it then good luck. Tyre rubber is largely still natural too, sorry to say. The main additives to rubber used in tyre manufacturing is carbon (for the colour) and the steel or nylon or canvas used in the reinforcing belts. The main diference in modern tyres is the type of plying used, old tyres were crossply whereas today most are radial ply, but that is still old-tech as bike tyres have been radial ply for a very long time.

Hmm I thought neophyte had a typo when he said "tyre" is that how you spell it in AU? To me the only thing Tyre means is an ancient Phoenician city...

Tyre is the correct way (The Queen's English) yep and I spelt colour the right way too.

Even South Pacific Tyres (Goodyear, Olympic and Dunlop lumped together) spell it this way.

Goodyear doesn't spell it like that. www.goodyear.com title "The Goodyear Tire & Rubber Company Homepage".

And neither does Dunlop. www.dunloptire.com (note dunloptyre.com doesn't even exist), title says "Dunlop Tire"

Oh and btw, I don't get my pronunciation information from a 50million year old lady who for some reason is in charge of a country

If you go to www.goodyear.co.uk then it's spelled 'tyre'. There may well be something similar for dunlop aswell, I didn't bother checking. So basically it's down to localisation (and the incorrect assumption that .com == USA).

Quote:

Agreed, but thats because apparently you think this will make mIRC better, I think it will make mIRC scripts harder to read.

I guess it looks a little harder to read but not dramatically. It's not like one can pull apart a full featured script and follow it effortlessly. Custom aliases and identifiers will have you bouncing all over.

Quote:

There are 3 mode params "mymode, nickmode, nicknotmode" you know how many hundreds of people are going to be posting "my script doesn't work!" and the reason is because they had the order of those parameters wrong?

It should be pretty easy to show them how to fix it. It's just as easy to typo somewhere else in the script and not have it work.

Quote:

It doesn't solve problems really, and it is confusing. Maybe it's just me, but I don't see the current way being so difficult/slow/etc. that it requires a rewrite.

I see people haggling over a few milliseconds in an event/alias all the time. There is another suggestion to add a /benchmark command just so it would be easier to test. This has the possibility of speeding things up by limiting how/when to run an event.

What do you think of the CID field? Would you rather it be a network/server field or have no field at all? If you don't like the MYMODE field then would you like to see a prefix for +h or +v? What about a prefix making the matchkey case sensitive.

I'd like to thank you for the post. We may disagree but I'd rather disagree over the details than go back and forth about wheels and tires/tyres. If a person feels a suggestion is not an improvement I'd rather hear why instead of "don't reinvent the wheel" or "you can script it"

I never actually said that this would be better. I just simply made the point that if something can be improved upon, then at least look into improving it, and if the idea is good, then try and implement it.

http://goodyear.com.au/
http://www.dunloptyres.com.au/
http://beaurepaires.com.au/
http://beaurepaires.co.nz/
http://www.michelin.com.au/home/default.cfm
http://www.pirelli.com/en_42/index.jhtml;jsessionid=FBCAK4FGXYIFBFYKJOPCFEY?_requestid=34909
http://www.olympictyres.co.uk/
http://goodyear.co.nz/
http://www.dunloptyres.co.uk/site/

Errr they do actually :tongue: