Color codes and functions

Login to reply  Page: « < 1 of 1 > »
25 Jan 2010 - 01:552258
Color codes and functions
Ok so i thought i posted this but i cant find it on the forums now.

Ok so let’s take the example:
send_to_char(i->character, "%s[ %s ]%s\r\n", CCGRN(i->character, C_NRM), output, CCNRM(i->character, C_NRM));

So why not express this as:
send_to_char(i->character, "@g[ %s ]@n\r\n",output);

We do have @ codes so we should convert ourselves to use them. Doesn’t make sense to have them and not use them.

I tell you I like looking at that second line better than the first.

I did some searches for all the color functions and excluded all the headers defining the color functions

It would not take much to convert the whole code base over to using the @ codes rather than color functions

Just my $0.02


CCNRM( 149
CCBLK( 0
CCRED( 10
CCGRN( 18
CCYEL( 54
CCBLU( 0
CCMAG( 0
CCCYN( 79
CCWHT( 1

CBRED( 24
CBGRN( 16
CBYEL( 485
CBBLU( 20
CBMAG( 0
CBCYN( 0
CBWHT( 6
CBBLK( 0

CCFRED( 0
CCFGRN( 0
CCFYEL( 0
CCFBLU( 0
CCFMAG( 0
CCFCYN( 0
CCFWHT( 0

CBFRED( 0
CBFGRN( 0
CBFYEL( 0
CBFBLU( 0
CBFMAG( 0
CBFCYN( 0
CBFWHT( 0

CBKRED( 0
CBKGRN( 0
CBKYEL( 0
CBKBLU( 0
CBKMAG( 0
CBKCYN( 0
CBKWHT( 0
CBKBLK( 0



Last edited by tap3w0rm (25 Jan 2010 - 02:03)
25 Jan 2010 - 21:382263
Color codes and functions
Quote tap3w0rm:
send_to_char(i->character, "%s[ %s ]%s\r\n", CCGRN(i->character, C_NRM), output, CCNRM(i->character, C_NRM));

So why not express this as:
send_to_char(i->character, "@g[ %s ]@n\r\n",output);

Because they don't mean the same thing. CCGRN(i->character, C_NRM) means
(!IS_NPC(ch) ? (PRF_FLAGGED((ch), PRF_COLOR_1) ? 1 : 0) +  (PRF_FLAGGED((ch), PRF_COLOR_2) ? 2 : 0) : 0)  >= 2 ?  "\x1B[0;32m" : ""
while @g means
(!IS_NPC(ch) ? (PRF_FLAGGED((ch), PRF_COLOR_1) || PRF_FLAGGED((ch), PRF_COLOR_2) ? 1 : 0) : 0) ?  "\x1B[0;32m" : "";

The difference is not obvious, but @g will be green if you have color level set to "sparse" , where the CC macro won't kick in until you set it to either "normal" or "complete". @-tags simply check if you are using colors. CC macros are much more finely tuned.


__________________
You know who I am.
26 Jan 2010 - 02:412265
Codes
Maybe we should make fine tunable @ codes. Imagine being able to color code an item and some descriptions with some @ codes that conform to the sparse tags.

is this a horable idea?


09 Jun 2010 - 10:532691
Here's a fairly simple enhancement to allow this:

Add screen.h to comm.c and replace proc_colours:

 static size_t proc_colors(char *txt, size_t maxlen, int char_colour_pref)
{
  char *d, *s, *c, *p;
  int i;
  int colour_level = C_NRM;

  if (!txt || !strchr(txt, '@')) /* skip out if no color codes     */
    return strlen(txt);

  s = txt;
  CREATE(d, char, maxlen);
  p = d;

  for( ; *s && ((size_t)(d-p) < maxlen); ) {
    /* no color code - just copy */
    if (*s != '@') {
      *d++ = *s++;
      continue;
    }

    /* if we get here we have a color code */
    s++; /* s now points to the code */

    switch(*s)
    {
    case 0:     *d++ = '@'; continue;        /* string was terminated with @; make sure s stays at the 0 */
    case '@':   *d++ = '@'; break;           /* Always a @ */
    case '+':   colour_level = C_SPR; break; /* high colour - show even if SPARSE */
    case '=':   colour_level = C_NRM; break; /* normal colour */
    case '-':   colour_level = C_CMP; break; /* low colour - show only if COMPLETE */
    default:
      if (char_colour_pref >= colour_level) { /* only copy the new code if above the level */
        for (i = 0; CCODE[i] != '!'; i++) { /* do we find it ? */
          if ((*s) == CCODE[i]) {           /* if so :*/
            /* c now points to the first char in color code*/
            for(c = ANSI[i] ; *c && ((size_t)(d-p) < maxlen); )
               *d++ = *c++;
            break;
          }
        }
      }
      break;
    }
    /* Whatever the code was (even invalid), skip it */
    s++;

  } /* for loop */

  /* make sure txt is NULL - terminated */
  d = 0;
  strncpy(txt, p, maxlen-1);

  free(p);

  return strlen(txt);
}

and in vwrite_to_output, remove the if(t->character) check and insert this:


   {
    // Inherit colour settings if switched
    struct char_data *dest = t->original ? t->original : t->character;
    int colour_level = dest ? _clrlevel(dest) : 0;
    wantsize = size = proc_colors(txt, sizeof(txt), colour_level);
  }

This adds three new @ codes: @+, @= and @-, meaning 'sparse' 'normal' and 'complete' respectively. The setting applies from that point forward. In addition, @-code colours preferences are now taken from the parent character if switched.

A couple of design decisions here are up for grabs:
- should -, =, + correspond to the amount of colour displayed (+ means more colour visible, so SPR) or the user's settings (+ means more colour wanted, so CMP). Went with the former.
- What's the default? To match the existing behaviour it would want to be sparse. Went with NRM, the wiser design decision going forwards I reckon.
- push and pop might possibly be useful?

Possible that this also fixes a bug with the raw colour codes appearing if t->character was 0, but that's a rather unlikely situation, so probably not important.

Feel free to pull this into TBA if required. (I'm in the process of merging a very old MUD codebase with TBA, I've plenty of bug reports and small and large suggestions for enhancements coming at some point).



Last edited by Dio (09 Jun 2010 - 10:55)
09 Jun 2010 - 20:332695
Very nice code. I like how you cleaned up the old messy proc_colors() function.

Kudos.


__________________
You know who I am.
10 Jun 2010 - 08:082697
Cheers. I'll start up another thread about the things I'm finding in the merge...


Login to reply  Page: « < 1 of 1 > »