mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Mar 2013
Posts: 3
Andrio Offline OP
Self-satisified door
OP Offline
Self-satisified door
Joined: Mar 2013
Posts: 3
There doesn't seem to be any way for a script using the ON CHAT event to differentiate between normal messages and ACTION messages.

The specific problem I'm having is with a script that was written for mIRC 6.16. It requires '/me attacks' commands in DCC CHAT. This is the event that is used:
Code:
ON 2:Chat:ACTION attacks*:{

However, I'm running the script on version 7.29. And it doesn't work. I did some investigation, and I found that this was being returned in $1- in the CHAT event:
Code:
attacks Zombie

Whereas in version 6.16 I got this:
Code:
ACTION attacks Zombie

Which means the script isn't forwards compatible, and there's no reliable way to differentiate between normal messages and actions in DCC sessions.


As long as we stand, we will fight!
Joined: Oct 2012
Posts: 164
D
Vogon poet
Offline
Vogon poet
D
Joined: Oct 2012
Posts: 164
Indeed. Add that $rawmsg is broken for chat events in that it also strips ACTION from the returned line (since v6.30) leaving no way to differentiate between chat msg and action.

Joined: Aug 2006
Posts: 167
P
Vogon poet
Offline
Vogon poet
P
Joined: Aug 2006
Posts: 167
There is a way. Using the ^ prefix makes $rawmsg provide enough information to discern between TEXT and ACTION.

Here's an example of code that intercepts every incoming DCC CHAT line (whether it is TEXT or ACTION), and prints it to the correct DCC CHAT window exactly as mIRC would if the event didn't exist. (In other words, the script will produce output identical to mIRC's simply to show that what you want is possible.)

Code:
alias -l getwid {
  set -eu1 %getwid $wid
  return $1-
}

on ^*:CHAT:$($getwid(*)):{
  var %w = %getwid
  unset %getwid
  if (!$halted) {
    if ($gettok($rawmsg,1,32) == $+($chr(1),ACTION)) var %a = $true, %s = $left($gettok($rawmsg,2-,32),-1)
    else var %s = $1-
    if ($cnick($nick) != 0) && ($cnick($nick).method < 2) var %n = $+($chr(3),$base($cnick($nick).color,10,10,2),$nick,$chr(15))
    else var %n = $nick
    echo -ibcflmrt $iif(%a,action,normal) $+(@,%w) $iif(%a,%n,$+(<,%n,>)) %s
    haltdef
  }
}

The extra alias is necessary to overcome a $wid bug. ($wid in ON CHAT always reports only the window ID of the first DCC CHAT window opened to $nick. So the alias allows the event to write text to the correct DCC CHAT window, even when you have more than one DCC CHAT window open to $nick.) There is also extra code to reproduce mIRC's user-defined nick colorization.

Joined: Dec 2002
Posts: 5,431
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,431
Thanks for the bug report. As mentioned in the above posts, this was due to a change in mIRC many versions ago. Unfortunately, it is difficult to undo changes like this as scripts written since then have adapted to the change.

I could change $rawmsg so that it contains the full line, which it should in this case. Although, again, any scripts that currently use $rawmsg in on CHAT, will need to be updated to remove the "ACTION" and "SOUND" (which is the only other CTCP message that behaves the same way - no other CTCP messages are filtered in chat messages) prefixes from the message.

Joined: Dec 2002
Posts: 5,431
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,431
Quote:
The extra alias is necessary to overcome a $wid bug. ($wid in ON CHAT always reports only the window ID of the first DCC CHAT window opened to $nick. So the alias allows the event to write text to the correct DCC CHAT window, even when you have more than one DCC CHAT window open to $nick.)

This is not so much a bug in $wid as it is a long-standing design issue that affects all commands and identifiers in remote events.

All remote events run with the status window as the active window eg. if you use /echo in the event, it will display in the status window associated with that event. Only a small number of remote events, such as on INPUT, use the window that triggered the event as the active window.

I would love to change this so that all events are triggered using their associated window as the active window. However this would cause all existing scripts that expect the active window to be the status window to work differently ie. all commands and identifiers would now return results based on the chat window and not the status window. This would very likely introduce all kinds of subtle bugs and require many scripts to be updated.


Link Copied to Clipboard