hey man, sorry I missed you on IRC earlier! i hope life is treating you well and you've found other things to fulfill you as much as mIRC's fun little scripting language once did :D i myself have been off and on - mostly off - for the last 5 or so years, but came across a challenge on mirc.com's forums and decided to fire up mIRC again about a week ago. haven't /exit-ed yet! so it was quite a coincidence that you would show up now of all times, albeit not quite coincidental enough lol. there still seems to be a bit of interest in mIRC - even Sat is still around! we're on ##mirc on freenode, in case you find yourself on IRC again in another 7 years ;)
hi! wow, thanks for investigating that :P
yeah it seems as though i entirely overlooked the prospect of excess spaces... or simply didn't want to handle them.... can't really remember. i've been battling with the 'excess spaces' problem in mIRC for as long as i can remember, and as much as i hate to leave the script in such a defeated state, the solution would require more time than i can afford to commit right now. i do have an easy way to fix it in your case though:
you'll notice the /findtext itself is not very precise. the /findtext ends up looking for that line, already stripped of excess spaces, anywhere in the buffer. thus it could potentially find too much (where the line is part of a larger line) or too little (where the line contains multiple consecutive spaces in the middle and therefore won't be found). i figured that since most people use timestamps, the first case was not likely to happen often enough to cause distress. now, in your case, mIRC needs to get a chance to "/findText [tstamp] Yawhatnever:" (trailing space gone), since it would then find the right line. the only problem is that it has to first pass successfully through $hl_findLine(). quickest solution is to just add '*' to the end of the search term, ie:
return $fline($2, $replace($3, *, ?) $+ *, 1)
now it resembles /findText in that it could report partial matches, but if you use a timestamp then the prospect of error is really slim. it isn't perfect, but i don't expect that the potential problems would cause anyone too much grief.
an almost bulletproof solution could be:
1) store the line in a way that retains information about excess spaces. maybe store the line as a regex (see below)
2) use $fline() with a regular expression (changing spaces to \x escapes etc.) to find the exact line
3) seek to the line using one or more /findTexts
number 3) is a bit complicated:
/findText will never be able to find a line containing excess spaces if you use those excess spaces in the search term. it is also limited in that it doesn't accept wildcards or any type of search other than a sort of "isin". we need to cut the line up, either before or after the first excess space and use that chunk in /findText. with this approach, we need to be able to know which line our next /findText is going to take us to. to do this, you can use /findText -n one or more times to seek to the last occurrence of in the buffer. the maximal number of times to do this can be found with $fline() and a precise search with regex. now you know that every /findText you do will take you back through $fline(, , N-1, 2) $fline(, , N-2, 2) $fline(, , N-3, 2) etc. and you can use $fline().text or $line() to retrieve the line currently in focus and compare it to the saved line and check for equality.
why is this almost bulletproof? because if your exists on several lines in a single message that wraps in your window, /findText will treat those as separate occurrences and cycle through them individually! but i think i have a better chance of being struck by lightning while cashing in a winning lottery ticket than witnessing that happen in practice.
Beautiful script though, I learned a lot just figuring out how it works :P
thank you :* glad people are still learning and playing with mIRC. i'll be back on regularly soon
is not the best way to grab the bans. i've found that if the banlist has not been modified for a bit such as adding/removing of bans. that some or all of the bans will not show up this is an example of another way to do it that i set up via my bot.
look at his whole code. he checks $chan().ibl before initiating the dialog and will request the ban list from the server if the IBL isn't necessarily up-to-date. that is the most sensible method.
yes, but i didn't say "in a malicious way" but rather "in the same malicious way as $decode()"
while i don't fully agree with the initial decision to include it in the lock settings, i understand why it was added and why it would be difficult to remove it at this point.
see, the reason why $decode() was first locked was due to its popularity in spreading IRC worms. while mIRC code can be obfuscated in many different ways, $decode() became the de facto method for doing so, and IRC worms involving $decode() probably still exist on various shady sites and possibly a few infected machines in the IRC universe. therefore, there is a case to be made for it still being in the lock settings and still enabled by default.
$utfdecode() is relatively new and more difficult to figure out how to abuse. it doesn't share any of the above facts with $decode() and its addition to the lock settings was nothing more than a preemptive measure against potential abuse. the mere fact that it was added will have tipped off a few would-be skiddies who, if this setting were ever reversed, may use the opportunity to develop worms involving $utfdecode. but this is all unlikely. anyway, this was a deliberate change that we have to learn to live with, no matter ill-founded or inadvisable it may have been!
i'll show you an example on IRC :P
elseif - is used to "speed" up the script... when using elseif
no, that is a side effect of using it in one particular way. "elseif (...) { ... }" is just another way of writing "else { if (...) { ... } }". understand how 'if' and 'else' work, and the behaviour of 'elseif' will become apparent.
And (!$2) = ($2 == $null)
again, no. if (!$2) = if ($2 == $null) || ($2 == 0) || ($2 == $false). sure, you may not expect $2 to equal $false or 0, but it is important to realize that there is a difference between the two.
i dont see much differents with my script but i think i will use it this way if everybody likes it in this way.
:(
don't be pressured into using code that you don't want to. i can't say i blame you for not being altogether convinced, since very little appears to have been said about WHY an alternative approach might be useful for you in this case. the message you should take from these comments is not that using multiple text events for the same script is bad (since this is wrong), it's that using a single TEXT event here may, with a bit more work, result in code that is easier for you to read and maintain. i say 'a bit more work' since eliminating the TEXT events without any code factoring accomplishes nothing useful.
there is a relevant quote on Wikipedia's article on the abstraction principle:
Each significant piece of functionality in a program should be implemented in just one place in the source code. Where similar functions are carried out by distinct pieces of code, it is generally beneficial to combine them into one by abstracting out the varying parts.
an example of one such piece of functionality is the action shared by all !wale (sic) requests: "inc %allc". understanding this principle takes time and putting it into action takes practice, but it's a good one to code by and will enable you to make some sound decisions.
unique identifier, which would be appended to the beginning of each line within a single text file. Then use filter to pull up the relevant identifier, and discard the identifier from the output. This could be achieved by using filter -k and filtering through an alias which does a tokenize 32 on the input text, then returns $2-.
~= $read's 's' switch, which is actually much more efficient.
all should be elseif after the first ifff.
I often run into unworkability when I use an elseif right after an if upon sockread.
forgive me, but i sense there's still some confusion about what is one of the most fundamental programming concepts.
if (A) {
}
if (B) {
}
if (C) {
}
here, each of the conditions 'A', 'B' and 'C' are tested (unless the code is forced to end prematurely with /halt or /return). the if statements act independently. even in the case where 'B' can only be true if 'A' is false, or 'C' can only be true if both 'A' and 'B' are false, they are all still tested.
if (A) {
}
elseif (B) {
}
elseif (C) {
}
here, 'B' is only tested if 'A' is false. and 'C' is only tested if both 'A' and 'B' are false. when you're dealing with the case mentioned earlier, this code is ideal especially if 'B' and 'C' are computationally expensive checks, or if you want a final 'else' default case, or simply to adhere to good practice as in this snippet's case.
if you're not comfortable with a certain language construct then TEST IT. don't test it in the middle of your socket script, or with some other 1000 line script; test it in a simplified bit of code, and in a variety of different ways until you understand how it works.
For isnum, and I don't know why you put "1-", you could simply use: if ($2 isnum).
maybe because he wants to ensure $2 is positive? i mean, that much is obvious, but i can't see what else there is to be confused about.
also, i don't understand how you could use the phrase 'you could simply' and then include this in the same post
if ($regex(%n,/(.){ $+ $2 $+ }/)) {
leaving people out in the cold? huh?
the question was purely rhetorical. a bit of banter between 2 coders. to spell out exactly what was (already strongly) implied is akin to a comedian explaining a joke for the special few who did not understand it after the audience's laughter has died down. i give Fuzionx more credit than that.
Does using && and || within one paranthesis actually work? I thought you had to separate them.
it fails only in certain cases, only when used without '{', and only because of bugs in mIRC. for example:
//if (1 == 1 || 2 == 2) noop
ambiguous format. mIRC finds '1 == 1' to be true, sees '||' (OR) and attempts to short circuit part of the if statement by skipping ahead to the next relevant bit of code. it's not doing that very well, because the above is NOT really ambiguous. in fact, i'm going to go out on a limb and say that that error should not even exist because the rules governing the interpretation of if statements in mIRC are thorough enough to disambiguate every possible combination of code.
it requires rather deep knowledge of mIRC's interpreter to be able to predict the exact behaviour in all cases, but as long as you check your code carefully, and use braces, it's really just a matter of preference. i've seen a few good coders who don't use them at all. i find including them around each condition enhances readability, so i do :p
You talked about "super complicated" at the beginning and then stressed it again at the end.
from Lucius' comment:
if ($super($+(complicated,retireval))) {
that's where i got "super complicated retrieval" from.
The goes without saying you talked about easy and then ended it "not simple."
i defined what i meant by 'simple', then went on to say that i would also use Lucius' idea in the case where v1 is not necessarily 'super complicated', but merely 'non-simple'.
You jargonized your explanation, to me, in an awkward manner that didn't make it concise
jargon, awkwardness, and verbosity are 3 distinct and negative features that i don't recognize in my post. it may be slightly wordy, but i believe that's often necessary in order to be satisfactorily accurate - all things considered.
let alone those who utilize English as a second language.
are you genuinely worried about this?
I'm just being blunt to say what I want to say as a straight shooter.
that's fine, i like when people do that ;)
i can see 'philosophy' implying romanticizing or soapboxing (is that a word?) in some way, but i can't see how my post comes across as such. after all, we are discussing a scripting language and not campaigning to end hunger or for world peace ;P
what i dislike is the suggestion that i'm being 'roundabout' or speaking in riddles. it's not the first time i've been accused of it, which is puzzling because i do try to explain things in a direct way that can, primarily, be understood by the person or people i'm talking to, and, secondarily, to any other enthusiast who may come across the post. the distribution of information related to mSL is scattered enough as it is without me having to lead people on an easter egg hunt
For those wondering, $regsub (Not to be confused with $regsubex) is an older way of doing RegExp substitutions.
older, and also different, since with $regsubex() a lot more work is performed by mIRC in delaying the evaluation of the substitution parm until after replacements have been made. we should use $regsub() when we can and $regsubex() when we must. since the latter's syntax is a bit friendlier, it's often easy to misuse, and we can probably forgive a man for doing so.