Forums Scripts & Popups Can this be better

Hi guys,I'm trying to put a few things together and it seems to work for the most part but I was wondering if it could be writing a better way.
I only want ops to use it so I have it set to lvl20 .One thing I wasn't sure about which I'd like to do is add to the ban/kick section that if an op tries to kick or ban another fellow op,
the script will just ignore it but I cant seem to work it out.

I tried this but it didnt work:

if ($$2 isop $chan) { halt



TIA,D00M

If $2 is the nick to kick/ban, your check "if ($me isop $chan) && ($$2 isop $chan) {" will allow the kicking of ops only.
Just negate the "isop" operator:And you may also add a check if $2 is on that chan at all:

Alternatively, you could use the $nick() identifier:

but if you do, as $nick() also takes a numerical parameter, use something like:

You have the right idea with checking isop, but you're doing it backwards. You currently have it set so that "if $2 is an op, then ban/kick them." Instead, you want it so that "if $2 is not an op, then ban/kick them." I don't see where you used halt in your current script, so I can't say what exactly was done wrong there. Based on your current script, just change the isop checks to !isop checks and you don't have to use halt for anything.

A few more points...

* Instead of checking if $me isop, use the @ sign on the event lines. For example:


The @ will trigger the event only if you are an op. Perfect for any script that requires you to be an op for it to work (setting modes/bans/etc).

* When setting a dynamic variable, you don't need to use []'s. Instead of:


Use:


Also, note that I removed the double $ on $$2. The reason is that your event checks for "!ban *" (or "!kick *" or whatever). Because you have a space before the *, you are guaranteed to only trigger if there is a $2 value. You only need double $ if it's possible to trigger the event without the right number of values. In this case, you're fine. Now, if you needed $3, then you'd want $$3 on there (or change the matchtext).

* Although dynamic variables can be read using this format:


The better way to do that would be:


The $+(%,reason.,$2) creates the full variable name-- For example, if $2 is D00M, it creates %reason.D00M . Then, the $( ,2) part evaluates the variable so that you know what the variable is set to. Note that $() is shorthand for $eval(), so you can use that instead if you want to. Although your way will work, it's just considered better to handle it this way.

* The final suggestion I'll make... using 20 for your level is okay, but not really the best option. As long as you make sure no other scripts are used that might add people using a higher number (or the same number) for other reasons, you're fine. But you have to be careful about that situation, especially for any script that provides Op commands. Instead, you can use a named level, such as Admins or whatever, instead of a numbered level. To do that, wherever you have 20, change it to the name (Admins in this example) and also make sure that's used instead of 20 on your Users tab. It's less likely to run into script conflicts that way. You may want to consider a more unique name than Admins, though. For the same reason as the numbers, a common name may be used by other scripts. You can pick something more unique like D00M-Admins or whatever if you want to have the very smallest chance of a conflict with other scripts. Again, this isn't an issue if you pay attention to what scripts you have and what they do with the user list, but it's a good practice to keep that kind of situation in mind.

Can you explain to me why:

$($+(%,reason.,$2),2)

is better than

%reason. [ $+ [ $2 ] ]

Thanks

The distinction between the use of [ ] and $() are merely of personal preference. I don't see how's one better than the other...
I suppose you can also use any of these that suits your fancy: $var().value , $eval() and the undocumented $(,$+()) They will work the same as a result.

The [ ] bracket are meant to control the order of evaluation of a line, so using two pairs lead to double evaluation, which is then the same as $eval.
$eval isn't better than the [ ] bracket and vice versa, people just started using [ $+ [ dynamicthing ] ] for retreiving dynamic content where $eval should be used, kind of a bad idea
You can read a lot of more about the exact behavior/difference of those here

So not to criticize whether the [ ] is better than $(). They both have their own distinct purpose to utilize in MSL when applied appropriately.

Quite not true, "!kick " would match just fine, no $2

Maybe I'm not seeing something right.





So here if there is no $2, the second comparison would be $false and thus it would halt.

Edit: Actually, looking at this again, regardless if its $2 or $$2, if there is no 2nd parameter the second comparison is $false so it halts.

The way I see it is when you don't leave a space after the trigger in the match section of the event, an extra dollar sign is needed:
Versus:No dollar sign is necessary if a space is inserted after the !kick command.

I'm not discussing the use of $$, I'm just saying "!kick *" match "!kick " and $2 doesn't exist here, I edited the post.

Yes, "!kick " would match, but that is extremely unlikely to ever occur because you can't just type it that way (the space would be truncated). You can make that occur by using Ctrl-Enter and other methods, but the chances are minor. Either way, your point is made that it is possible to cause an error if you don't use $$. It's just extremely unlikely. If you want to avoid the possibility, include it. If you are fine with the rare occurrence, then you don't need it. Completely up to you. Nothing wrong with adding in protection against rare occurrences.

Btw, the help file example is kind of odd. There definitely is no reason to put $$1 if you have $$2 in the same command. You can't have $2 and not have $1.

One other thing just as FYI for anyone who may not know. If your command must have a specific number of "words", you can use & as the wildcard.

In this example, it will only trigger if someone uses !mycommand followed by exactly one "word" (one thing separated by spaces... in other words, you have a $1 and $2, but not a $3).


In this example, it will only trigger if you have !mycommand followed by exactly two "words":


And, in this example, it will trigger if you have !mycommand followed by 2 or more words, but not fewer.



As far as the way to deal with dynamic variables, yes... both work. Yes, many consider it a preference (I used []'s to start until I found out that it would be more appropriate to use $eval(). Using brackets is fine if that is what you prefer. There are situations where that really isn't a good option, though. In general, $eval() is probably what you will be told is the better coding method whether you're using mIRC or another language that has an eval function along with the ability to use brackets. At least by longtime programmers. At least, that's been my experience. Besides, brackets can very quickly become cumbersome if you have more than a single combination of items.

You get me wrong, I'm not discussing whether or not matching "!kick " is a problem, but you said that since there was a space after !kick, $2 will exist, which is wrong when "!kick " is matched, I was just pointing that out

Wims, have you thought about what you've typed may have become of a misunderstanding to people's understandability? Oftentimes a message can be taken for another meaning if not explained thoroughly. :P I'm not implying that you've done it on purpose, but this occurs to any of us every now and then.

Thanks Horstl ,Riamus2 for the suggestions and everyone else that joined in on the topic.I find it very interesting watching you guys chat it out on the forums :P .Iv tweaked the script a little and it seems to be a lot better.I changed the lvl control also as suggested and fixed the kick/ban of ops etc...Thanks again guys for the suggestions

D00M

Look, all my post was damn clear, nowhere I'm talking about $$, but two of you replied about $$, frankly at that point I was already thinking "they need to read carefuly" but no point saying that.
So I edited the post by putting in bold what I was replying to and I stated that I was simply ("I'm just saying") talking about what he said about $2.
Then Riamus replied saying it's unlikely to appear etc (no the space won't be truncated, only if you halt on input but again, I don't care), which is still off topic, I was just pointing out it is possible for $2 to be empty with the actual trigger because it was wrong to say otherwise, nothing more.

Yes, I always think about how people are going to understand my posts, but no it's not my fault if you guys read and get me wrong
A simple "Oh yeah nice catch/my bad" or similar would have been ok.

Hm. You're right about the space. I haven't used mIRC without scripts in so long, I didn't realize that the script(s) are the cause of the truncating and not mIRC. Chalk one up to not testing it first in vanilla mIRC and only in my active copy of mIRC.