mIRC Home    About    Download    Register    News    Help

Active Threads | Unanswered Past 24 hours | Past 48 hours | Past Week | Past Month | Past Year
Bug Reports Jump to new posts
Re: [v7.68.1100] Batch or znc.in/playback Khaled Yesterday at 08:29 PM
Quote
These two scenarios are exactly the same to me. How do you think they are different?

I explained this in my post.

Quote
With that in mind, is mIRC adhering to this?

Yes, this is not the issue.
18 695 Read More
Bug Reports Jump to new posts
Re: /beep sound changed TECO Yesterday at 03:30 PM
Thank you wink
6 297 Read More
Scripts & Popups Jump to new posts
Re: Custom windows in script Loki12583 20/05/22 06:52 PM
Text events do not trigger from your own messages. You need to use INPUT event.
1 66 Read More
Developers Jump to new posts
Re: Spotify now-playing for mIRC turbosmurfen 19/05/22 09:49 PM
Thanks for the report Dee3D. I know what's the problem is. It's looking for a chromium window which Spotify and Battle.net client use. I will add back the old check. Sure it's reading through processes for Spotify. I think this is the best option to fix the issues.
16 3,017 Read More
Bug Reports Jump to new posts
mIRC beta Khaled 16/05/22 08:13 AM
The latest beta is v7.68.1159 and can be downloaded here. It includes the following changes:

Note: this beta moves your channel favorites from mirc.ini to channels.ini. This means that older versions of mIRC will not see your favorites once mirc.ini has been updated.

Note: echo-message support can be tested on eg. Libera-Chat which only supports echo-message and not labeled-response, and Snoonet that suports both of these tokens. In the beta, echo-message is currently automatically enabled if a server supports it.

Quote
Beta v7.68.1159 changes:
1.Item 16, updated.
2.Item 17, updated.
3.Item 18, updated, library would not compile, needed changes.
4.Item 19, updated, library would not compile, needed changes.
5.Item 14, fixed.
6.Item 20, changed. In cases where the current status window
server does not exist in the servers list, the server address
is added temporarily to the servers list in the connect dialog
and selected, since pressing okay in the connect dialog will
set the status window server. If you edit the server, it becomes
permanent.
7.Item 21, added.

Beta v7.68.1100 changes:
1.Item 3, enabled in this beta.
2.Item 9, https://forums.mirc.com/ubbthreads.php/topics/270238
Added support for disabling/enabling on the fly.
3.Item 9, https://forums.mirc.com/ubbthreads.php/topics/270251
Added support for parsing echoed CTCP messages.

This needs to display the echoed CTCP message as it appears
when "sending" from a client not "receiving" by a client. Since
the sent CTCP message is displayed differently depending
on context, eg. status/channel/query window, /raw, /ctcp, etc.
this requires parsing to match the associated displayed
line and only updating the message part of the displayed
line from the raw PRIVMSG/NOTICE.

4.Item 13, https://forums.mirc.com/ubbthreads.php/topics/270249
5.Item 14, https://forums.mirc.com/ubbthreads.php/topics/270259
6.Item 15, fixed.

Beta v7.68.933 changes:
1.Item 1, changed.
2.Item 2, changed. This means that older versions of mIRC will no
longer see your favorites/recent channels since they are in a
different file. This also means that any scripts that try to read
the [chanfolder] section in mirc.ini will no longer work.
3.Item 3, changed. Without this, the windows media library seems to
be fully loaded/unloaded whenever a sound is played. On my system,
this displays a wait cursor briefly every time a sound starts and
stops. I have been trying to a find solution to this for quite a
few versions. This change is a somewhat convoluted method to prevent
the media library from unloading. Tested under XP to 11. This speeds
up consecutive sound playing, eg. multiple beeps, significantly.
4.Item 4, extended.
5.Item 5, added.
6.Item 6, changed.
7.Item 7, added.
8.Item 8, added.
9.Item 9, experimental. For more information see
https://ircv3.net/specs/extensions/echo-message

This feature works with or without the labeled-response token
enabled, however:

1) Without labeled-response, the correlation between sent and echoed
messages is not reliable. The client cannot match on message content
since the returned echo message can be different from the sent
message, and echo messages may not arrive in the order messages
were sent.
2) If you use /msg nick,nick to send to the same nick twice, some
ircds will only send one message to nick, removing the duplicate
nick, while other ircds will send to each nick regardless. So the
number of echoed messages can differ depending on the ircd. Since
the client needs to know when all messages have been echoed, mIRC
now removes duplicate targets from outgoing PRIVMSG/NOTICEs.

In addition:

a) When a message is sent, it is displayed in a grayed color in the
status/query/channel window until an echo is received from the server,
at which point the message is redrawn in a normal color. Note:
1) If "no such nick" is received, the line remains grayed.
2) If sent to multiple nicks and one of them returns "no such
nick", the line remains grayed.

b) Own messages displayed in a window are replaced with the echo
message. The IRCv3 spec says that the echo message can be different
from the message you send, eg. the server/channel might filter out
color codes, block spam, etc. and that the echo message should
replace your message in a window to show what was actually received
by the user/channel.

10.Item 10, changed.
11.Item 11, added.
12.Item 12, https://forums.mirc.com/ubbthreads.php/topics/270224

Changes:
1.Changed servers list in connect dialog to always group servers
with the same group name together.
2.Changed location of channels favorites to channels.ini file. This
will allow users to update/edit this file without having to modify
their mirc.ini settings file. If [chanfolder] or [chanhist] exist
in mirc.ini when mIRC starts up, they will be automatically moved
to [channels] and [recent] in channels.ini.
3.Changed how the Windows media library is loaded to allow sounds
to be played without delay.
4.Extended $mouse.key to support detecting right-shift/control/menu
keys and capital/scroll/numlock.
5.Added /bset -z switch that makes an empty &binvar or zeros an
existing &binvar.
6.Changed regex parser to use less stack memory during recursion.
7.Added $keylparam identifier to on KEYUP/KEYDOWN that returns the
result of the lParam value in the event.
8.Added support for numeric 005 UTF8ONLY token. If enabled on a server,
this overrides the UTF-8 setting in Options/IRC/Messages to always
UTF-8 encode/decode messages on a connection.
9.Added support for IRCv3 echo-message. Current implemention tracks
outgoing messages, filters echoed messages, and grays displayed
messages until the server confirms they have been received by the
target, and replaces own messages with echoed messages, for both
PRIVMSG/NOTICE and nicks/channels.
10.Changed CAP request on connect to combine multiple tokens in one
line to speed up server reply.
11.Added $mircpid identifier that returns mIRC's process id.
12.Fixed nested while loops continue bug.
13.Changed how nick event is handled on connect to get around ZNC
initial nick change affecting query window with same nick.
14.Fix alignment of checkboxes in Address Book dialog.
15.Fixed /sound CTCP event not displaying message if filename is ""
empty.
16.Updated OpenSSL library to v1.1.1o.
17.Updated CA root certificates cacert.pem file.
18.Updated zlib library to v1.2.12.
19.Updated TagLib library to latest fixes.
20.Changed connect dialog to show server for current status window
at top of servers list if not already defined in list.
21.Added on PARSELINE identifier $parseem, returns $true or $false
depending on whether mIRC thinks the incoming line is an echoed
message due to IRCv3 echo-message being enabled.
1 244,244 Read More
Bug Reports Jump to new posts
Re: mIRC Address Book Khaled 14/05/22 04:37 PM
Thanks this should be fixed in the next beta.
3 292 Read More
mIRC Help Jump to new posts
Re: RSS TECO 12/05/22 07:58 PM
Originally Posted by kap
I made one not too long ago that works under current mIRC, but I packaged it as an add-on for the Peace-and-Protection script. (Because I wanted to re-use some utility code in PnP - https://github.com/peace-and-protection) You'll find the add-on in the PnPAddons422 repository. While it may not answer your main question 100%, anyone is free to grab whatever code you need to make it work under standard / vanilla mIRC.

N.B.:
1) It doesn't send to channel(s), only to a custom window in your mIRC;
2) It doesn't use dlls, but COM. I tested it to work under Win 10;
3) It only works with selectnodes rss/channel/item, meaning it won't work for the Atom standard. (Only RSS);
4) PnP uses option dbu for dialogs, which presents display issues on Windows with desktop scaling > 100%;
5) PnP is over 20 years old, but still runs a dream. Some ppl may yell at you for using it though!

Hope this helps smile

Code incomplete. That's why I couldn't test it.
4 314 Read More
Developers Jump to new posts
Re: IRCv3 echo-message, queries get separated Khaled 08/05/22 08:18 PM
I have been testing echo-message with the latest version of ZNC.

It appears that ZNC's echo-message implementation is not quite working correctly in the way it echoes some messages, such as CTCP messages. It seems to be filtering them out and not echoing them back to the sending client.

For example, if I use:

//raw PRIVMSG nick : $+ $chr(1) $+ hello $+ $chr(1)

ZNC seems to filter out the echoed PRIVMSG from the server.

If I test this with a non-CTCP-encapsulated message:

//raw PRIVMSG nick :hello

The expected echo does arrive.

If I test this by connecting directly to the server (in this case, the latest version of InspIRCd), both of the above are echoed back as expected.

This means that echo-message will not work as expected when connecting through ZNC at this time. mIRC would be waiting for an echo for the PRIVMSG/NOTICEs it has sent without receiving them, even though echo-message is enabled.

For the time being, I have stopped testing echo-message with ZNC because of the above issue.

Note: the next beta will fix a number of issues with echo-message, so it would be best to wait until that beta is released before testing echo-message further.
13 724 Read More
Bug Reports Jump to new posts
Re: 7.68.933 - /me not displaying correctly. Khaled 05/05/22 09:35 PM
Thanks for testing this.

For those not aware: this is related to the echo-message feature whose specification states that when an echo is received, the client should replace the message currently displayed in the window, ie. your own message, with the echoed message, since the echo may be changed in some way, eg. the server/channel might strip control codes, censor words, etc. so that you can see what the target actually received as the message.

Right, so this means that before replacing a line with its echo, the client will first need to check if the echo is using a format that needs to be parsed in a specific way, which in this case would be the CTCP ACTION format. But the echoed message needs to be re-parsed/displayed as if it is being sent, not received. Some CTCPs are displayed differently depending on context, so it's not as simple as just replacing the message, eg. PING is displayed differently depending on whether it is being sent, received, or replied to, SOUND is displayed differently depending on whether it is displayed in the status window or channel/query window, and all are displayed differently if they are sent using /raw, and so on.

It's also not clear how this would affect the display of messages customized by scripts.

I'm going to make a few changes to the next beta and we'll see how it goes from there.
1 191 Read More
Bug Reports Jump to new posts
Re: 7.68.933 - "/cap req -echo-message" display bug. Khaled 04/05/22 12:02 PM
Quote
After more testing found another bug. This one is a bit more strange as I can only replicate on Libera.Chat.

This is the same issue :-) Please wait until the next beta before testing -echo-message further as it is not supported in the current beta.

The reason you are seeing different behaviours is that Libera.Chat only supports echo-message, while Snoonet supports echo-message and labeled-response. The parsing of their echoed messages will be different since, without labeled-response, there is no clear correlation between sent and echoed messages. I have described this issue in beta.txt.

In fact, it may even be the case that different ircds handle enabling/disabling echo-message differently, and there may be a timing issue since echoed messages will only be returned once a message has reached its destination. So, by mixing multiple enabled/disabled/send/receive without/without labeled-response, the results could be interesting.

This is why I may decide to not support echo-message without labeled-response in the final release. In that case, if a user decides to manually enable echo-message without labeled-response, they will then also need to write a script to handle echoed messages themselves.

Update: I tested your script on Libera.Chat. In some cases, it showed the expected result, in other cases, it showed your above result, with the following debug information:

Quote
-> lithium.libera.chat PRIVMSG #thisisatest :6
-> lithium.libera.chat PRIVMSG #thisisatest :5
-> lithium.libera.chat PRIVMSG #thisisatest :4
-> lithium.libera.chat CAP req -echo-message
-> lithium.libera.chat PRIVMSG #thisisatest :3
-> lithium.libera.chat PRIVMSG #thisisatest :2
-> lithium.libera.chat PRIVMSG #thisisatest :1
-> lithium.libera.chat CAP req echo-message
-> lithium.libera.chat PRIVMSG #thisisatest :Testing123
-> lithium.libera.chat PRIVMSG #thisisatest :Testing1234567890
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :6
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :5
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :4
<- :lithium.libera.chat CAP nick ACK :-echo-message
<- :lithium.libera.chat CAP nick ACK :echo-message
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :Testing123
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :Testing1234567890
-> lithium.libera.chat QUIT :

Dissecting this: notice that even though we sent two CAP reqs, we did not receive confirmation from the server of the CAP req changes until after several PRIVMSGs were sent. From mIRC's viewpoint, the echo-message status only changes once it has received the CAP ACK confirmation from the server. So in the above series of events, there is a disconnect between what mIRC thinks should/should not be echoed and what the server thinks should/should not be echoed. When combined with the lack of labeled-response on Libera.Chat, and perhaps lag/timing, the result is not going to look pretty.

In the above case, mIRC sends the "CAP -req -echo-message" to disable echo-message, and then a few seconds later sends "3" "2" "1". The server treats "3" "2" "1" as not needing echoes because echo-message has been disabled but mIRC does not receive the "CAP ACK -echo-message", confirming that echo-message has been disabled (which the server could possibly decline with a NAK), until after these messages are sent, so as far as mIRC is concerned echo-message is still enabled for them, expects echoes for them, grays them out, etc.

I would say that, while it's great that you are testing this, echo-message is very likely meant to be either enabled or disabled :-)
2 282 Read More
Developers Jump to new posts
Re: IRCv3 echo-message Khaled 03/05/22 04:22 PM
Quote
Of course there is, clearly, the msg even turns gray for few ms before appearing in the chan after sending it.

That is what it is meant to do.

The purpose of echo-message is to allow a client to visually display to the user when a message has reached its destination.

See my above reply for a fuller explanation.
3 251 Read More
Scripts & Popups Jump to new posts
Re: Send message via webhook on mirc to Discord Talon 02/05/22 09:42 PM
By webhook, I assume you mean some form of HTTP API. You would need to look at $urlget()

Here's the info directly from the help file: /help $urlget

Note: the user:pass@address portion of the URI defines an OLD base64 authentication method (http response of: 401 unauthorized) This is NOT login/password for anything and everything, like forums or web API's etc... Logging into websites and API's you would need to form the proper query-string containing the form items and their values, for either GET method or POST method.

Once doing said login information, most sites give you a Unique ID as a cookie, which you MUST extract yourself from the $urlget().reply .. Any following calls to this website requiring this data must be formatted as valid header fields in a binvar and passed to $urlget() so it includes your extended header information (like cookies). Extra header information are NOT persistent across multiple $urlget() calls, unlike a browser.

Without further information on how you need to interact with your "Webhook" this is the best I can offer.

Quote

$urlget(url,hgpuadfbrtikc,target,alias,headers,body)
Downloads content from specified http/https address. Returns id number. Calls alias with id number as parameter when transfer completes.

url = http/https://user:pass@address:port/file?parameters

options =

hgpuad = head, get, post, put, patch, or delete
fb = file or &binvar
r = resume
t = use .part file
i = ignore SSL errors
k = prevent redirects
c = cancel

target = file or &binvar
alias = called on completion
headers = &binvar
body = &binvar

If the call fails, for any reason, it returns an id of zero.

$urlget(N/id) can be used with properties: url, redirect, method, type, target, alias, id, state, size, resume, rcvd, time, reply
1 241 Read More
Feature Suggestions Jump to new posts
Option to differentiate between notices Valware_ 02/05/22 02:58 PM
Hi there!
Apologies if this has been posted before, I did a quick search and couldn't find anything.

I was wondering it would be possible, in the options dialog in the IRC tab, in the 'Show in active:' box, to have an extra option for Server Notices.
This way we would be able to leave server notices unchecked, and normal notices checked, which would be very valuable to have especially when dealing with large-scale networks where there are a ton of server notices that I don't need to see in the active window =]

Thanks, and have a great week.
0 135 Read More
Developers Jump to new posts
Re: Proposal: draft/external-reg Valware_ 02/05/22 02:53 PM
Sorry, I'd only just seen your message.

Why should it be necessary to ise HTTP in order to access IRC

Because the browser has been around half as long and has had a billion more advancements. This is a small part of an effort to provide server administrators with the option to delegate their registration process to a website..

This could be for a number of reasons, including things like the host wanting to truly customise the registration process and have it exactly how they like. You can very easily, with much user friendliness, do things like upload a profile photo which, if their client supports it, can also be their IRC avatar (dw METADATA spec rewrite underway). Also, whenever anyone is told to sign up to anywhere outside of IRC circles, everyone is very used to "we sign up on websites".

Aside from this, there is Anope services which provides an optional webpanel for user registration, and DALEK which provides straight up full wordpress integration, where the registration form for the network lives.
3 400 Read More
Bug Reports Jump to new posts
Re: while loop + continue Khaled 02/05/22 11:31 AM
Thanks this issue has been fixed for the next version.
1 183 Read More