Tweet
Each brand or slay has a verb defined for it so that when the damage is increased on a hit, instead of getting the message 'You hit the troll' it says 'You burn the troll' or whatever the brand/slay-specific verb is.
I thought it would be nice to highlight these verbs with color. I looked into the code and alas, it appears not easily doable, because these messages go to the message log and out through the 'EVENT_MESSAGE' handler which doesn't have any way to colorize one part of a string being messaged.
The only code I saw that puts out color is c_put_str, where you write directly to a screen location and provide the color as a separate parameter.
It might be possible to define some kind of 'color shift' character escape sequence, embed it into message strings, then handle it at the low level when the strings are being put to the screen (and strip it out for strings being put to the log file), but that's waaay too much work for my little WIBNI.
And while I'm wishing for the impossible, I wish there were color attributes for reverse video.
I suppose all this has been thought of and discussed before. Let me know if I'm incorrect on any of my understandings.
Is there any thought of eventually rewriting all the term stuff that still supports, or purports to support, the sort of 1980's dumb terminals that no longer exist? You could still have a lowest-common-denominator terminal-like output device assumption but raise the lowest-common-denominator a bit to exclude ancient devices that are no longer used.
I thought it would be nice to highlight these verbs with color. I looked into the code and alas, it appears not easily doable, because these messages go to the message log and out through the 'EVENT_MESSAGE' handler which doesn't have any way to colorize one part of a string being messaged.
The only code I saw that puts out color is c_put_str, where you write directly to a screen location and provide the color as a separate parameter.
It might be possible to define some kind of 'color shift' character escape sequence, embed it into message strings, then handle it at the low level when the strings are being put to the screen (and strip it out for strings being put to the log file), but that's waaay too much work for my little WIBNI.
And while I'm wishing for the impossible, I wish there were color attributes for reverse video.
I suppose all this has been thought of and discussed before. Let me know if I'm incorrect on any of my understandings.
Is there any thought of eventually rewriting all the term stuff that still supports, or purports to support, the sort of 1980's dumb terminals that no longer exist? You could still have a lowest-common-denominator terminal-like output device assumption but raise the lowest-common-denominator a bit to exclude ancient devices that are no longer used.