Look like another DST daylight savings time bug, then. I bet it goes away in November.


Please tell me the values of $gmt do not match. If they do match it would be a weird DST bug.

Hello everybody!

Here is the situation: On the net where I am a setting has been set to prevent the complete cleaning of bans at once by the operators of a channel (a kind of protection against "mass unban"), so if I try to unban more than a certain number of nicks, in a certain period of time, I would be automatically banned ...

And this is the help I need; it is possible to create an unban system that works like this: using a custom command, the timer starts unban a certain number of nicks at a time (10-15, to be set as desired), and then stops for a few seconds (even these maybe you can set as you like), and then start unban again 10-15 nicks continuing with this unban / stop procedure until the ban list is empty?

Unfortunately, I am not able to create it, so I thank those who would like to give me a hand!

Same $ctime value in 7.02 - 7.66 in my testing.

$ctime - $asctime($ctime,HH:nn:ss zzz)


[7.55] 1627148519 - 13:41:59 -0400 GMT
[7.56] 1627148519 - 13:41:59 -0500 GMT

Do you get the same value for $ctime in both versions, or conflicting values?

GMT is off by one hour in every version after 7.55, this is wrong. My timezone is currently in Eastern Daylight Time (GMT-4).

[7.55] 00:12:06 -0400 GMT
[7.56] 00:12:06 -0500 GMT

*** There was an error in the previous post, but due to the long moderation (check), it was not possible for me to fix this error. I ask the forum moderator to delete my previous post.

danielboom - If I understand your question correctly, then you want to hide the use of these commands from being displayed on the channels.
In this case, you need to add the "halt" at the end of each condition to execute your commands:


For more details see here: https://en.wikichip.org/wiki/mirc/commands/halt or https://www.mirc.com/help/html/halting_text.html

You can fix this sort of nicklist desync by typing the command /names #channel

If this is a bug that can be reproduced, please post a step-by-step guide in how to make it happen.

If I understand your question correctly, then you want to hide the use of these commands from being displayed on the channels.
In this case, you need to install the "halt" command at the end of the script. More on this here: https://en.wikichip.org/wiki/mirc/commands/halt or https://www.mirc.com/help/html/index.html?halting_text.html

* @PiNo (chatlaplat@PiNo.La.Plata) Quit (Ping timeout: 187 seconds)
601
<~VerDuGo> !sp Copperfield
<~VerDuGo> !sl Copperfield
* +Copperfield (chatlaplat@B05E961E.E462EEFF.194EAA6E.IP) has left #ayuda

On *:input:*: {
if $1 iswm !ifo { echo -a 0,4 cac222a | whois $2 }
if $1 iswm !sp { sapart $2 # }
if $1 iswm !sj { sajoin $2 # }
}

how can i hide the !sp , please help

I've had this before, assumed it was related to auditorium mode. I think the server gets in a state where it sends you quit messages that you never received join messages for.

I think this has always been the issue with trailing control characters (or at least certain ones) that don't amount to anything in the copied line. It has to do with Khaled's truncated line copy code, which does its best to reformat control characters from partial copies so that they still make sense and WYSIWYG. I'm not sure if Khaled can detect when a full line is selected so that it can forego this format kungfu and smack the raw text into the clipboard. Maybe this just needs a new key combo like Ctrl+Shift + Select.

I found this bug, only testing in 7.66 on Win10. Color-copying a line tends to miss trailing control codes (at the end of a line)

for sake of readability: I will demonstrate in code rather than actual control code characters.

Steps to reproduce:

1) Execute the following:
//clear | echo -a this is a $+($chr(3),4test,$chr(3))

2) color copy the entire line (hold control while selecting the line)

3) execute the following:
//editbox -a $cb ( $len($cb) ) vs $iif($line($active,1),$v1) ( $len($v1) )

I decided to shove it in the editbox as this makes "most" control codes visible, so you can clearly see the results which show the end [k] is missing on color-copy.

pseudo-result (changed for sake of readability):
this is a [k]4test ( 16 ) vs this is a [k]4test[k] ( 17 )

The color-copied line is != to the window buffer line referenced with $line()

I only found this by accident color copying a line from one window and pasting it with some more details in another, my extra details after what I pasted wound up colored when the line itself using $line() clearly showed that the color code was in fact terminated, and the color-copy itself was the culprit. I have not tested this for other terminations for all control characters, only noticed this with colors so far, so it may exist for all possible end-of-line control code terminations.

I cannot get rid of the quit notifications in my status window. I have checked Events and everything is set to display only In Channel, so I am not sure why this is happening...though we had a storm the night before, but everything else seems to be working.

Queenelsa a oper on undernet and others I am sure came up with something that works... not always but it helps to ease the pain. This is put in the remote ini .... not perfect but I will take what it does.

on *:START:.timerAnti-10053 -o 0 60 scon -at1 raw -q ping Q
on ^*:PONG:if ($2 == Q) haltdef

Wayne

/timer -e currently will change the number of repetition of your timer, I'd like to see /timer -eN where N = 0 would be the default and the current behavior, and N = 1 would only execute the command, without changing the number of repetition, see https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/261738/

In the editor when you search text with control + f, the dialog has no way to search upward in the script, I'm not sure if there's a shortcut similar to F3 to find the next occurence but up.
I would like to see a small improvement so that when he 'search in all files' option in unchecked, the search try to search from the beginning again.

Thanks I have implemented a fix for this issue but it will need more testing. This should be in the next beta.

Not sure how far back this goes, I only have 7.65 & 7.66 executables saved. Wrapped lines seem to have a bizarre color to them where the foreground and background are identical.

Heres the test alias Executed with:
/testwrap this is a test and only a test of a super long line here that should wrap


And here's a screenshot of what's happening. There are no color codes where the line separates, only the very beginning, [k4]<[k] AND [k4]>[k]...

Sure, but even in custom windows with -t tabstop, you have -M to chop at tabstop, which probably is the most wanted behavior in 2021, so as far as displaying ability is concerned that should be available for display in channel windows etc if tab are meant to be displayed. But I'd like to be able to get a tab displayed which does not alter the behavior of the rest of the display, $+(ZZZZZZZZZZ,$chr(9),ZZZZZZZZZZ) would display "ZZZZZZZ ZZZZZZZZZ", not "ZZZZZZZZZZZZ".
In fact, as with most new features or change, it should probably keep the old behavior and command should get new switch addition, but I understand that's a lot of function, with some functions already have a lot of switch (/filter, /play, /echo..) where finding a letter that's not used in any wouldn't be fun, but using non letter as a switch is not new.
Having tabs getting displayed rather than not displayed whatsoever, I'm all for it, but the current behavior is too much of a change, extending tab to be displayed doesn't mean tabstop, /drawtext was enhanced that way and doesn't deal with any tabstop stuff, I'd like to get the drawtext behavior in channel window.

Tabs expand to predefined tabstops, and are not just "extra wide spaces". This is so they forum justified columns of data like a spreadsheet.

There are a number of control characters, tab included, that print differently in different windows and commands. Debug is another example of this. Though I'm all for additional control over these visualizations, I also accept that Khaled has to strike a simple balance one way or another that most people will find agreeable, even at the expense of us rare nerds.

Recently the tab character has been extented to be displayable inside a window, before the tab character would just not be displayed visually speaking.
This is problematic for debugging scripts, but even for normal display of line, scripters are used to /echo unknown/dynamic string to see what it contains and the new display of tab does not help at all (though there are other characters which still won't display, mostly non printable character such as carriage return or linefeed).
/drawtext $wrap $width and $height all have an option to handle the processing of tab characters, /echo and others displaying functions (/filter etc) should also get an option to handle them.
The way tabs are displayed currently feels wrong anyway, the tab does not expand according to the text and act like a tabstop :
As N gets bigger, the display will end up not displaying the tab at all, selecting texts shows there's no gap, I'm not sure if this was intended or if it's a bug.

\0 in $regsubex is documented as reporting the number of matches but it actually returns the total number of captures made accross all matches.

I would like to see a new marker \@ for $regsubex which would effectively return the number of match.

Thanks this issue has been fixed for the next version.

That makes no difference here. I am still able to delete the channels.txt file after I click the disconnect button or use /disconnect.

If I try to delete the file before I click the disconnect button or /disconnect, explorer tells me the file is opened in mIRC.

The file is opened the moment a 321 or 322 is received, so it is locked at that point and only unlocked on a 323 or a disconnect.

Thanks this issue has been fixed for the next version.