|
k_starling Beginner
Joined: 06 Aug 2010 Posts: 11
|
Posted: Mon Apr 11, 2011 6:17 pm
[3.33a] Xterm color bug |
Aardwolf has just implemented the Xterm 256 color protocol. It appears that Cmud might not handling this properly.
The xterm colors 0 to 15 should correspond to the ANSI equivalents, but they don't. Here's an example:
http://www.aardwolf.com/temp/cmud-colors.jpg
Also, apparently the bold flag or some such isn't being cleared or reset when cmud receives a new color code. This might be a known issue, but just wanted to mention it here in case.
Hopefully that helps. |
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Mon Apr 11, 2011 8:13 pm |
First question: have you set your Cmud window to use Xterm protocol?
|
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Mon Apr 11, 2011 11:44 pm |
Are you referring to Terminal Type, Rahab? I couldn't find any other reference to Xterm in Preferences. Not sure that field does anything more than tell the server what name to refer to your client as, so that if necessary it can properly enable any appropriate serverside stuff. The default is CMud.
|
|
_________________ EDIT: I didn't like my old signature |
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Tue Apr 12, 2011 12:01 pm |
Yes, I meant the terminal type. I thought it would affect more than that. Oh well.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Apr 12, 2011 4:11 pm |
I'm not sure I understand your screen shot. The first column of colors look like the correct ANSI colors to me. Your second color that says ANSI does not match what ANSI colors are supposed to be.
To test XTERM colors I have used a Perl script called 256colors.pl that you can find on the Internet. I've never seen any problem with it. But maybe you can show the script that you used to generate the above picture so I can test it.
Also keep in mind that XTERM 256 color protocol allows each of the colors to be redefined as needed by the server. CMUD doesn't have any GUI for changing the 256 colors manually, but if you look at the 256 color spec you should be able to figure out the control codes needed to change the RGB value of any of the 256 colors. |
|
|
|
charneus Wizard
Joined: 19 Jun 2005 Posts: 1876 Location: California
|
Posted: Wed Apr 13, 2011 12:24 am |
In the screenshot, the first column are the 256 xterm colors. The second column is supposed to be the ansi equivalent. As you can see, they are not. Here's the raw input/output:
Code: |
[38;5;0mColour 0 Test [0m [1;30m Same color in ANSI[0;37m
[38;5;1mColour 1 Test [0m [0;31m Same color in ANSI[0;37m
[38;5;2mColour 2 Test [0m [0;32m Same color in ANSI[0;37m
[38;5;3mColour 3 Test [0m [0;33m Same color in ANSI[0;37m
[38;5;4mColour 4 Test [0m [0;34m Same color in ANSI[0;37m
[38;5;5mColour 5 Test [0m [0;35m Same color in ANSI[0;37m
[38;5;6mColour 6 Test [0m [0;36m Same color in ANSI[0;37m
[38;5;7mColour 7 Test [0m [0;37m Same color in ANSI[0;37m
[38;5;8mColour 8 Test [0m [1;30m Same color in ANSI[0;37m
[38;5;9mColour 9 Test [0m [1;31m Same color in ANSI[0;37m
[38;5;10mColour 10 Test [0m [1;32m Same color in ANSI[0;37m
[38;5;11mColour 11 Test [0m [1;33m Same color in ANSI[0;37m
[38;5;12mColour 12 Test [0m [1;34m Same color in ANSI[0;37m
[38;5;13mColour 13 Test [0m [1;35m Same color in ANSI[0;37m
[38;5;14mColour 14 Test [0m [1;36m Same color in ANSI[0;37m
[38;5;15mColour 15 Test [0m [1;37m Same color in ANSI[0;37m |
As you can see, the colors are mismatched. Other clients have been able to display both colors correctly, so it is apparently a CMUD issue. As xterm is going to be pretty prevalent in Aardwolf once it is fully implemented, it would be wonderful that we'd be able to see the same colors as everone else. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Wed Apr 13, 2011 4:01 pm |
Ah, OK, now I understand.
I was confused because ANSI Color #1 (in CMUD terms) is not the same as the ESC 31m code. When you go into CMUD Preferences and into the ANSI Color section, you see the colors for ANSI colors 1-16 (Foreground colors). These are not in the same order as 31m, 32m, 33m, 34m, etc.
CMUD maps the first 16 XTERM colors to these same Foreground colors, and that is the bug. Instead of mapping the XTERM 38;5;1m to the ANSI 31m color, CMUD was mapping it to the 1st ANSI index shown in the ANSI Color GUI. ANSI 31m actually uses the 4th color in the ANSI Color table.
The confusion came from how Windows mapped it's original 16 colors. Back in the really old days before Windows had 256 color support and was only 16 colors, zMUD mapped the 8/16 ANSI colors into the 16 Windows colors. And it's been that way for all of these years.
In any case, I have added this to the bug list and should be able to fix it for the next update. Thanks for giving me more details on this so I could track it down. |
|
|
|
Myrkul Wanderer
Joined: 21 Aug 2008 Posts: 85
|
Posted: Thu Apr 14, 2011 3:13 am |
[edit][/edit]
|
|
Last edited by Myrkul on Thu Apr 14, 2011 10:19 pm; edited 1 time in total |
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Thu Apr 14, 2011 12:08 pm |
Myrkul, that sounds rather unfair. This bug has been known now for only a couple days, and it sounds like you are complaining already that it hasn't been fixed yet. Zugg said a few weeks ago that he was working on the next bugfix version. It is unrealistic to expect it to be out already, and completely untrue to say that bug fixes aren't happening. The biggest reason there haven't been any updates in a while is because 3.33 is so stable already. Yes, a few bugs have been reported since it was released a few months ago. None of the bugs were critical. And they are on Zugg's list to be fixed as soon as possible. It is likely that most will be addressed in the upcoming bugfix version. Do remember that there is exactly one programmer on staff at Zugg Software--Zugg himself, who also has to write and support other programs, do administrative work, and take breaks from time to time.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu Apr 14, 2011 4:21 pm |
Rahab is completely correct. v3.33 has been so stable that there haven't been enough serious bug reports to warrant a new version. I always reduce the frequency of updates once CMUD is in Public status to get it more stable. The fact that it hasn't been updated recently doesn't mean that it isn't being supported, it means that the current version is very stable and has less need to be updated.
Man, you just can't get a break with anybody. When I release monthly versions people complain that CMUD is unstable and that I'm releasing too many versions. When I release versions less often people complain that I'm not supporting it anymore.
Also, if you actually read my post about v3.34 you would also see that I already said I was taking a break for a while because I was burned out working with the Unicode conversion of CMUD. I never post actual release dates for anything...any dates are always subject to change at any time.
Anyway, back on main topic, I hope that Lasher's "fix" on the server doesn't cause a problem when the next version of CMUD is released and has this fixed. |
|
|
|
Myrkul Wanderer
Joined: 21 Aug 2008 Posts: 85
|
Posted: Thu Apr 14, 2011 6:42 pm |
[edit][/edit]
|
|
Last edited by Myrkul on Thu Apr 14, 2011 10:19 pm; edited 1 time in total |
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Thu Apr 14, 2011 8:20 pm |
[edit]Bleh...accidentally duplicated[/edit]
|
|
Last edited by Rahab on Thu Apr 14, 2011 8:23 pm; edited 1 time in total |
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Thu Apr 14, 2011 8:22 pm |
Sorry, Myrkul. I absolutely have to disagree. The great majority of users do not want to have to load a new version every couple months. They want to have a stable version that they can depend on for a while. New versions can mean that their code no longer works. They have to install it. They have to read new documentation. They have to check everything. What they want to do is play their muds, not worry about software changing under them.
Yes, if there are critical bugs, it is important to get bugfixes out quickly. But most people don't like it when new versions come out too often. Only those people who like to be on the cutting edge or help out with beta testing want frequent updates. There have not been any critical bugs in 3.33. Frequent releases of public versions is a sign that software is unstable, It diminishes customer confidence. It makes it harder for the typical user, and for the software producer. There has been no need for frequent updates since 3.33a.
In the software world, five months between updates on stable public versions of software is nothing. Software companies don't put out a new bugfix to correct just one bug unless it is a critical bug. They slowly correct multiple bugs and fix them in their internal versions until they decide it is time to put out a new release. Once a year, or even less frequently, is not uncommon. Putting out a new release requires quite a bit of administrative work which you don't want to do too often.
If Zugg were putting out new releases as often as every two weeks, as you suggest, he would never have time to get anything else done, like developing other programs to sell or new features in Cmud. For instance, if Zugg is working on unicode support for a few months, he can't stop every two weeks to put out a new minor bugfix release. There is only one development version--any new features he has only partially developed and still buggy would end up in the bugfix release. Can you imagine the problems that would cause? And each time he stops to make a quick bugfix release, he has to spend time seeing whether there are any major problems reported, and then more time getting back up to speed on the new development afterward. New features would take two or three times as long to develop, at least.
So I, for one, absolutely disagree with you on this. And I think you are wrong about what the majority of customers want. Individuals may want the specific bugs that bother _them_ fixed quickly, but in general I don't believe they want frequent unnecessary updates. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu Apr 14, 2011 10:05 pm |
Sorry Myrkul, but I also have to disagree. You obviously haven't run a software business before where you have to deal with thousands of users and millions of lines of code. If I released a new version every time I made every small little fix that somebody reported, then I'd have the vast majority of users screaming at me for releasing too many updates.
I don't think you have been involved in CMUD Beta testing, but during Beta testing, even releasing a new version every week is too much for most people, causing many people to stop participating in the testing.
When I release a new update, everybody running CMUD gets a popup notification of the new version. This bugs a lot of people and if I updated for every little thing, then people would just turn off this notification. It's like "crying wolf"...people start ignoring it after a while.
Finally, I don't just go into the code and apply a quick fix like you suggested. Sure, I looked at the code and sure I saw how to probably fix it. And that is what I entered into my issue tracking system. But when I do a release, I don't just change the code. I also run a whole series of tests to see if the "fix" had an impact on other areas of the code. Often times a bug fix in one area will cause a problem in another area. That's what testing is for. After running a series of tests, then I run my build scripts for CMUD, CMUDPro, and TeSSH. Then I have to update a bunch of stuff on the web site. The minimum amount of time to do a release after changing just one character in the code is about an hour. I'm not going to do an hours worth of work for every little thing that is reported. I save up bug reports until I have enough to justify spending a while on it. Unless the issue is major and is preventing people from playing. The bug reported here was not major...it was very minor...it only effected certain people on a single specific MUD. That doesn't warrant a new release that effects every CMUD user.
Edited: Also, in most cases I do *NOT* look at the code when answering forum bug reports. Usually I just run CMUD and try to reproduce the bug and then enter it into my issue tracking system.
So, sorry you feel the way you do. You won't find any software company in the world that works the way you are talking. Only hobbiest can get away with that, and not for very long. Been there and done that.
But for you to sit back and say things like "Zugg obviously isn't supporting CMUD anymore" when you have no idea at all what I've been spending my time on is just plain arrogant. While I've been working on Unicode conversion stuff, CMUD wasn't in the state to be releasing any updates. It's only now after I've rolled back all of the work from the past couple of months from my version control system that I'm able to go back to doing bug fixes on v3.x.
You also exaggerate because it's only been 4 months (Dec to Apr) not 5, and one of those months was December where I always take off most of the entire month. That makes it only 3 months of development time, which is nothing. Sorry you are so impatient.
Now I'll go back to work because just the time I have spent dealing with this silly post is time I could have been spending doing bug fixes. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Fri Apr 15, 2011 1:57 am |
Editing/Removing your comments?? That is horrible net-etiquette! Myrkul you should be ashamed.
|
|
|
|
Daern Sorcerer
Joined: 15 Apr 2011 Posts: 809
|
Posted: Fri Apr 15, 2011 2:24 am |
Well, it wouldn't have been necessary if there was a way to delete a profile, or even rename a profile, but apparently I couldn't do that, so I did it the hard way.
|
|
|
|
|
|