I posted something about this last year, and never got a response. Problem seemed to fix itself for awhile, then returned. (Either that, or players just stopped reporting it for awhile).
After installing AFKMud's color code, for some reason at occasional intervals, players' prompts will contain strange information instead of color codes always at the same point in the prompt, such as
Probably asking for trouble, but could you post the entire content of your display_prompt function? What little you've given us so far isn't enough to go on except to identify that your prompt code is not stock Smaug.
Not all that much has been changed from stock, aside from the deletion of a few cases, and cases 'h', 'm', and 'A'. The error code ALWAYS happens either before, in place of, or after the first time %h or %m is called. There is never an error elsewhere in the string, or if %A is called first.
There is something rather strange about this prompt code. First it checks that it has a '%' symbol, and then later on backs up and re-checks again. I refer to these lines:
switch(*(prompt-1))
{
default:
bug( "Display_prompt: bad command char '%c'.", *(prompt-1) );
break;
case '%':
This is done after it already knows that *(prompt-1) is a %.
Anyway, you are having a problem with %h and %m, both of which put ANSI codes into the prompt string. This is then passed to the colour code, which re-evaluates the string and puts more ANSI codes in it. It might be safer to put in the colour code (like &C) rather than the ANSI codes, although you say you have done that.
You haven't posted the colour code, but is it possible that it is treating the % symbol differently? After all, the %m is echoing the mana as a percent (eg. 40%) and that % might be causing the colour code to react badly. I can't say for sure without seeing the colour code.
The color code is an almost completely unmodified copy of Samson's code included in SmaugFUSS. Contains no references to % that I can see.
You're right about the extra case '%'.
It's quite weird - its only purpose seems to add a *pbuf = '\0'.
What does the line
pstat = 0x80000000;
do?
Note: I think you're on the right track about the % affecting the code badly. It only happens on the first value called with %% in the string.
Note 2: Out of curiosity, I removed the int percent check from the prompt value. It seems to have decreased the frequency of the prompt errors, but it still occurs...
Ah, Thanks.
I just got some information from a couple players.
The color bug most often occurs in the prompt, but a couple have received them outside prompt, where there is no % sign, even at the start of a line.
ch_printf( ch, "&gYou %s run along a treadmill at %d mph.\n\r", buf2, number_fuzzy(get_curr_con(ch) + 2));
became
[0;N jeou shakily run along a treadmill at 7 mph.
Perhaps it's not liking \033 calling ANSI instead of \x1b?
I am incredibly confused at this point. I ran a compare of my color.c and .h with the distro copy from AFKmud's homepage, and could find no significant differences. I suppose tomorrow I'll give replacing the files a try, but I doubt it will help.
Screwed up strings like that are indicators of over/underruns on the buffers. There really isn't any other way for "you" to turn into "jeou". Valgrind will catch overwrites, but I'm not sure if it knows how to catch "underwrites" where you access something before string[0] in a char. This kind of thing can be incredibly difficult to track down too. But I can tell you with a reasonable degree of certainty that the color code is not to blame for the problem since it's being used widely in many muds. It may simply have exposed the problem for you.
The only problem Valgrind seems to identify is this:
==17739== Use of uninitialised value of size 4
==17739== at 0x1B9DB3F5: mempcpy (in /lib/libc-2.3.4.so)
==17739== by 0x1B9D1E11: _IO_default_xsputn (in /lib/libc-2.3.4.so)
==17739== by 0x1B9AF874: vfprintf (in /lib/libc-2.3.4.so)
==17739== by 0x1B9CD85F: vsnprintf (in /lib/libc-2.3.4.so)
==17739== by 0x80F7B7E: pager_printf (color.c:1354)
==17739== by 0x8174F41: do_score (player.c:183)
==17739== by 0x8137E7A: interpret (interp.c:562)
==17739== by 0x80F8A71: game_loop (comm.c:646)
==17739== by 0x80F8046: main (comm.c:302)
This message appears a few times, but the bold line only appears shortly before someone gets a color error in their prompt.
The line in question in player.c is
pager_printf(ch, "&GPlayed&g: &w%d hours &GSaved&g: &w%s\r",
(get_age(ch) - 17) * 2), (ch->save_time ? ctime(&(ch->save_time)) : "no save this session\n");
Maybe those strange pbuf[i-1] lines in comm.c should be investigated, because those are likely suspects to do something before the beginning of the buffer, especially since your color codes are occuring at the very beginning of the line.
Can't be of much help though without all the code in front of me. What you can try doing is to contrive a situation in which the MUD prints out the score line, and then directly displays the prompt, and see what happens.
But the fact that 'you' is turning into 'jeou' is sign that something very unwanted is occurring.
Hm. Just thought I'd update: The problem appears to be resolved.
No idea what exactly was causing it, or how I fixed it, though.
While rewriting several functions for greater efficiency, the error just dissapeared...
Well, gratz on fixing it I guess. But that is somewhat irritating to accidentally fix a bug and not know why. That's how I felt after awhile realzing we never see the infamous room_is_dark bug. :)