mIRC Home    About    Download    Register    News    Help

Print Thread
#252880 15/05/15 04:50 AM
Joined: Apr 2010
Posts: 969
F
Hoopy frood
OP Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
With the rise of CAP, there is a major hurdle mIRC is unable to scale without QUITE a bit of fancy scripting: Creating CAP modules that handle messages estranged from the IRC protocol. For example, lets say the server supports "CAP REQ :server.net/usermeta" that causes all messages(PARTS, JOINS, PRIVMSG, etc) from users to be prefixed with something similar to:
Code:
usermeta:admin=false;registered=true;ssl=true :Nick!ident@host PRIVMSG #channel :Message
There's no way to alter that message so mIRC's internal event handling can process it. The work around(s) requiring EXCESSIVE amounts of coding to either create a proxy that middleman's the connection or re-implementing via mSL all of mIRC's event handling for any message that originate from another user.

To ease this I suggest
Code:
;Stops mIRC from attempting to parse the line
on ^*:PARSER:[matchtext]:{
  haltdef
}

; Changes the line mIRC and subsquent PARSER events would
; parse from the original to "newline"
on *:PARSER:[matchtext]:{
  parse newline
}
PARSER events from multiple scripts will be passed the line after alterations from previous scripts. That is to say, the first scripts in the script-order get the rawline first, can alter the line, and the altered line will get passed to the subsequent PARSER events

-- EDIT --

After thinking about this some more, instead or requiring a new event, a single command to activate mIRC's built in parser/event-handling would probably be much easier to code, and allow the scripter MUCH more flexibility:
Code:
var %t = :Nick!nick@host PRIVMSG #chan :message
/parse %t

Last edited by FroggieDaFrog; 15/05/15 07:26 AM.

I am SReject
My Stuff
Joined: Apr 2010
Posts: 969
F
Hoopy frood
OP Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
Since I can't edit my original post, I'm posting this to possibly better explain what's lacking in mIRC and the feature itself.

What's Lacking

As stated previously with the rise of CAP mIRC does not have a graceful way for scripts to handle messages that deviate from the IRC protocol. This can be a very large limiting factor for mIRC connecting to servers that are branching out to become multi-purpose. Not only do these modules add custom event messages if the client enables the capability but they may also alter otherwise parsable event messages in such ways that mIRC is unable to understand them.

This is not a twitch-specific feature request. I am on 3 different networks that have custom capabilities that alter, otherwise parsable, user messages when enabled. For the tech-inept it boils down to them hoping the home-brewed obscure cap module their server uses gets native support or do without. For those with enough know-how spend hours writing a local-proxy to trim off an invalidating prefix.

If it was just about displaying a custom event message, it could be left to using the RAW event but these capabilities alter JOIN, PART, PRIVMSG, NOTICE etc events for which mirc and scripts depend on. There's not, currently, a way for mIRC/mSL to handle these types of messages in such a way to allow for mIRC to maintain a connection's state. For example, a script is able to handle echoing a 'join' message to the correct channel from the RAW event, but there's no way to add said user to the nicklist, update the IAL, or alter $nick().idle.


The suggestion
I suggest a the addition of a /parse command that can only be used from within the RAW event. This command would pass a string to mIRC's internal server-message event handling as though the string was just received from the IRC server. Using /halt from within a RAW event that makes use of /parse would not only stop the display but stop further handling of the original message:
Code:
/parse <text>
    <text>: Text to be handled as server-message event



Example
Code:
; assuming $rawmsg is "@stuff :Nick!ident@host PIRVMSG #chan :msg"
raw *:*:{
  if ($regex($rawmsg, /^@(\S+) (:.+)$/)) {

    /* do stuff with $regml(1) */

    ; have mIRC handle the rest of the message
    parse $regml(2)
    halt
  }
}


Last edited by FroggieDaFrog; 24/05/15 11:04 PM.

I am SReject
My Stuff
Joined: May 2015
Posts: 133
K
Vogon poet
Offline
Vogon poet
K
Joined: May 2015
Posts: 133
I would like to see this implemented as well.


twitter @keyeslol
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
Yeah its a good idea, +1


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Dec 2002
Posts: 5,408
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,408
I assume you are referring to the IRCv3 message tags feature? I have added support for this to the next version. mIRC will automatically remove message tags (that start with the @ prefix) from all incoming server messages and place them in a $msgtags identifier per event for use by scripts.

That said, it would not be possible to make a /parse command work in specific events as, even with ^ events, a lot of pre-processing and internal state updates can take place based on the incoming line before the ^ event is called. The only place where this could work is in the alias that /debug calls, which takes place before a server message is parsed in any way.

However, while it would be possible to add support for a /parse command to the debug event to allow a script to modify incoming server messages, this would very likely result in unexpected side-effects as mIRC maintains a large number of internal states for many events. A script that changes/halts incoming lines that mIRC is expecting could cause subtle errors in features without realizing it.

Joined: Apr 2014
Posts: 33
B
Ameglian cow
Offline
Ameglian cow
B
Joined: Apr 2014
Posts: 33
Any eta on this release Khalid?

Joined: Apr 2010
Posts: 969
F
Hoopy frood
OP Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
Originally Posted By: Khaled
However, while it would be possible to add support for a /parse command to the debug event to allow a script to modify incoming server messages, this would very likely result in unexpected side-effects as mIRC maintains a large number of internal states for many events. A script that changes/halts incoming lines that mIRC is expecting could cause subtle errors in features without realizing it.
But isn't that the root of why this feature is requested/required. mIRC is unable to handle the processing of these obscure CAP modules as-is resulting in its internal state already having 'subtle errors' (via omission) in it.

Furthermore, wouldn't it make more sense to have a way for scripters to manage these CAP modules via the built in scripting language than implement each module as it gains popularity, leaving those that do not left 'in the dark' as far as being able to be handled?

I'd also like to point out that XChat, HexChat, EggDrop and many other clients that have a scripting environment already support server-message injection from scripts/modules.

Last edited by FroggieDaFrog; 23/06/15 02:27 AM.

I am SReject
My Stuff
Joined: Dec 2002
Posts: 5,408
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,408
That is a normal part of client development though. There are many server features that mIRC has added support for over the years without which there would be issues. If a server adds an important feature, like IRCv3 message tags, it should be implemented in the client. The reason for my post was to confirm that issue referred to was IRCv3 message tags and that support for this had been added to the next version. As for /parse, this is not something I want to add support for due to the number of issues it would cause.

Joined: Jul 2006
Posts: 4,141
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,141
Well, although I don't like this suggestion as it is, there is a valid point here, having a way to handle CAP modules currently unsupported by mIRC would be nice.
Do you think it's possible to make something like this in a different, less direct, way?
I was more or less saying to froggi that, to be able to make a way to support these CAP modules (which break the IRC protocol) with scripting, mIRC itself would first have to support these newly-formatted messages anyway, meaning you would probably go ahead and support the module anyway.
Do you plan on implementing all the CAP modules in the future?


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
Originally Posted By: FroggieDaFrog
Furthermore, wouldn't it make more sense to have a way for scripters to manage these CAP modules via the built in scripting language than implement each module as it gains popularity, leaving those that do not left 'in the dark' as far as being able to be handled?


RAW has never triggered on server message that trigger existing events (i.e. ON NICK, ON MSG, ON ACTION, etc). While even I personally would like RAW to handle all events even if they already trigger existing events, it's not going to happen.


Last edited by MeStinkBAD; 15/07/15 12:54 AM.

Beware of MeStinkBAD! He knows more than he actually does!
Joined: Apr 2010
Posts: 969
F
Hoopy frood
OP Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
First, "RAW" does trigger for all events, not just numerics. This issue that gave rise to this feature request is that with CAP gaining popularity scripters have(had; see the second part of this post) no way to make use of these CAP modules without breaking mIRC's internal event handling.
Code:
raw *:*:{
  echo -s $rawmsg
}


Second, the request has been implemented in the closed beta for testing:
Quote:
29.Added on PARSELINE event, triggers before incoming/outgoing server
lines are received/sent and allows a script to modify them.

on *:PARSELINE:<in|out|*>:matchtext:echo $parsetype $parseline

The line can be modified using the following command:

/parseline -iotbqpnuN [text|&binvar]

-i or -o = required to specify an in/out line.

-t or -b = required to specify text or &binvar.

-q = add a new line to the end of the in/out queue. It can be used
inside and outside the PARSELINE event. New lines are processed
after the script/event exits.

-p = use with -q to indicate that the new line should trigger the
PARSELINE event.

-n = add a CRLF to the end of the line if it does not have one.

-uN = where N is 0 or 1 and either disables or enables UTF-8
encoding/decoding for the line.

Notes:

1) A script must check $parseutf to know whether mIRC will be UTF-8
encoding/decoding a line. For outgoing lines, if $parseutf is $true,
after the PARSELINE event, mIRC will UTF-8 encode the line before
sending it to the server. You can prevent this by using -u0. For
incoming lines, if $parseutf is $true, after the PARSELINE event,
mIRC will UTF-8 decode the line before processing it. You can prevent
this by using -u0.

2) mIRC maintains internal states based on incoming and outgoing
lines. If lines are modified, mIRC may not work correctly. This
feature should only be used, for example, to support features
and/or protocols that mIRC does not already support, not to modify
standard lines.

Last edited by FroggieDaFrog; 15/07/15 06:30 AM.

I am SReject
My Stuff
Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
Originally Posted By: FroggieDaFrog
First, "RAW" does trigger for all events, not just numerics. This issue that gave rise to this feature request is that with CAP gaining popularity scripters have(had; see the second part of this post) no way to make use of these CAP modules without breaking mIRC's internal event handling.


I'm totally unfamilar with these new CAP modules. I haven't connected to a network that uses them. Thus I know nothing about them. I use my own event redirection so i'm not sure it would impact me or not. As of the most recent public release, "RAW *:*" will not trigger on events such as NOTICE, PUBMSG, PRIVMSG, JOIN, PART, etc etc...

Originally Posted By: FroggieDaFrog
Second, the request has been implemented in the closed beta for testing:


I don't HAVE the closed beta version because of it being a CLOSED beta! I'm glad the feature has been added to the closed the beta. But for everyone else we'll have to wait till the public release.


Last edited by MeStinkBAD; 17/07/15 01:45 PM.

Beware of MeStinkBAD! He knows more than he actually does!

Link Copied to Clipboard