Well.. As you have been saying nick, you don't really know how to handle giving the user the color and other info in the line itself. So here is my proposed solution (or at least more or less how I would code it if there was a way to get the 'raw' ansi line. ;)
The point after all is not to 'hand' them the colors, etc. Just make them accessable in a way they can identify and change or skip over them. ;) As for MXP/Pueblo, that is already plain text and unsupported ansi codes can just be stripped out in the Recode_Ansi part of the process or ignored completely. The point is that it is not impossible to code a simple way to handle the ansi, even if all we had was the raw line. It would be 'slightly' more complex in vbscript since the case statement for the attributes would have to use if-then, due to being unable to test a 'range' of values in a case statement, but I seem to remember that C++ can. The only real issue imho is if you want to provide this level of control to users and without it, you could add item replacement to triggers, but the result would be far less versitile. Also, as I said befoer, in some cases like I mentioned with muds that begin using MXP, but refuse to follow the specs you can't 'fix' it from the client end.
Well you could.. But that would require turning mxp off, and processing the tags yourself, which if any ansi was used would still fail because you can't get style info on omitted lines. You would probably also have to process triggers, etc. through the script, since there is a bit difference between 'You see a red ball.' and 'You see a <color fore="red">red ball</c>.' Changing some things Pre-process is imho the only real option.
The no-style changes available for omitted lines thing still needs to be addressed to though.. Just about everyone I have talked to about it has aggreed that it severely limits the use of the option and what they would have considered using it for. Some of those issues would be addressed fairly easilly with the pre-process feature, but not necessarilly all of them.
Client pre-processing.
|
\
function Parse_Ansi (Ansi_Line)
dim Output, codes
dim Valid = "0123456789;,"
for count = 1 to len(Ansi_Line)
if mid$(Ansi_Line,count,1) = chr(27) then
Output = Output & "<Ansi-"
codes = ""
for acount = count + 2 to len(Ansi_Line)
temp = mid$(Ansi_Line,acount,1)
if instr(Valid,temp) then
codes = codes & mid$(Ansi_Line,acount,1)
else
..Check type and encode codes..
select case temp
case "m"
dim codelist
codelist = split(codes,";")
value = 0
Output = Output & "Attr("
for ccount = 0 to ubound(codelist)
select case codelist(ccount)
case 30-37,39,40-47,49
Output = Output & codelist(ccount) & ";"
case 1-28
value = value + 2^codelist(ccount)
end select
next
Output = Output & "#" & hex(value) & ")"
case else
Output = Output & "NS"
end select
Output = Output + ">"
count = acount
exit for
end if
next
else
Output = Output + mid$(Ansi_Line,count,1)
end if
next
end function
|
Ex: <Ansi-Attr(34;40;#1000048)> = Italic, Fast blink and underline off.
|
V
BStr OnPluginLineRecievedEx (BStr aline)
Whatever the user wants to do with it..
OnPluginLineRecievedEx = aline
end function
|
|
V
function Recode_Ansi (aline)
Reverse the process on returned line..
end function
|
/
Client final processing.The point after all is not to 'hand' them the colors, etc. Just make them accessable in a way they can identify and change or skip over them. ;) As for MXP/Pueblo, that is already plain text and unsupported ansi codes can just be stripped out in the Recode_Ansi part of the process or ignored completely. The point is that it is not impossible to code a simple way to handle the ansi, even if all we had was the raw line. It would be 'slightly' more complex in vbscript since the case statement for the attributes would have to use if-then, due to being unable to test a 'range' of values in a case statement, but I seem to remember that C++ can. The only real issue imho is if you want to provide this level of control to users and without it, you could add item replacement to triggers, but the result would be far less versitile. Also, as I said befoer, in some cases like I mentioned with muds that begin using MXP, but refuse to follow the specs you can't 'fix' it from the client end.
Well you could.. But that would require turning mxp off, and processing the tags yourself, which if any ansi was used would still fail because you can't get style info on omitted lines. You would probably also have to process triggers, etc. through the script, since there is a bit difference between 'You see a red ball.' and 'You see a <color fore="red">red ball</c>.' Changing some things Pre-process is imho the only real option.
The no-style changes available for omitted lines thing still needs to be addressed to though.. Just about everyone I have talked to about it has aggreed that it severely limits the use of the option and what they would have considered using it for. Some of those issues would be addressed fairly easilly with the pre-process feature, but not necessarilly all of them.