Nov 25, 2006
irc.swiftirc.net #mSL

Activity Stream

jaytea liked a Page, $RandNow() - periodic random number generator  -  Aug 13, 2018
jaytea commented on a Page, $comma()  -  Aug 26, 2017

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

jaytea   -  Aug 28, 2012

@Hawkee i see you acquired the mircscripts.com domain name ;P how has that affected hits?

jaytea commented on a Page, Raccoon's Ban Rejoin (mIRC)  -  Aug 28, 2012

fake gif! argv wasn't oped 15 years ago!

jaytea liked a Comment, here  -  May 16, 2012
jaytea commented on a Page, jaytea's Highlight Thing  -  May 14, 2012

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

jaytea commented on a Page, Ban List Viewer/Remover  -  Feb 20, 2012

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.

jaytea commented on a Page, Auto Translator  -  Feb 14, 2012

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

jaytea commented on a Page, Auto Translator  -  Feb 12, 2012

it's not a bug: $utfdecode() can be used in the same malicious way as $decode().

jaytea commented on a Page, /BANSYNC Channel Ban Synchronization  -  Feb 01, 2012

good idea! how about the reverse process if it's possible that $1 is also a source of bans?

jaytea commented on a Page, Picwin balloontips  -  Jan 25, 2012

aw that was mean of me. brinxy deserved more than that ;P

jaytea commented on a Page, Optional +v -v for ChatSpace   -  Jan 25, 2012

Just a little refinement on the regex suggestion:

you haven't "refined" it by making the contents of the event bulkier than in Wader's example.

and once again, the original code is the cleanest and most suitable of the bunch :/

jaytea commented on a Page, !Time (PST)  -  Jan 15, 2012
  • jaytea slaps hixxy

you want "$gmt" in place of "$ctime($date $gmt)" :P

and isn't PST always GMT -8? you shouldn't be adding $daylight there since $gmt is unaffected by daylight savings. btw, good to see you around :*

jaytea commented on a Page, funny wale script :D  -  Jan 15, 2012

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.

jaytea commented on a Page, Sticky Note Custom Window  -  Dec 22, 2011

you said the unique identifier was prefixed to each line (not each note). and this would still be (more of) a problem for /filter without some extra logic to recognize whether a line contained a new note definition or was an extension of the previous line.

jaytea commented on a Page, Sticky Note Custom Window  -  Dec 22, 2011

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.

jaytea commented on a Page, Sgkk alias  -  Dec 21, 2011

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.

jaytea commented on a Page, Kick by Nick length  -  Dec 20, 2011

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 $+ }/)) {
jaytea commented on a Page, Kick by Nick length  -  Dec 20, 2011

there's no need for an ison check since you're only testing the results of $nick(). that is to say, $nick($1, ...) = %nick implies (%nick ison $1).

jaytea commented on a Page, /trollface  -  Dec 19, 2011

this has just as much right to be in the Aliases section than in Remotes, perhaps even more so. if an alias stands alone, and is not part of a larger script, then the most suitable place for it is in the Aliases section. why else would such a section exist? ;P

jaytea commented on a Page, Word Definition   -  Dec 15, 2011

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.

jaytea commented on a Page, Word Definition   -  Dec 14, 2011
Nice way of using a timer to check the 6 seconds delay between commands but isn't a variable less performance-consuming?

how do you think a timed variable works internally? :P

jaytea commented on a Page, Channel Check On Join  -  Dec 14, 2011

the best thing to do in this case is silence all raws received up until the "End of Whois" one, not just the most common ones. disabling #channelcheck should be done automatically when the end of whois raw is received.

jaytea commented on a Page, Channel Check On Join  -  Dec 14, 2011

LuminolBlue used /halt in those raw events to silence their output. the rest, i think, is self evident. look at your code and think about what it's doing.

jaytea commented on a Page, Channel Check On Join  -  Dec 14, 2011

not the same

jaytea created a Page  -  Dec 13, 2011
3 313 
jaytea commented on a Page, Away Popup Menu  -  Dec 10, 2011
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

jaytea liked a Comment, Protocol JANUS  -  Dec 09, 2011
Are you sure you want to unfollow this person?
Are you sure you want to delete this?
Click "Unsubscribe" to stop receiving notices pertaining to this post.
Click "Subscribe" to resume notices pertaining to this post.