[Scrymud] CVS Commit Info

[Edward Roper]

Okay I think this is the design I'm most comfortable with, as always feel free
to comment.

1] I'm going to rework show() to take a vararg which will default to the
players "default color". Other arg options (via. #defines) will let show()
handle moblist's pc-list's (which isn't differentiated yet but I'd like to see
the ability to set pc's to a different color than mobs in a "look" listing),
battle color, etc. This will also allow the anti-bleed code to set the color
back appropriately to say a users defined "say" color when they person changed
the color in the middle, or when an item uses colors and reverts back using ^0
or &0.

2] Color strings in the config file will be altered to accept the mudwide
color strings. Existing ansi strings in place in current Pfiles will continue
to work automagically and will be updated automatically at the next use of the
"color" command.

Err it's late... I hope all that made sense. Oh yeah and show() will now call
isUsingColor() so that the bazillion invocations of it throughout the rest of
the code don't have to anymore.

I'm assuming that all this processing in show() will result in a minor
speed-hit, but I'm not expecting it to be noticeable. Hey this also means I
can fix the double << annoyance ;)

--Khaav

On Thu, Jan 03, 2002 at 06:30:03PM -0800, Ben Greear wrote:
> So now I'm facing a design decision.
> 
> 1] Make all yell, shout, say, etc. color changes happen at the beginning of
>    every show()'ed string.
> 2] Do the above but instead of embedding raw ansi, have them use the new color
>    code scheme in addition. I.E. to embed blue instead of passing show() a
>    long escape sequence embed ^b for dark blue or ^B for light blue. The other
>    advantage to this is that now instead of adding a million more keywords
>    that the color command can accept, I just allow it to take as a parameter
>    the MUD-WIDE ^ color codes for foreground and & color codes for background.