Forums Active Threads Past Month

Thanks for spotting this. The treebar was incorrectly using the same colors as the switchbar. The switchbar itself was using colors that were added before a number of other changes. I have changed both to use the text color for the bars so as to correctly stand out against the background.

Hi,
i have a channel on undernet and get a few trools frequently. I usually kick/ban them with "/msg x@channels.undernet.org ban #channel *!*@ip1.*,ip2.*,ip3.* 3h "
That works well for one or 2 lines. I want to script so I can send several lines to X. I know I can open a query window to a nick and use the /play "text" 1500. But that is not working with sending X Commands. Any help is much appreciated.

Forgive my ignorance but I am unable to find spoton.dll. Have looked in the zip and on github. If you could point me in the right direction I would be very grateful.
Thanks in advance!

Hello Khaled,

If the forum time is UTC, then the the difference between actual time and the UTC - 7 hours according to the post time of the topic of Sunlily. According to Sunlily the time showed on mIRC was UTC - 8 hours which was wrong.

According to my investigation there is an issue in mIRC with these two timezones:

Currently set in mIRC (don't know which version):
(UTC-08:00) Baja California
(UTC-08:00) Coordinated U:niversal Time-08
(UTC-08:00) Pacific Time (U.S. and Canada)

Should be set as in mIRC:
(UTC-07:00) Arizona
(UTC-07:00) La Paz, Mazatlan
(UTC-07:00) Mountain Time (U.S. and Canada)
(UTC-07:00) Yukon

I think there is an issue with the Pacific and Mountain time in mIRC. Please check these two timezones in mIRC Khaled?

Is there a way to change the color of the new DCC Progress Bar? I use a black background and I can't see the bar unless I select the line nick.

Thank you.

Dear Epic,

thank you for your reply ,
i already see all link you give to me

script not working
{
/timer 0 900 msg #" your channel " "your messages"
/timer 1 10 msg #" your channel " "your messages"
}

and changes to

on *:connect:{
if ($network == "your server") {
/timer 0 900 msg #" your channel " "your messages"
/timer 1 10 msg #" your channel " "your messages"
}
}

my script is working well now

thank you

Obviously, to do this you need to create a script that will do what you want.

To get started, try reading/studying the help documentation: https://www.mirc.com/help/html/index.html?remote.html

In addition, something similar using a timer has already been discussed in the next forum thread: #Post272454

If after reading the information in the links you still have difficulties creating a script or it is not exactly what you want to do, then try to describe your idea in more detail, as well as provide text examples/screenshots/handwritten drawing/scheme on a sheet of paper or something else, so that we understand exactly what you want to do.

Dear Sir / Madam

please help how to write timer in mirc script
i try writein status " /timer 3 5 msg #chan This test message using timer " <<< it work well
but not work when i write in remote (script area)

please help how to do that

i want to post a message in my channel every 30 minutes

thank you

Hi Khaled,

I would like to ask you if it is possible to add an identifier, for example $markasread, that allows you to return $true or $false when the windows are all read or not?

Example:

Talking about the fixed code:

You cannot comment code reliably with the ';' if it's not starting the line. You can check this thread for more informations about how ; can in fact be used to comment only a single statement out of multiple statement separated by a |, but is has a quirk and you cannot comment out the last statement if it ends with a } or the } is parsed incorrectly, but if no } are involved on the line, you can comment a single statement, even the last :
alias test {
echo -ag ok | echo -ag ok1 | ;echo -ag ok2
}
Will only display ok and ok1, it's also worth noting that the else statement does not have this problem and you can always comment out the last statement of a single line else statement with multiple statements in it as is the case in the above link.


You also still have one extra } in this code, making 'alwayscommand' outside on the on text event because spaced out } cannot be commented out if ; isn't starting the line.

Focusing only on the line "IF (1 == 1) { Command1 | Command2 } ; | TestCommand3", what's happening there is that } in itself acts as a statement separator:
//if (1 == 1) { echo -ag ok | echo -ag ok1 } echo -ag ok2
is equivalent to
//if (1 == 1) { echo -ag ok | echo -ag ok1 | echo -ag ok2 }
If you change the condition to 1 == 2 for example, 'ok2' is not echoed
It's known that } act as a statement separator, same as |, and you don't need prior { } involvement to see this:

//echo -ag ok } echo -ag ok1
is equivalent to
//echo -ag ok | echo -ag ok1

So then ';' is seen as starting a statement but you see, the quirk with ; and commenting out single statement is that it correctly works stopping at a | but not a }, so this is the same as
IF (1 == 1) { Command1 | Command2 | ; | TestCommand3 }
Where you just have an empty commented out statement, and /testcommand3 is executed 'normally'

Although the problem is as simple as "; starting a statement which is not starting a line but is the last statement in a line doesn't stop at } correctly", given Khaled's answer it's likely that fixing it would require more work than just adding that logic once somewhere. But of course I would like to be able to comment out single statement like that so I wouldn't mind a fix.

I wouldn't recommend anyone trying to comment out single statement out of multiple statements separated by | on a single line or trying to commentate anything with ; if it's not starting the line anyway because of all of these, but if you're aware of them, you can actually workaround them. For example you can solve the issue reported in the mentioned url by adding a fake last empty statement, just by adding a spaced out pipe character, which works for your case as well, coming from this code:
and trying to get testcommand3 not to be executed without changing much in the code, your best bet is

But trying to use ; when it's not starting a line and when it's not starting a statement properly either (properly aka after the } in your original example isn't proper) is just not possible.

Thank you for replying .

What am I doing wrong in the $calc ? Too many spaces ? Not enough ?

Granted....all typos I'll fix. None of which have anything to do with or impact the issue being identified.

You have multiple issues in your example.

1. The "IF" cannot touch the "(".
2. The "==" cannot touch the numbers.
3. The "{" cannot touch the "Command1".

Fixed example:

For a better handling and managing of a custom help file, such as updating it from the web, I would like to be able to close an help file from a script via /winhelp.

/winhelp -n <name> <file> [keyword]
/winhelp -c <name>

I've done some searches under "Comment" "Bracket" Brace" and "{" and "}" and not found this being discussed anywhere.

I've just spent many hours trying to debug a script only to discover that the a comment at the end of the line that starts with a ; character after the code does not stop the parser from reading and processing a } character and therefore unintentionally closing a loop/event. Running v7.76

e.g.
Will output Command1 and Command2.

The "AlwaysCommand" will never execute as mIRC will treat the last } after "TestCommand3" on the IF line as the closing bracket for the ON TEXT event. You can see this instantly in the way the script window will indent the code.

Remove that supposedly commented text " | TestCommand3 }", or even just the "}" and everything will ident and execute as expected.

Having read this post and the replies I don't expect this is critical enough to warrant a serious "fix", it sounds like it might be very difficult to fix.

I'm capturing here so some future fool like me can find an answer before banging their head off the desk for several hours.

Khaled: I am constantly in awe of the power and scope of the script engine "as-is". Thanks for everything.

Now the reported problems are working perfectly

Thank you

Now the reported problems are working perfectly

Thank you

This is likely the same issue as with your other post. Please see the next beta.

Thanks, I will be releasing another beta that fixes this issue.

Hi,
I check that the mIRC windows have display problems

mIRC v7.76.2691

Hi,
Download the new beta version and when you replace the mirc.exe file with the new beta version 7.76.2691 and start the mIRC, verify that the mIRC is not available in the DCX.dll file.

* /dll: unable to open file 'D:\newmirc\scripts\dlls\dcx.dll' (line 11, script3.ini)

I meant to show the built-in 'echo' command is called instead of the custom echo alias just created:
//alias echo !echo -ag custom echo called | var %exec !echo -ag ok | [ %exec ] | alias echo
The [ ] are required from the editbox to force a commnand starting with a variable (or $ident), I got rid of the ! inside the variable name, hopefully this is clearer.
That being said, I understand this is unrelated to the issue.

My bad then, I hadn't tried it.

This is how I view it as well, however I did not realize it means this report is invalid because indeed $testqpfx() is evaluated before knowing the command has the . prefix.

I realize now as well that $show is a global value, not a local identifier, which is why it changes per routine whenever you have silenced command, with mIRC reverting back the value to the original value:

alias temp echo -ag $1
alias myalias echo -ag $show | .noop $temp($show) | echo -ag $show
/myalias will echo $true, $false, and $true again

I suppose that's just the way it works then, and there's no issue so to speak, after all.

Nice try :-) That is part of the variable definition and can appear anywhere in a command. It has nothing to do with command prefixes.

Both items were hopefully fixed as mentioned in versions.txt, 27/11/2022 - mIRC v7.72, 11.Fixed !. command prefixes used infront of while/if commands affecting following command.

This is a similar issue to the current post.

I had already looked through the code when I posted my first reply, however I looked through the code again and now I am even more uneasy about the idea. The /!. prefixes are meant to be parsed once a command is fully formed and ready to be executed. In the case of the original post, the variable is not a command yet. It is sent to the variable parser to be evaluated in order to form the final command, which can then be executed, and only then are the prefixes parsed and applied. What you are requesting is for the evaluation parser to make assumptions about the start of the line during the process of evaluation, before the line has been fully constructed, and to apply these to all subsequent identifers/variables/etc. - not once the entire command line has been constructed and is ready to be executed, as has always been the case.

As you know, I generally try to avoid making changes that can affect backward compatibility, so this is not a change I would make.

Hello Maiko, im not quite sure what it is your asking for but i have this for you so far..

on *:TEXT:!world:#:{ worldtimes }

worldtimes {
echo -a 96 -----------------: Local Time: $asctime($ctime, HH:nn AM/PM) :-----------------
echo -a 13 --: Argentina (Buenos Aires): 8 $asctime($calc($ctime + (0 - 3*3600)), HH:nn tt) ; UTC offset: -3 hours
echo -a 13 --: Australia (Sydney): 8 $asctime($calc($ctime + (0 + 10*3600)), HH:nn tt) ; UTC offset: +10 hours
echo -a 13 --: Belgium (Brussels): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Brazil (Sao Paulo): 8 $asctime($calc($ctime + (0 - 3*3600)), HH:nn tt) ; UTC offset: -3 hours
echo -a 13 --: Canada (Toronto): 8 $asctime($calc($ctime + (0 - 4*3600)), HH:nn tt) ; UTC offset: -4 hours
echo -a 13 --: Chile (Santiago): 8 $asctime($calc($ctime + (0 - 4*3600)), HH:nn tt) ; UTC offset: -4 hours
echo -a 13 --: China (Beijing): 8 $asctime($calc($ctime + (0 + 8*3600)), HH:nn tt) ; UTC offset: +8 hours
echo -a 13 --: Denmark (Copenhagen): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Egypt (Cairo): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Finland (Helsinki): 8 $asctime($calc($ctime + (0 + 3*3600)), HH:nn tt) ; UTC offset: +3 hours
echo -a 13 --: France (Paris): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Germany (Berlin): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Greece (Athens): 8 $asctime($calc($ctime + (0 + 3*3600)), HH:nn tt) ; UTC offset: +3 hours
echo -a 13 --: India (New Delhi): 8 $asctime($calc($ctime + (0 + 5.5*3600)), HH:nn tt) ; UTC offset: +5.5 hours
echo -a 13 --: Indonesia (Jakarta): 8 $asctime($calc($ctime + (0 + 7*3600)), HH:nn tt) ; UTC offset: +7 hours
echo -a 13 --: Iran (Tehran): 8 $asctime($calc($ctime + (0 + 4.5*3600)), HH:nn tt) ; UTC offset: +4.5 hours
echo -a 13 --: Ireland (Dublin): 8 $asctime($calc($ctime + (0 + 1*3600)), HH:nn tt) ; UTC offset: +1 hour
echo -a 13 --: Israel (Jerusalem): 8 $asctime($calc($ctime + (0 + 3*3600)), HH:nn tt) ; UTC offset: +3 hours
echo -a 13 --: Italy (Rome): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Japan (Tokyo): 8 $asctime($calc($ctime + (0 + 9*3600)), HH:nn tt) ; UTC offset: +9 hours
echo -a 13 --: Mexico (Mexico City): 8 $asctime($calc($ctime + (0 - 5*3600)), HH:nn tt) ; UTC offset: -5 hours
echo -a 13 --: Netherlands (Amsterdam): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: New Zealand (Wellington): 8 $asctime($calc($ctime + (0 + 12*3600)), HH:nn tt) ; UTC offset: +12 hours
echo -a 13 --: Norway (Oslo): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Philippines (Manila): 8 $asctime($calc($ctime + (0 + 8*3600)), HH:nn tt) ; UTC offset: +8 hours
echo -a 13 --: Poland (Warsaw): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Portugal (Lisbon): 8 $asctime($calc($ctime + (0 + 1*3600)), HH:nn tt) ; UTC offset: +1 hour
echo -a 13 --: Qatar (Doha): 8 $asctime($calc($ctime + (0 + 3*3600)), HH:nn tt) ; UTC offset: +3 hours
echo -a 13 --: Romania (Bucharest): 8 $asctime($calc($ctime + (0 + 3*3600)), HH:nn tt) ; UTC offset: +3 hours
echo -a 13 --: Russia (Moscow): 8 $asctime($calc($ctime + (0 + 3*3600)), HH:nn tt) ; UTC offset: +3 hours
echo -a 13 --: Saudi Arabia (Riyadh): 8 $asctime($calc($ctime + (0 + 3*3600)), HH:nn tt) ; UTC offset: +3 hours
echo -a 13 --: Singapore (Singapore): 8 $asctime($calc($ctime + (0 + 8*3600)), HH:nn tt) ; UTC offset: +8 hours
echo -a 13 --: South Africa (Johannesburg): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: South Korea (Seoul): 8 $asctime($calc($ctime + (0 + 9*3600)), HH:nn tt) ; UTC offset: +9 hours
echo -a 13 --: Spain (Madrid): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Sweden (Stockholm): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Switzerland (Bern): 8 $asctime($calc($ctime + (0 + 2*3600)), HH:nn tt) ; UTC offset: +2 hours
echo -a 13 --: Thailand (Bangkok): 8 $asctime($calc($ctime + (0 + 7*3600)), HH:nn tt) ; UTC offset: +7 hours
echo -a 13 --: Turkey (Istanbul): 8 $asctime($calc($ctime + (0 + 3*3600)), HH:nn tt) ; UTC offset: +3 hours
echo -a 13 --: Turkey (Ankara): 8 $asctime($calc($ctime + (0 + 3*3600)), HH:nn tt) ; UTC offset: +3 hours
echo -a 13 --: United Arab Emirates (Abu Dhabi): 8 $asctime($calc($ctime + (0 + 4*3600)), HH:nn tt) ; UTC offset: +4 hours
echo -a 13 --: United Kingdom (London): 8 $asctime($calc($ctime + (0 + 1*3600)), HH:nn tt) ; UTC offset: +1 hour
echo -a 13 --: United States (Chicago): 8 $asctime($calc($ctime + (0 - 5*3600)), HH:nn tt) ; UTC offset: -5 hours
echo -a 13 --: United States (Los Angeles): 8 $asctime($calc($ctime + (0 - 7*3600)), HH:nn tt) ; UTC offset: -7 hours
echo -a 13 --: United States (New York): 8 $asctime($calc($ctime + (0 - 4*3600)), HH:nn tt) ; UTC offset: -4 hours
echo -a 13 --: Vietnam (Hanoi): 8 $asctime($calc($ctime + (0 + 7*3600)), HH:nn tt) ; UTC offset: +7 hours
}

OR

Or you could place this below in your alias in mIRC, Use !time
to echo all the times, If you want to message just 2 times you could do somthing like this..

on *:TEXT:!time:#:{
/msg # Argentina (Buenos Aires): $asctime($calc($ctime + (0 - 3*3600)), HH:nn tt) ; UTC offset: -3 hours
/msg # Local Time: $asctime($ctime, HH:nn AM/PM)
}

if you need anything more specific, ill try to help, thoe i havent really explained the code to you , i hope you can use somthing from this script

Well, the other command prefix '!' is parsed correctly from a %variable though:
//alias echo !echo -ag custom echo called | var %!noop !echo -ag ok | [ %!noop ] | alias echo


More about the silencing '.':
- https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/270904/ In this thread you fixed the '!' command prefix being propagated to the first command associated with the if/while/else, however you did not touch the '.' silencing behavior despite Iire asking about it specifically in the last post.
- https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/162820/ this is a more known about behavior of the '.' where $show changes to $false inside a silenced command while the original routine was an alias called normally, reported a lot but never fixed

But this defeats the purpose of having a dynamically created command 'call' including the prefixes.
In fact, creating dynamic custom command call is a way to get rid of some cascade of if/elseif statement to dispatch stuff (function pointer if you will).

Given all those informations, would you reconsider fixing '.' and $show's behavior? Please keep in mind that for a script to break after fixing any of this, it would have to be using dynamic command call with silencing prefix and expecting it to not silence it, or silencing an if statement and expecting it to silence the first command which belong to that if statement only, or expect $show to change from $true to $false inside a silenced command when it was $true before it. Those can only be wrong expectations.