06 Feb, 2007, Guest wrote in the 1st comment:
Votes: 0
http://www.mudbytes.net/index.php?a=past...

I have that function as part of AFKMud 2.0. It has a slight bug, which probably wasn't readily noticed. But when the room descriptions are split up based on how large the mini-map segment is. But when this splitting is done, the color codes don't carry over to the next line the way they should.

So I was hoping someone better with strings than I am could help with this. Valid color tags in AFKMud are &, {, and }. Ideally the last color tag change in a line should carry over as the first color tag on the next line's text.

Sample output of a room description with the mini-map:
+———–+ A thunderous roar echoes through the sky….. and suddenly 
| | you are transported into this tiny room! An odd blue mist
| | begins to slowly fill the room, clouding your vision and giving
| | you a very strange sensation…… After a few minutes, the
| | mist clears away and suddenly you notice your body has been
| @ | altered! You are no longer in a physical form! From somewhere
| | high overhead a deep booming voice shouts: "Welcome stranger!
| | Examine the paintings before you and choose your new race
| | by saying its name out loud. For example, if you wish to become
| | a High Elf, you would type: say high-elf to do so. Refer to
+———–+ the website for further information on races and classes
located at http://www.alsherok.net&c. You may also get a brief overview of
which classes are allowed by examining the scrolls here."


This description begins life as cyan, tag &c, but that only goes out to the end of the first line at which point everything reverts back to default.
06 Feb, 2007, Scandum wrote in the 2nd comment:
Votes: 0
The main difference I see is that the last color code of the map ends with &w in the first line, and with &D on all following lines. So it could be a bug in your print fuction's color parser.

Assuming &D stands for Default I'd like to remark that it's preferable to use \033The main difference I see is that the last color code of the map ends with &w in the first line, and with &D on all following lines. So it could be a bug in your print fuction's color parser.

Assuming &D stands for Default I'd like to remark that it's preferable to use \033[0;37m above \033[0m because the default color can be different for each terminal. Some muds look pretty ugly on OS X's terminal, which defaults to blue.
06 Feb, 2007, Davion wrote in the 3rd comment:
Votes: 0
Here we go!
Add this function wherever
char whatColor(char *str, char *pos)
{ static char col;
col = 'x';
while(str != pos)
{ if(*str == '&')
{ ++str;
if(!str) break;
col = *str;
}
++str;
}
return col;
}


Then, in the show_mapper function where it appends the line, I changed it too->
/* Add the text, if necessary */
if( !alldesc )
{
pos = get_line( p, 63 );
char col[3], c;
c = (char)whatColor(text, p);
if(c == 'x')
sprintf(col, "%s", ch->color_str(AT_RMDESC) );
else
sprintf(col, "&%c", c);

if( pos > 0 )
{
mudstrlcat( buf, col, MSL*2 );
strncat( buf, p, pos );
p += pos;
}
else
{
mudstrlcat( buf, col, MSL*2 );
mudstrlcat( buf, p, MSL*2 );
alldesc = true;
}
}


And it worked on all my tests.
11 Feb, 2007, Guest wrote in the 4th comment:
Votes: 0
Finally had a chance to put the code in and test it. The results didn't work. For room descriptions where there were color tags used, it seem to work fine. On rooms where none have been used, only the 1st line of the description works. The rest are turned green and have the first letter of each line cut off.
09 May, 2007, Mithros wrote in the 5th comment:
Votes: 0
You've probably long since fixed this problem, but you can try viewing the same description in a few different clients, a lot of the color codes passing from line to line problems are actually the client mucking up and not the server.
Random Picks
0.0/5