|
|
Joined: Jan 2003
Posts: 44
Ameglian cow
|
OP
Ameglian cow
Joined: Jan 2003
Posts: 44 |
Please can you tell me some simple script that makes the color of the nicks in the nick list that are on specific server different from the others.
For example all the nicks are with white color and those who are on irc.server.com to be with yellow or blue or other ...
10x
Regards, ThE_mASk.
|
|
|
|
|
Joined: Dec 2002
Posts: 212
Fjord artisan
|
|
Fjord artisan
Joined: Dec 2002
Posts: 212 |
I can;t give you ready to use script (I'm lazy), but I can tell you how to do it
use /who # on join (when you join) to get user list with server info, then check if the user is on that specific server and color it's nickanme with /cnick command
and use the same logic when other users join, but with /who nick
And all I need now is intellectual intercourse, a soul to dig the hole much deeper
|
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
You'd have to issue a /who <channel> for each channel you join and parse the 352 raw replies (more specifically, $5 contains the server name). Also note that some networks (like Undernet) hide the user's server. If you still want to go on with it, you can use something like: on me:*:join:#: set $+(%,mejoin,$cid,:,#) 1 | .timer 1 0 if (!$chan( # ).inwho) .raw who #
on *:disconnect: unset $+(%,mejoin,$cid,:*)
raw 315:*: if $eval($+(%,mejoin,$cid,:,$2),2) { unset $+(%,mejoin,$cid,:,$2) | halt }
raw 352:*:{
if $eval($+(%,mejoin,$cid,:,$2),2) {
if $me ison $2 && [color:green]$5[/color] == [color:red]some.ircserver.net[/color] { cline 8 $2 $6 }
halt
}
}The problem is you can't do much for the people that join after you, since the /who $nick reply does not include the server, but the hopcount, which doesn't help a lot... You could use /whois for that, but you really wouldn't like all that flood.
Last edited by qwerty; 07/02/03 11:29 AM.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
|
Joined: Dec 2002
Posts: 212
Fjord artisan
|
|
Fjord artisan
Joined: Dec 2002
Posts: 212 |
hm, on which network?
Hybrid show's it - I use this for ircop colourer stuff
<- :KALININ!~user3566@bgirc-085837.cablebg.net JOIN :#gyuvetch
-> irc.del.bg WHO KALININ
<- :irc.del.bg 352 vasil #gyuvetch ~user3566 bgirc-085837.cablebg.net irc.del.bg KALININ H :0 Realname
<- :irc.del.bg 315 vasil KALININ :End of /WHO list.
(Sorry for the server name, hope you don't take this as spam, If so I wouldn't mind if it's removed)
And all I need now is intellectual intercourse, a soul to dig the hole much deeper
|
|
|
|
|
Joined: Jan 2003
Posts: 44
Ameglian cow
|
|
OP
Ameglian cow
Joined: Jan 2003
Posts: 44 |
Ei pi4 obiasni mi go na 4ist bulgarski ezik 6toto kato gledam si bulgar4e  Kaji mi kak da gi napraa tia 6turotii sus praeneto na colorz ?
Regards, ThE_mASk.
|
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
Woops, you're correct. I thought that /who <nick> doesn't show a server because I did a quick test on mirc and it didn't show up... looks like mirc hides the server name, because it showed in @debug (although I should've guessed that a who reply would not be different depending on the command). Then the script can be written to include other people joining. The code is lengthy, but it is necessary in order to minimize the number of /who commands being sent (for example, it caches the info in $ial().mark, queues the channels - in case a user joins two channels almost simultaneously, ie joins the second channel before the 315 reply from the first channel is received - etc). on me:*:join:#: set $+(%,mejoin,$cid,:,#) # | .timer 1 0 if (!$chan( # ).inwho) .raw who #
on !*:join:#:{
if $ial($nick).mark isin 0 8 { cline $ifmatch # $nick }
else {
var %a = $eval($+(%,who:,$cid,:,$nick),2)
set $+(%,who:,$cid,:,$nick) $addtok(%a,#,32)
if !%a { .raw who $nick }
}
}
on *:disconnect: unset $+(%,mejoin,$cid,:*) | unset $+(%,who:,$cid,:*)
raw 315:*:{
if $eval($+(%,mejoin,$cid,:,$2),2) { unset $+(%,mejoin,$cid,:,$2) | halt }
if $eval($+(%,who:,$cid,:,$2),2) {
var %a = $ifmatch
unset $+(%,who:,$cid,:,$2)
halt
}
}
raw 352:*:{
if $eval($+(%,mejoin,$cid,:,$2),2) || $eval($+(%,who:,$cid,:,$6),2) {
var %a = $ifmatch, %b = $iif($5 == [color:red]some.server.net[/color],8,0), %c = $6
.ialmark %c %b
tokenize 32 %a
cline %b $* %c
halt
}
}Thanks for pointing it out the error To ThE_mASk: Do NOT use this script on large/busy channels, it will most probably flood you off. Also, I haven't tested it a lot, so it's possible that there is an error, either logical or syntactical. Let me know if it doesn't work as you want.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
|
Joined: Dec 2002
Posts: 1,321
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 1,321 |
Nice script, qwerty. I have a couple of questions about it, though. - Why do you switch styles all the way through it? Some of your if's use ( ) around the condition and no { } around a single command; others omit the ( ) entirely! and put { } around multiple commands on the same line; still others split out multiple commands on multiple lines. (This makes following the logic a little challenging for me.
 ) For example:
if (!$chan( # ).inwho) .raw who #
if $ial($nick).mark isin 0 8 { cline $ifmatch # $nick }
if !%a { .raw who $nick }
if $eval($+(%,mejoin,$cid,:,$2),2) { unset $+(%,mejoin,$cid,:,$2) | halt } - Why use "$ial($nick).mark isin 0 8" over "$ial($nick).mark != $null" ? $ifmatch will still contain 0 or 8 if there is a mark and you skip the match() on the string "0 8".
- In the 315, why are you setting %a at all? You don't do anything with it and since it's set with /var, it unsets itself after the halt.
DALnet: #HelpDesk and #m[color:#FF0000]IR[color:#EEEE00]C
|
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
1) If you notice, the () in if statements is used only inside the /timer. This is because { } get lost in the first evaluation (which takes place inside the script), so the timer would end up calling the command: if !$chan( #channel ).inwho .raw who #channelNow that might work too, but it's way too stretched and I wouldn't trust it at all. Otoh, ( ) aren't lost in evaluation and since the command part is a single comand it works fine. I could've used $chr(123) and $chr(125), I just like the 1st solution better. Edit: Oh, regarding multi-line vs single-line, I usually prefer pipes if there are up to 2 commands that are to be separated. For >2, I go for multi-line. I also (usually) prefer multi-line if there is an if statement involved, I feel it's clearer this way.2) I realise that it would work equally well with != $null, but isin 0 8 is slightly faster than != $null. This may sound odd at first, but in practice, the evaluation of an identifier ($null), which means a lot of stuff underneath, like mirc adding to a stack etc, is apparently slower than an expression that contains no 'evaluatable' content. Similarly, if * !iswm <something> is faster than if <something> != $null I don't remember if this was the reason I wrote it this way though: it might be that I subconsciously thought that isin 0 8 makes clearer what the script expects $ial().mark to be. Now, why did I leave a space between 0 and 8? No idea 3) Woops, this is a left-over from earlier attempts (I changed the script quite a few times before its final version), thanks for pointing it out
Last edited by qwerty; 07/02/03 05:07 PM.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
|
Joined: Dec 2002
Posts: 1,321
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 1,321 |
A few years ago, I wrote up a little script to speed test using ( ) and { } to see which way was parsed/executed fastest. If I recall correctly, the script used a single if statement with two commands inside it, all inside a while loop in all 4 configurations. I will have to do it again to see if anything has changed, but the last time I tested it, the order (fastest to slowest) came out like this:
if (condition) { command | command }
if condition { command | command }
if condition {
command
command
}
if (condition) {
command
command
}
The reason I asked was that I thought you might have done some similar testing recently and had some insight into why you'd omit the ( ) around all but one of your conditions. Since you tend to write fairly tight code, I figured you must have a reason and I was curious what it was.
DALnet: #HelpDesk and #m[color:#FF0000]IR[color:#EEEE00]C
|
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
You are absolutely right regarding the speed, the order is exactly that, at least according to my tests. The reason I use { } over () is not speed; it's convenience. In the vast majority of cases, this tiny speed difference is not as important (generally, I use the faster alternative if there aren't other reasons to make me think otherwise). I just find it much clearer to avoid () in if statements, especially if there are nested statements, where I'll probably forget a ( or ) too. I also find it easier to type. Last, which is the least important, you can use something like
if ) == %a { command }
which wouldn't work if you did a
if () == %a) { command }
Of course there are cases where () are necessary to control the order but the precedence of the && operator over || eliminates the need for () in most (I would think) cases.
In simple statements with a single command, both ways are equally clear to me
fex
if (%a == 2) echo -s ok
is as easy for me to type and read as
if %a == 2 { echo -s ok }
but for the sake of uniformity I use { } even in such simple statements.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
|
Joined: Dec 2002
Posts: 1,321
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 1,321 |
Here's the script I used to test tonight:
alias if.test {
echo -s * IF speed test: $bytes($$1,b) iterations per test
var %j, %i = $1
var %ticks = $ticks
while (%i) {
if %i > 0 %j = %i
dec %i
}
echo -s -() -{} single $calc($ticks - %ticks)
.timer 1 1 if.test.2 $1
}
alias if.test.2 {
var %j, %i = $1
var %ticks = $ticks
while (%i) {
if (%i > 0) %j = %i
dec %i
}
echo -s +() -{} single $calc($ticks - %ticks)
.timer 1 1 if.test.3 $1
}
alias if.test.3 {
var %j, %i = $1
var %ticks = $ticks
while (%i) {
if %i > 0 { %j = %i }
dec %i
}
echo -s -() +{} single $calc($ticks - %ticks)
.timer 1 1 if.test.4 $1
}
alias if.test.4 {
var %j, %i = $1
var %ticks = $ticks
while (%i) {
if (%i > 0) { %j = %i }
dec %i
}
echo -s +() +{} single $calc($ticks - %ticks)
.timer 1 1 if.test.5 $1
}
alias if.test.5 {
var %j, %i = $1
var %ticks = $ticks
while (%i) {
if %i > 0 {
%j = %i
}
dec %i
}
echo -s -() +{} multi $calc($ticks - %ticks)
.timer 1 1 if.test.6 $1
}
alias if.test.6 {
var %j, %i = $1
var %ticks = $ticks
while (%i) {
if (%i > 0) {
%j = %i
}
dec %i
}
echo -s +() +{} multi $calc($ticks - %ticks)
echo -s -------------------
.timer 1 1 if.test $1
} I started this up with /if.test 1000000 and after letting my 800MHz monster run through sets of 1,000,000 loop iterations per item (6,000,000 loop iterations per run) (8 runs = 48,000,000 loop iterations) for a while, here are the results. I think These have some interesting changes since the last time I tested them. This is using mIRC v6.03.
A. -() -{} single == - - s
B. +() -{} single == + - s
C. -() +{} single == - + s
D. +() +{} single == + + s
E. -() +{} multi == - + m
F. +() +{} multi == + + m
A. - - s 77582 77782 78563 78002 78884 78443 78072 78233 = 625561
B. + - s 89318 88678 89159 88998 88807 88487 88728 89299 = 711474
C. - + s 94616 94956 94286 95347 95067 95117 95778 95017 = 760184
D. + + s 94957 96118 96108 95478 97200 95898 96018 96619 = 768396
E. - + m 98552 98421 98662 99523 99503 98392 99744 97881 = 790678
F. + + m 99183 99603 100224 100415 100214 99463 99994 99924 = 799020
====== ====== ====== ====== ====== ====== ====== ====== = =======
554208 555558 557002 557763 559675 555800 558334 556973 = 4455313
A. B. C. D. E. F.
- - s + - s - + s + + s - + m + + m
====== ====== ====== ====== ====== ======
A. - - s == 12.07% 17.71% 18.59% 20.88% 21.71%
B. + - s == 12.07% 6.41% 7.41% 10.02% 10.96%
C. - + s == 17.71% 6.41% 1.07% 3.86% 4.86%
D. + + s == 18.59% 7.41% 1.07% 2.82% 3.83%
E. - + m == 20.88% 10.02% 3.86% 2.82% 1.04%
F. + + m == 21.71% 10.96% 4.86% 3.83% 1.04%
This is a heavy-duty switch around from years ago. Last time I tested this, omitting both the () and { } was only faster than multi-lined; now it is 12% faster than +(), nearly 18% faster than +{} and around 18.5% faster than +() +{}. +() is only 6.4 or 7.4% faster than +{} or +() +{}, respectively. Clearly, I have some tightening up to do in my own scripts, where possible.
DALnet: #HelpDesk and #m[color:#FF0000]IR[color:#EEEE00]C
|
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
The results are more or less the same as mine, except that I did not test the -() -{} case (it's surprising how nice mirc can be to you; it doesn't break if you omit both () and {} in some cases). I didn't calculate the difference in percentage, I only got 3 numbers (the $ticks difference) and compared them roughly with each other. There are a couple of things I'd like to point out. When a particular procedure is to be benchmarked we have to reduce the CPU time consumed in other parts of the script as much as possible; the benchmark is more accurate if the procedure in question is responsible for the 90% of the CPU consumed by the script, than being responsible for the 40% for example. Whatever element eats processing time apart from the actual if statement is considered "noise". In a high level language like mirc's, this noise is important and could alter the results. One might think that since in all tests the extra elements are the same, they would need the same CPU time, more or less, so they could just be subtracted from the result. However, this might not be true and I believe that the higher the level of the language, the greater are the variations in processing time. This is what makes benchmarking in mirc kinda unreliable, imo, even if it's designed the best possible way. For example, in this statement: if (%i > 0) %j = %i the noise factors are two. First, the condition is true, which means that the command part (here the %j = %i) will always be executed. This execution eats some of the cpu time. Second, in the condition part, we have the variable %i that's evaluated each time. This evaluation is also considered noise. Also, a possible third factor (I'm not quite sure about this one but I consider it a possibility) is that each while iteration has only one if statement. So, to test, fex, 10,000 times this statement you need 10,000 iterations in while. However, if with each iteration, 5 identical if statements were executed, you'd need 2,000 iterations. The latter seems more accurate to me, although I have no idea about the way while() is implemented in mirc. Another factor that could affect a benchmark is the time it takes to complete. Longer benchmarks are more accurate because a minor speed difference builds up to a noticeable amount. Also, making an average of many runs is more reliable than a single (or a few) runs. Otoh, if a benchmark takes some time to complete, there is a chance that something will happen during that time to your system that will steal some CPU from mirc and lend it to another application. Taking the tests in a system with as few as possible apps running reduces this danger but it won't make it zero. Increasing the process priority for mirc could help, although I'm not sure about that either (I would imagine that only the thread that executes the script should be given greater priority, but I'm not qualified to talk about these things). I think that a great number of runs (each one taking a relatively little time) is the best solution, as you can monitor what's happening: for example, if out of 100 runs, 2 of them are abnormally slow, it would possibly mean that the o/s stole some CPU from mirc to use it for something else. Taking all these into consideration, I would make two versions of if.test* aliases: one where the condition is true and another where it's false (and I would consider the second more indicative); I'd use a statement that contains no variables/identifiers; I'd include more statements in the while loop body; in the tests where the condition is true I'd use a command that eats as less cpu as possible ( !haltdef would be a good example I think, it's the least time consuming command, since it does absolutely nothing. The ! is included as I've found it's faster this way, probably because mirc doesn't have to check if there is a /haltdef alias). Here's how I'd write the if.test alias, for both versions: alias if.test.false {
echo -s * IF speed test: $bytes($$1,b) iterations per test
var %i = $1, %ticks = $ticks
while %i {
if 1 == 2 do-nothing
if 1 == 2 do-nothing
if 1 == 2 do-nothing
if 1 == 2 do-nothing
if 1 == 2 do-nothing
if 1 == 2 do-nothing
if 1 == 2 do-nothing
if 1 == 2 do-nothing
if 1 == 2 do-nothing
if 1 == 2 do-nothing
dec %i
}
echo -s -() -{} single $calc($ticks - %ticks)
.timer 1 1 if.test.2.false $1
}
alias if.test.true {
echo -s * IF speed test: $bytes($$1,b) iterations per test
var %i = $1, %ticks = $ticks
while %i {
if 1 == 1 !haltdef
if 1 == 1 !haltdef
if 1 == 1 !haltdef
if 1 == 1 !haltdef
if 1 == 1 !haltdef
if 1 == 1 !haltdef
if 1 == 1 !haltdef
if 1 == 1 !haltdef
if 1 == 1 !haltdef
if 1 == 1 !haltdef
dec %i
}
echo -s -() -{} single $calc($ticks - %ticks)
.timer 1 1 if.test.2.true $1
}Even if all the above said are valid (I'm not sure that they are, heh), they are purely theoretical; in practice, I believe that the speed difference among the various ways of writing an if statement is clear enough and can be shown with any decent benchmark, even if it's not the perfect one. Your benchmark might give different percentages than mine for example, but the order would be exactly the same.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
|
Joined: Dec 2002
Posts: 212
Fjord artisan
|
|
Fjord artisan
Joined: Dec 2002
Posts: 212 |
wow
I've always used to think that using {} and () speeds processing
/me has to do some tieghtening too
how about using | ?
they speed up too right?
And all I need now is intellectual intercourse, a soul to dig the hole much deeper
|
|
|
|
|
Joined: Dec 2002
Posts: 1,321
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 1,321 |
I turned off all my other unnecessary programs I had running (like email) and disconnected from all server connections. mIRC was the only high-level process running. And I ran each of the 6 tests using the exact same commands. The only thing in the script that changed was the format of the IF statement being tested. That is the only thing I was interested in seeing the difference for. With no active connections and no active timers, the other parts of the script were dormant. (I did, in fact, try testing while I still had my email client connected (risking it checking for email during the test) as well as being connected to #mIRC on DALnet/EFnet and thus risk having the test interrupted occasionally (well .. between tests, since the while loop should preclude the rest of the script from responding at all while I'm still inside the while loop for any given if.testN). So, I closed everything down except 1 status window that was not connected to a server.
The actual command that runs if the if condition is true makes no difference, as long as they are all exactly the same for each test. If you vary them, you're going to skew your results. The same applies to what you are testing in the if condition. As long as the condition is identical, then you're still only timing the difference in the formatting of the if statement itself. I could have used a CPU-intensive command, like a /filter command (or whatever)...as long as I use the exact same command under the exact same conditions for each test; the only result would be that my numbers would be larger. I avoided using a command (as such) for the very reason you stated: I didn't want mIRC to go looking for an alias by that name before executing the command. That is why I picked a simple variable assignment statement.
The reason the numbers vary at all is that I did not shut down every other process that Windows has running, since I am not sure which of those are essential to Windows and which are not. The test would have been more accurate had I shut them all down, but I tried to minimize, or level out, the differences by extending the iterations of the loops to something that would (hopefully) make the interruptions reduced to a low noise level. Thus, I used 1 million loop iterations for each format tested per run. And then, to further level out the results, I ran the test 8 times and added the results of all the tests together, basing my statistics on the aggregates of all of the run totals rather than on one or another of them, such as highest or lowest time to complete. That's 8 million executions of each test and 6 tests. This is quite possibly more than any mIRC script should ever expect to do in almost any script. (If you're running into these kinds of numbers, it's time to farm the problem off to a compiled DLL.)
These tests all tested for only a true condition because I was only testing formatting of ( ) { } and single/multi-line, not logic; however, I will grant you that testing for formatting false conditions might be just as valid and important as for the true condition I tested. You would still have to keep everything else in each script exactly the same, though. The formatting of the rest of the script involved cannot change at all, including how or when you set $ticks into a variable, how you format the while condition, etc. Optimizing those is all well and good; doing so will make your resulting numbers smaller, but not any more or less valid.
In an ideal scenario, mIRC would be the only process running on the computer except for absolutely essential OS processes; it would not be connected to anything. It would have all scripts (other than the test script) unloaded. And the test would be allowed to run consecutively for several days or weeks. For THOSE kind of result numbers, you'd probably want to put the results straight into a spreadsheet file (outside the timed section of the script, of course); you'd certainly not want to have to manually enter all that data yourself, nor do all the manual math on it at the end.
DALnet: #HelpDesk and #m[color:#FF0000]IR[color:#EEEE00]C
|
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
The actual command that runs if the if condition is true makes no difference, as long as they are all exactly the same for each test This is exactly what I tend to consider questionable: even if they are exactly the same commands, fluctuations in execution time can be introduced, and they are greater as those commands get more complex (for example evaluate many variables/identifiers etc). In a benchmark in assembly or even C/C++, this would probably not matter, as a single command takes a predefined number of cpu cycles. In higher levels though, like mirc scripting, the same command can be completed in times that vary among repetitions. This doesn't matter much if you want to measure the speed difference of two procedures that one of them is known to be faster. But I think it matters when these procedures are almost equally fast. In that case, the 1 msec (for example) difference between those procedures might be lost in fluctuations during the evaluation of variables or what not. Granted, a very large number of repetitions finally evens out these fluctuations, but it feels more proper to try to measure the time consumed by only a specific procedure (to the extent that it's possible) than including the execution time of other elements and then ignoring them as "common factors", which might not be so "common" after all.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
|
