So, after getting MXP up and working with the most recent version of SmaugFUSS, I then looked into getting HTML color support added into the code. However, I've run into a bit of a snag. First, I'll explain what I'm doing to implement it. With MXP, the <FONT> tag is already defined, so I don't need to go and tell the Client how to interpret it anywhere.

color.c : colorcode()

case 'y':  // Dark Yellow
	if( mxp )
	{
		mudstrlcpy( dst, MXPTAG("FONT COLOR=\"#D91313\"", dstlen );
		break ;
	}
	if( ansi )
	{	mudstrlcpy( dst, ANSI_ORANGE, dstlen );	}
	break;

case 'x':  // Reset
case 'X':
	if( mxp )
	{	
		mudstrlcpy( dst, MXPTAG("/FONT", dstlen );
		break ;
	}
	if( ansi )
	{	mudstrlcpy( dst, ANSI_RESET, dstlen );	}
	break;

As you might notice I did change around what certain color codes do, this is just for my own -- and my staff's -- preference, so no worry for that. The MXPTAGS() come out to <FONT COLOR="#D91313"> and </FONT> respectively, up to 23 characters long (less than 23 means that the Font Tag isn't properly closed, so output becomes a bit wonky and MUSHClient logs an MXP error.)

So, because of the increase in possible length, we have to change what dstlen is passed into colorcode() from colorize(), like so:

color.c : colorize()

if( d->mxp )
{	ln = colorcode( colstr, colbuf, d, 23, NULL );	}
else
{	ln = colorcode( colstr, colbuf, d, 20, NULL );	}

(We have to make a similar change in mapper.c, but I'll leave that out since it's just the same code, and it's the above code that is most definately giving me a problem ... I assume that if I tested it I'd get the same issues, given what they are.)

However, when I test to see if the code works by logging onto the MUD and doing say &ytest&x I get a Segementation Fault and Core Dumped shennanigans. A bit of bug-lines told me that I do get past that initial &y color code without any problems, but crashes before it attempts to redo the Reset Code &x.

I'm at a bit of a loss as to what's causing this. Because of where it is I presume that it's somewhere in here, but I'm not sure because colorize() is used to incredibly often that attempting to add a bug line to it just causes the MUD to crash when I attempt to log on.

if( ln > 0 )
{
	mudstrlcat( result, colbuf, MSL );
	prevstr = colstr + ln;
} else {
	prevstr = colstr + 1;
}

After some attempts to debug I noticed that the crash seemed to be happening whenever I attempted to reference prevstr, including asking if prevstr[0] == '\0' (to see if it was somehow becoming a NULL String), but that still caused a crash at that line. So I'm really at a loss as to what's going wrong; I know that ln is 2, which seems like the correct thing for it to be, still, since the code still is just wanting to skip over &y. It doesn't make too much sense for it to be dying off of that, though. I'll continue to try to find the bug after posting this, but if anybody knows what's up I'd love to hear it.

Edit: Mud was crashing when I log in because, I think, I was logging on as an admin and the buffer was overflowing with log + bug lines. Testing as a mortal works much better.

At the beginning of the main while loop in colorize() why is hH present? I get &^{, but not the last two.

while( (( colstr = strpbrk( prevstr, "&^}hH" ) ) != NULL) )

Edit: Nevermind, I'm blind: the h and H are there to match http links.

A bit more testing with bug lines shows that my initial guess wasn't correct: it's not prevstr that is causing the crash. Rather, it's colstr. I added Debug lines to show the steps that were going on here, and I discovered that src in colorcode isn't transferring back to colstr in colorize correctly when I add the MXPTAG. At the end of colorcode a bug line of

bug( "Colstr: %s" src )

shows that src has the proper information stored, but when I go to colorize and use a bug line checking the value of colstr right after the call of colorcode I get a segmentation fault. I don't have this problem if I'm only using ANSI colors. So I've got absolutely no idea what's causing this, to be frank, but I suspect it's a memory issue -- memory management is one of my admittedly inexperienced areas, but there we have the problem specified. Anybody got tips for where I should go from here to solve this bug?

Pop back just a little bit before where you're editing in color.c:

      char colbuf[20];

The declaration for colbuf will need to be raised. I'd suggest going with 25.

:: Insert Facepalm Here ::

Thanks very much, I never know whether to be upset that I missed something so easy, or happy that I didn't screw something big up. Guess that's why the internet was invented.