Zugg Software :: View topic - Poll: What urgent problems still need to be fixed?

Novice Joined: 14 May 2004 Posts: 37

Okay, thanks for the update. :) I'm looking forward to the new chat capabilities.

As for bugs, I can still get 100% CPU lockup from CMUD [1.16] in 4 easy clicks, as I reported in another thread a while ago.

Wanderer Joined: 09 Nov 2006 Posts: 55

dont forget reverse paths... as a zmud user, I constantly use ..path to reverse it. although it just takes a few secs to #al ..path {#re path}, its not a natural slip from zmud to cmud...

and %if(a,a,b)
:)

Apprentice Joined: 29 Jul 2003 Posts: 101 Location: USA

You might take a last once through of the buttons.

If I'm remembering from last night, I was missing the parsing on/off icon and the trigger on/off icon when I upgraded to 1.16.
When I moused over the blank spots, I saw the balloon help come up for them, but no icons, nor change of state indicated when I tried to turn parsing on or off.

Posted: Mon Nov 27, 2006 10:01 pm

jg1lbert: what is wrong with %if(a,a,b) ? If there is a separate topic on this, then that's fine, otherwise please make a bug topic since I don't know what problem you are referring to.

Yamabushi: the parse/trigger button issue sounds like a corrupted toolbar layout file. Delete the *.TBZ file for your session and see if that helps. Also try just resizing the CMUD window and see if the icons appear then.

kernighan: if you posted your method for making CMUD lockup and I already responded to it, then it should be on the bug list. But it doesn't hurt to remind me what post you are talking about.

Magician Joined: 13 Oct 2000 Posts: 463

I would disagree Seb. While I *personally* don't care about backward compatibility, it's crucial for less skilled users. If their scripts stop working, they are not going to look on Zuggsoft and see what new features they can use now... they are going to whine, or quit buying new CMUD versions because it 'broke their scripts'.

Take a look at Microsoft... they had a product, Visual Basic. They made a huge update/improvement to it with VB.NET... but they did not maintain backwards compatibility. Hundreds of thousands of crappy programmers cried out in horror. The new VB was demonstratably better in almost every way... but it was not backwards compatible.

Posted: Tue Nov 28, 2006 5:46 pm

Raven: Yeah, but VB isn't a very good example. With zMUD->CMUD we are talking about 90% compatibility. With VB.NET there was something like 0% compatibility (ok, maybe that's an overstatement, but it was pretty bad).

But that's really not what we should be talking about here. The compatibility is already as good as it's going to get. There is no way to make CMUD 100% compatible with zMUD. And people are going to whine no matter what I do.

Magician Joined: 13 Oct 2000 Posts: 463

Actually, VB.NET was about as compatible with VB6 as CMUD is with zMUD... the difference is more in how people used VB vs how they use zMUD... there are more simple, trivial programs written in zMUD, so it's easier to make them compatible or do a little conversion. The programs in VB6 tended to be far larger, more complex, with more dependancies than you'd ever see in zMUD... so the same level of compatibility between the two resulted in far more headaches for a VB6 conversion.

At least, from what I understand. I could be wrong, as I did very little VB6 coding myself.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

There are a whole bunch of Package Editor things that pretty much still keep me from doing any real testing. The import of my old zMud files finally went well. Then because of the changes in packages, modules, and windows I have to make a number of tweaks to get rid of old unnecessary :window syntaxes, and bad @window.variable syntaxes. Also I had to clean up a number old classes. In the process I decided to make use of the package system and move portions out of my old main file and into properly published modules in seperate packages. A few of the problems I have run into (feedbacks posted on all replicatable ones)

1. A setting was deleted by the old blanking bug, this has only happened once and I can't get it to happen again.
2. Open/Creating a package causes confusion of the tabs and allows moving a setting into the read-only Default package
3. Copying to other packages by right-click Copy To... and Move To... don't work
4. Packages can become corrupted still, by closing thier tab at the wrong time.
5. Copying settings to other packages is extremely problematic, sometimes resulting in very odd displays.

I am sure there are more with the Package Editor I will run into, and who knows just how urgent they are since most involve working with multiple packages.

Posted: Tue Nov 28, 2006 7:59 pm

Yes, and those package editor bugs are the most depressing for me because they are so intermittent and hard to find. And it's all because of the stupid flaky tree view and the kludge to keep it updated properly. I'm really torn on this one...part of me want to just throw it out and start clean with a new non-database package editor. But there is no way to do this in time for the public release, and financial difficulties prevent me from delaying the public release. And delaying the release really doesn't help much because nothing is going to get done over the Christmas holiday anyway and we can't afford to go another 2 months like we are now.

So I'm forced to live with the crappy settings editor flakyness and just try to patch it up the best that I can. But all 5 of the issues that you reported are all things that I've spend numerous hours already working on. Everytime I think it's fixed, it just breaks again. It's very depressing.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Perhaps you could put in something to turn off the background updates for the next version so we can test whether these sort of problems are related to that, or more directly related to the tree view. Some of the bugs I have found in the past few hours are probably caused by only 1 of those things. If it can be narrowed down to bugs caused by the tree view itself and those get fixed then it might be possible to just disable the updating during certain operations.

I am sorry to hear that these bugs are depressing, CMud is vastly better then even a few version ago when I could barely even test anything. It will get there.

Novice Joined: 14 May 2004 Posts: 37

Hi Zugg,

I never received a response from you about the lockups I encountered, although Seb responded a few times.

You can see the entire thing here, with screenshots:

http://forums.zuggsoft.com/phpbb/viewtopic.php?t=25227&postdays=0&postorder=asc&start=15

--Kernighan

Novice Joined: 14 May 2004 Posts: 37

I can confirm the lockup occurs still with 1.17 as well.

--Kernighan

Posted: Tue Nov 28, 2006 9:29 pm

Vijilante: You can already turn off the background updating. In the View menu, turn off the Auto Update option.

kernighan: I think I didn't respond to that thread because I couldn't reproduce it. I just tried your procedure in 1.17 and it worked fine here. Have you done a clean install lately?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Oops I missed that one, I remember seeing it before too. I guess I forgot that it was there, I will retest a bunch of stuff and see what happens.

Magician Joined: 13 Oct 2000 Posts: 463

Zugg, perhaps you should turn off background updating by default, until you get a chance to really iron out the bugs in the tree view, or replace it. Also, saving the choice as a preference, so I don't have to remember to turn it BACK OFF after every crash would also be nice.

Novice Joined: 14 May 2004 Posts: 37

Zugg: I've removed and reinstalled CMUD multiple times, and I always get the problem. I've installed CMUD on a system that doesn't have ZMud installed, and has only ever had CMUD installed, and I get the problem. I'll be getting a brand new laptop this week or next, I'll see if I can reproduce it on there as well.

--Kernighan

Posted: Wed Nov 29, 2006 1:05 am

kernighan: I don't know what else to suggest. I'll go bump your other thread to see if anyone else can reproduce it. I can't get it to happen on any of my computers here.

Raven: No, with the background updating turned off, then things can get a lot worse, since it doesn't update the settings editor properly at all. Turning it off temporarily is good for debugging problems, but leaving it off all the time will cause other problems.

Adept Joined: 04 Feb 2005 Posts: 246

The important thing about CMUD isn't to me to have backwards compatibility--but if it doesn't, then it should do *migration*. It's going to be a daunting task for me to do just the "%1" -> %1 edits throughout my scripts.

Posted: Wed Nov 29, 2006 6:14 pm

Well, if it was as easy as just doing a global replace, then CMUD could do it (or you could export to XML, do a global replace, then import). But the problem is that it's not as simple as a global replace. So that's what the Compatibility Report is for. Click on each script that has this error to open it in the settings editor and then fix the syntax. This might take time, but it gives you a chance to actually look at each script to make sure you are fixing it correctly. But with the Compatibility report, this should actually go more quickly than you might think.

Posted: Sun Dec 03, 2006 2:00 pm

I'd like to add to this that there was reported a couple of versions ago some bugs with settings not being saved - things like the read only option on packages, and some of the checkboxes for triggers and such. Some of them still exist (there are new bug reports for them, like the case sensitive bug), and I think they're pretty urgent.

Posted: Mon Dec 04, 2006 10:18 pm

There was a new bug in 1.18 that was messing up the options for anything that was copy/pasted. But I'm not aware of any others, so be sure to make separate topics for reporting other bugs. The readonly checkbox was fixed a while ago.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

I'll pipe up for a sec..
the work you have done is great, and I really like what you are doing with cmud.
Playing a single player with cmud right now is pretty stable, and I run into vert few problems, but it goes downhill fast if I start opening other sessions, and other window. I think that needs to be high on the priority list, because without that, I can't use cmud, and I'm sure others are the same.

I would not expect compatability between beta versions, and don't consider that a problem at all. Honestly, I don't even try to import my old settings, I'd rather build them from scratch -- to learn the interface, and get more familiar with where the settings I might need to change in a moments notice are.

One word on help files (ok -- a few more than one) , I get more out of examples, than by reading 20 paragraphs of text. Please -- show lots of examples, and if the first help-files were more examples than text, I'd be pretty happy!

Thanks and keep-up the good work.

Posted: Tue Dec 05, 2006 7:45 pm

I'm aware of a bug that can cause multiple session pkg files to get confused, but if you have some other problem with multiple settions, be sure to create a new topic to discuss it.

As far as the help files, there are already examples for almost every command and function. While these examples haven't been formally tested in a while, most of them should work. The problem with examples is that every MUD is different, so I can't provide very many useful examples that anyone could use on their MUD. In any case, I tend to disagree and think that the topics for the newer features, like the package library and package editor, need to come first. If there are specific topics that you think need better/more examples, start a new forum topic about improving the help file and give me more specifics.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

No, that is the bug I am refering to -- it's a big one on my list.

I can see how packages will need to be explained, and that would be a higher priority than commands. I wasn't seeing the big picture on that one...

The things I was talking about was stuff like the
#button help file -- without examples, there is almost no way to get the syntax for it correct. I had to go to the forums, and search for it to find enough to make it work.
If I can see a example of a command that uses most of the paramaters available, I can make it work. the #button thing was recent in my mind, and that's why I mentioned it.

Posted: Tue Dec 05, 2006 9:30 pm

Ugh, #button is a horrendous command to use from the command line. I don't know why anyone would want to :(