There always seems to be lots of confusion around when damage reduction drops damage to zero and it shows up as "misses". I've changed the way it works now, so that if the original damage is greater than zero, and damage reduction reduces it to zero, it will show up as "barely scratches" now instead of misses.

Coming soon to a Crash/Reboot near you.

I like the idea but I would prefer a single-worded verb.

Reasons why "barely scratches" isn't the best for this:
1) not very accurate description of zero damage. "scratches" assumes some damage even it's just "barely". Strictly speaking, for zero damage "misses" was better.
2) It is not conforming with the single-worded style for nearly all other damage verbs (except the unspeak). I don't think that breaking this trend was necessary as there are other verbs that could describe zero damage better and in a single word.
3) Minor issue: highlights needs an update. They would need an update anyway, but for a single verb it's more regular/easier.

About highlights:
Yes, sure, I'm able to update my highlights (which are open sourced, btw, and other people use them too). I know regex well enough for that (but many don't). But I honestly don't understand this attitude: "we ####ed your highlights? We don't care!". Normally, people use clients to play CF, so why don't "support" players by not breaking their setups while it takes nearly zero efforts on the server side?

My response is bolded, Dwoggurd's text in reference is not.

>Reasons why "barely scratches" isn't the best for this:
>1) not very accurate description of zero damage. "scratches"
>assumes some damage even it's just "barely". Strictly
>speaking, for zero damage "misses" was better.

In this case, the attack does not miss. It hits, but fails to hurt due to the opponent's damage reduction. It does not make sense that a lash "misses" you, yet lags you for two rounds. If you have problem with "barely scratches" in this sense, maybe replace it with "fails to hurt", which is also a slightly shorter expression as well?

>2) It is not conforming with the single-worded style for
>nearly all other damage verbs (except the unspeak). I don't
>think that breaking this trend was necessary as there are
>other verbs that could describe zero damage better and in a
>single word.

Unspeaks doesn't conform to it either. The fact remains that you haven't yet suggested a better single word alternative for "barely scratches". Your suggestion, "touches", was worse than barely scratches.

>3) Minor issue: highlights needs an update. They would need an
>update anyway, but for a single verb it's more
>regular/easier.

If your highlights are that great, they should be implemented in the game. This is why I think Imms shouldn't care about ####ing over your highlights.

>In this case, the attack does not miss. It hits, but fails
>to hurt due to the opponent's damage reduction. It does not
>make sense that a lash "misses" you, yet lags you for two
>rounds. If you have problem with "barely scratches" in this
>sense, maybe replace it with "fails to hurt", which is also a
>slightly shorter expression as well?

Fails to hurt is better at describing zero damage. But it is not necessary better in other aspects. Multi-words and, perhaps, some will think that it sounds "bad" (though I don't think so).

>Unspeaks doesn't conform to it either. The fact remains
>that you haven't yet suggested a better single word
>alternative for "barely scratches". Your suggestion,
>"touches", was worse than barely scratches.

I'm not happy with "unspeaK" too, but it will be too much to ask about changing it as well.
And I would rather prefer to hear suggestions from native speakers as I'm not the best person to pick the right word.

>If your highlights are that great, they should be
>implemented in the game. This is why I think Imms shouldn't
>care about ####ing over your highlights.

I fail to grasp any logic in this sentence.
However, they can't implement my highlights on the server side as they can use only ANSI color codes with 16 predefined colors unless they decide to use a different protocol (like MXP) instead of raw telnet.

>I fail to grasp any logic in this sentence.
>However, they can't implement my highlights on the server side
>as they can use only ANSI color codes with 16 predefined
>colors unless they decide to use a different protocol (like
>MXP) instead of raw telnet.
>

Those 16 colours are enough to make people notice the echo better. The game doesn't need to be a Christmas tree.

He just formats the game pretty much exactly the way the logboard has formatted for a long ass time.

I like it and a lot of other people use it as well. Yeah, he'll have to change it, and yeah the general CF community that doesn't use it now gets different colors for incoming versus outgoing but seriously, don't #### on a guy that's helping others out with his work. Christmas tree because we want something beyond 16 colors?

When did you ever bring ANYTHING useful to the community?

>He just formats the game pretty much exactly the way the
>logboard has formatted for a long ass time.
>
>I like it and a lot of other people use it as well. Yeah,
>he'll have to change it, and yeah the general CF community
>that doesn't use it now gets different colors for incoming
>versus outgoing but seriously, don't #### on a guy that's
>helping others out with his work. Christmas tree because we
>want something beyond 16 colors?

Dwoggurd's logs looked a bit like a Christmas three because they had so many colours. Personally, I don't think it's a good idea to develop the game in terms of accomodating the functioning of third party triggers. Sure, larger colour selection makes it easier to colour echoes, but I think that sufficient highlighting for the MUD's needs can be done with the 16 Ansi colours.

As for Dwoggurd's highlights, I don't consider them crap. However, I've read enough threads and reviews that mention MUD colours to know that highlights like Dwoggurd's aren't something that every player would want to see in a MUD. It's simply too much colour for some people and thus useful as an addon for those who prefer such colouring. I think that such addons should be developed in the terms of the game and not the other way around (I might find some of the m useful, but wouldn't want just to add his whole package to my client as is). Thus, I regard Dwoggurd's request for the game to better accomodate for his triggers as absurd. I simply think that Dwoggurd updating his highlights is the best solution for the highlight problem.

>When did you ever bring ANYTHING useful to the community?

I've done some page updating and forum moderating in Dio's back in the day when I played actively and added my own part to Wiki maps and such things. Don't be a ####.

The dwoggurd script added way to much color for my tastes. I use very minimal coloring, and echoes to highlight important stuff.

Really.
More available colors make it easier to develop coloring that looks much less christmas tree.
Why? Because you have a wide choice of shades and soft colors.
For example, CF now colors received damage in very bright red color. In my highlights I specifically used much less bright color for that (to protect my eyes). With ANSI color codes you don't have a lot of choice. It's either: dark red (which looks bad) or bright red. With custom colors you can go any color inbetween.
When there are many available colors you can pick different colors for different types of thing and yet have them readable.

Moreover, in my case, I have a set of variables where you can define each color, so you can go with shades of gray, for example, for each highlight. of just disable several classes/types of events you don't want to hightlight (by making them default text color or just disabling a whole class).

Talking that "supporting" my system is dumb because my coloring looks too much for somebody that is what is really dumb. My coloring isn't the constant set, you can redefine it as you would like.
Supporting it has nothing to do with good or bad coloring. It is not about coloring at all. My request was to make mud output more conforming. More regular with less exceptions.
I will give you a simple example. Assume you asked sombody to write some text report about something (let's say the average salaries in cities). He can come with two variants:
- write very randomily formatted text
- put it in a nicely structured table.
I definetely will prefer the second variant. Why? Because it's easier to read and follow when similar concepts look alike and structured.

The same happens with CF output. Notice, it has nothing to do with roleplay. It's just a request to print similar stuff using similar formatting because it's much easier to follow it. Whether I choose to color it and which color I pick for that is completely different and unrelated matter.
For the very same reason I don't really like many parry/dodge/shield messages that were implemented by Valg some time ago. I need to read CF information about my defensive move type and I can use my own imagination to add that variaty in my mind. I don't really like to be forced to read those 40 types of dodges that happens once in 20 regular dodges and serve the only purpose: confuse me.
Plus, in reality, people hardly have time to read them all in fights.

Specifically about combat rounds highlights:
I hightlight several things:
- my damage to opponents. Because it helps me to see what I'm hitting and how much.
- Opponents damage to me. Easier to track what is hitting me in spam.
- my defensive moves. Because sometimes I fail to notice when people redirecting on me or assist or anything like that but I haven't receieved any damage yet (I parried it all). Highlighting defensive moves makes easier to follow that stuff.
- third party damage. I don't really highlight it, I use default CF damage color instead, but I hightlight it in my logger scripts.

Combat color picks explanation:
1) I had to a pick a soft color for hightlighting my moves. I decided to go light cyan because it is much less aggressive than ANSI cyan or Yellow. And it is close to white while being easier to notice.
2) For opponents damage it is light red. That should be some kind of alarming stuff, so red is natural. But bright ANSI red isn't good for that, so I use soft red/magenta.
3) My damage. It's something that shouldn't be very alarming. Thus I pick some neutral color (Yellow) that is easy to notice yet not very aggresive. If you remove red colors (everything is good and you're winning) you will have only silver (default text), lightcyan (your moves) and yellow (my damage) in you output and the combat rounds will be more or less monochrome looking. It's not really fun to read all combat rounds painted in different shades of red. Red on black isn't great coloring scheme, though DurNominator may like it.

For other types of messages I use different colors as well.
If you dont want to hightlight a particular set of events you can just turn them of instead ot asking Zulg to break consistency in CF output.
For me, I prefer to hightlight many types with different colors. It makes easier for me to follow what happens and how I should react.
Examples:
- healing is purple. If I see purple I know something bad about me is cured, so if I don't have time to read I can just skip that line
- successeful skills "gold". This is consistent with my damage color. Some neutral color to let me know that things happen as I planned to.
- failed skills/spells - a shade of blue. Here I know that some skill/spells needs to be used again. But I don't want to go red or something.
- moving. People arriving/leaving. This is White.
- Some kind of orange marks all dangerous #### to me like "hold person", bash, etc. So in a combat I know what to read first. If DurNominator doesn't care about being bashed - good for him, he can disable that color.

Plus you miss another part of my system that is small but very important:
It's the prompt splitter.
CF isn't good at marking prompts with special ANSI codes that many clients recognize. Thus, if you spammed several commands and then receive several results together your text will be joint with prompts which makes it look ugly. And clients can't really distinguish it because it is just a text.
There are two solutions to that:
- mark prompts on the server side with GO-Ahead command that many clients will recognize. This is actually request to Zulg (though I made it severals years ago and got rejected).
Some reading about it: Muds and telnet
- use prompt splitter triggers on the client's side. This is much less robust implementation because it requires for a client to parse prompts that can be very different.

If you don't understand what about I'm talking below are two examples of badly formatted text from CF because of this prompt issue and fixed output:

CF output:

<prompt> Your dirt kick misses
round text

Fixed output:

<prompt>
You dirt kick misses
round text

Another common example. When you spam directions the situation where you spammed several commands is quite common. Thus almost all the time room descriptions are joint with incoming prompts:

CF output:

<prompt> Market Square
description

Fixed output:

<prompt>
Marker Square
description

Add %- to the end of your prompt, it's a CR+LF, then it will always be a fresh clean line.

I'm aware of that option but it's not a complete solution.
It solves one part but breaks other.
I want my commands to be on the same line with a prompt.

Something like:

<prompt> dirt target
You dirt misses
etc

This will not be the case with CR+LF.
Otherwise all muds would just implement CR+LF after a prompt.

GA command solves this problem. Because the prompt and the incoming text will be split and the prompt and my commands will be on the same line.

So I spent about a half hour trying to figure out what IAC/GA is, how to implement it, and I'm still stumped. I could find no good example anywhere.

http://support.microsoft.com/kb/231866

so IAC GA would be 0xFF 0xF9.

My googling also turned up that some mu*s use IAC EOR, which according to some site would be 0x19.

Now a PROPER telnet implementation should probably negotiate the use of GA but... uh...

Edit: so wouldn't implementing IAC GA/IAC EOR be as simple as dumping those bytes in the bitstream? Anything not conforming to telnet protocol would display "ÿù" or "ÿ↓", though.

ROM 2.4 sources

Look in comm.c
Some definitions are in tables.c and telnet.h

Personally I find the bright red that CF defaults to as incoming now to be perfect. Each computer screen shows color very differently, and especially the normal ansi blue is extremly hard to read on my screen against the black background. I suspect your screen has a very bright color setting if you find the light red to hurt your eyes. (I even use normal bright white as the "general text color", and it is not very bright and suits me fine.

Oh and I find it much harder to catch something important that happens with a color. Its much easier to echo it in cyan like #echo *** Bash protection down!! ***

>Personally I find the bright red that CF defaults to as
>incoming now to be perfect. Each computer screen shows color
>very differently, and especially the normal ansi blue is
>extremly hard to read on my screen against the black
>background.

ANSI blue is too dark in most cases, I agree.

>I suspect your screen has a very bright color
>setting if you find the light red to hurt your eyes.

My settings are normal. And I have several monitors + notebook screen.

>(I even use normal bright white as the "general text color",
>and it is not very bright and suits me fine.

I guess that your monitor is too dark :)
Using shades gray instead of pure white is very common in the computer world. Especially for text on black background.

>Oh and I find it much harder to catch something important that
>happens with a color. Its much easier to echo it in cyan like
>#echo *** Bash protection down!! ***

That's how people did it in 90th, when they had no colors.
I assume that each man has its own preferences, though it still confuses me why would some people prefer to read twice as much text and find it easier to read. I guess it's just old habit (which is possible to correct, actually).

I have seen setups like:

Your bash misses
**** BASH MISSES ****

For me it is easier to color the original message instead of repeating it twice and increase the spam.

Often it takes longer to read a line than seeing a *** Bash prep fell! *** echo. Especially evident if your fighting and the text spam across your screen, then your likely to miss what that colored text wanted to inform you about. Much easier to read the short and clear *** BASHED! *** echo.

>Talking that "supporting" my system is dumb because my
>coloring looks too much for somebody that is
>what is really dumb.

Supporting your system is dumb because your system conforming to the changes in the game is much better alternative.

>Red on black isn't great coloring
>scheme, though DurNominator may like it.

I've made the red a bit brighter from the client colour settings so that it can be seen easily enough.

>If DurNominator doesn't care about being bashed - good
>for him, he can disable that color.

Bash can be stopped with chest muscles. Granted, some of those highlights may be useful. I'm a MUSHclient user myself, so I have no idea whether or not your file for CMUD functions in it. As I don't want to copy all your highlights blindly, I'm not going to try to add up the file in there. Feel free to post a list of trigger phrases sorted by colour (I'm adding them in the GUI anyway if I choose to do so) if you want to be helpful in this aspect.

Could make it so that if you hit somebody you always do 1 hp of damage at minimum. Then leave the rest of the code alone.

>Could make it so that if you hit somebody you always do 1 hp
>of damage at minimum. Then leave the rest of the code alone.

I thought about that as a possible solution, then decided against it.

For they shall not have to fear death by paper-cut!

.

Not a bad idea...
But it messes up with highlights. Can we come with a different single-worded web?
"touches" or whatever.

>Not a bad idea...
>But it messes up with highlights. Can we come with a different
>single-worded web?
>"touches" or whatever.

Uhm...no.

All damage verbs are single-worded :)
Why make an exceptiion for this one?

"does UNSPEAKABLE THINGS to" is a damage verb, too.

Something will pop up with that. Just to show himself smart.
But in this case it covers the out-of-range damage and it's not easy to come with other words. Though I wouldn't mind if it was a single word.

if you think that the highlight thing is a problem.

>All damage verbs are single-worded :)
>Why make an exceptiion for this one?

As has already been pointed out, it is not the only one. As for why...I see no good reason to. "Because you have problems with highlights" is not a good reason.

...is he's given time to help the community with some useful highlights that anyone can use. You change something that breaks it and he asks for a substitute (given I didn't like his new one either).

Don't gotta be rude about it.

>...is he's given time to help the community with some useful
>highlights that anyone can use.

I have no idea what you're talking about. I'm also stumped why you would need highlights...since damage is already colored.

>You change something that
>breaks it and he asks for a substitute (given I didn't like
>his new one either).

And as I said, I don't find that to be a good reason.

>Don't gotta be rude about it.

Not sure why you think it's rude, that wasn't my intent. Just giving my point of view.

It's pretty slick.

http://sites.google.com/site/dwoggurdsden/dwoggurd-s-den/carrion-fields

nt

Damage being done to you is in a different color than other damage. Great...now it's part of the mud and everyone has it instead of relying on a client.

You changed the color of damage you recive, I love it! That aspect is the only part of the Dwoggurd script I use. It makes it so much easier to keep track of stuff when you are in large group fights.

n/t

In the same alley as the incoming, maybe allow outgoing damage from you (and potentially your pets) to be colored differently aswell. The dwoggurd script has this feature aswell. I dont find that feature to usefull but many people do.

Another coloring option that I would like see implemented is a yellow (PK) flag, ive been coloring (PK) yellow for years now. Makes it ALOT easier to spot the enemies in who, who group and where.

Third and last, perhaps the bigger one. Allow coloring to be customizable. If you want the incoming damage to be changed to something other than the default, you can for example do the command 'color incoming purple'. Perhaps even 'color outgoing green', 'color objects yellow', 'color exits pink' etc.

Feel encouraged to suggest stuff like this as you think of it.

I won't guarantee all of it will be implemented or the stuff that is will be quickly, but periodically we try to figure out what kind of stuff is so important that everyone with a client is highlighting it and try to make it part of the game. You've seen this in the past with things like dispel echoes.

Three suggestions from me, all of which I feel the playerbase would appriciate a great deal.

I also highlight (PK) in yellow.

nt

Red like communism

nt

I may have to keep highlighting it yellow then. :)

Товарищ

http://www.youtube.com/watch?v=f2-zzmCmMVI

http://www.youtube.com/watch?v=BivjKSTfq4I

Why the Soviets chose to sing their national anthem in Swedish remains a mystery, but that's how things are.

>In the same alley as the incoming, maybe allow outgoing
>damage from you (and potentially your pets) to be colored
>differently aswell. The dwoggurd script has this feature
>aswell. I dont find that feature to usefull but many people
>do.

Can't say I'm overly excited about that, and we've only got two shades of red.

>Another coloring option that I would like see implemented is a
>yellow (PK) flag, ive been coloring (PK) yellow for years now.
>Makes it ALOT easier to spot the enemies in who, who group and
>where.

I've been highlighting (PK) in red since the day I started playing CF. Probably a good thing to add, if there is an easy way.

>Third and last, perhaps the bigger one. Allow coloring to be
>customizable. If you want the incoming damage to be changed to
>something other than the default, you can for example do the
>command 'color incoming purple'. Perhaps even 'color outgoing
>green', 'color objects yellow', 'color exits pink' etc.

This is probably lowest on the totem-pole for me, as I think it would be a nightmare to deal with since all of those are currently hard-coded and that's a boatload of lines of code to change for very little benefit.

>>In the same alley as the incoming, maybe allow outgoing
>>damage from you (and potentially your pets) to be colored
>>differently aswell. The dwoggurd script has this feature
>>aswell. I dont find that feature to usefull but many people
>>do.
>
>Can't say I'm overly excited about that, and we've only got
>two shades of red.

It dont have to be red, it can be yellow like in Dwogg's script. But I see your point.

>
>>Another coloring option that I would like see implemented is
>a
>>yellow (PK) flag, ive been coloring (PK) yellow for years
>now.
>>Makes it ALOT easier to spot the enemies in who, who group
>and
>>where.
>
>I've been highlighting (PK) in red since the day I started
>playing CF. Probably a good thing to add, if there is an easy
>way.

If its not a large amount of extra work you could add a color picker to this color option, since if you make it red the chances are we who are used to yellow will just continue to use the color trigger.

>
>>Third and last, perhaps the bigger one. Allow coloring to be
>>customizable. If you want the incoming damage to be changed
>to
>>something other than the default, you can for example do the
>>command 'color incoming purple'. Perhaps even 'color
>outgoing
>>green', 'color objects yellow', 'color exits pink' etc.
>
>This is probably lowest on the totem-pole for me, as I think
>it would be a nightmare to deal with since all of those are
>currently hard-coded and that's a boatload of lines of code to
>change for very little benefit.

n/t

The main point is that your damage you are dishing out is a different color than that you are recieving or that your friends are dishing out. I'm sure it would be very useful to see in a raid situation and such.

If it were written for Wintin I might use it :P

But all in all a good dicussion this thread. A bit to much ranting but still one of the better I have read for a wile.