Zugg Software :: View topic

Posted: Wed Nov 08, 2006 11:52 pm

First, I need to apologize for the poor quality of v1.13. Now I know why some people seem to be so angry.

Yesterday I fixed a bunch of problems, including the new bug where pressing Enter on a blank line wasn't sending anything to the MUD. That was a side effect of the new OnInput processing occuring on every line sent to the MUD. OnInput normally won't send blank text to the MUD. For example, using the new #NOINPUT command clears the buffer of text being sent to the MUD, so nothing is sent.

So I had to make an exception when using the command line, or when specifically trying to send blank text to the MUD (like #SEND "")

What I also discovered was that *.MUD settings files were not getting loaded/converted at all. I don't know when this broke, but it *used* to work fine. Part of the problem was that the Default Settings (default.pkg) somehow got a "System" class added to them. This was deleted a couple of versions ago, so I'm not sure how it got back in there. Since each *.MUD file also contains their own System class, it was getting confused and placing your imported settings into the default package.

To make matters worse, the changes to the Settings Editor caused it to not create a new tab for the imported settings. So even though the settings were in memory, they didn't show up in the settings editor.

Yeah, it was a complete mess.

Today I added the Compatibility Report to the loading of *.MUD files from the session screen. When opening a session using a *.MUD file, it will convert it to a PKG file and then ask if you want to view the compatibility report. I also uncovered some problems with the compatibility report that I'm fixing.

I also started looking into the multiplaying issues. This gets really complicated. I know a lot of people are upset about how this worked right now, but I assure you that it is NOT WORKING the way I want it. The whole point is to make this EASIER than zMUD and not harder. So I'm well aware of the current problems.

But what gets complicated is that there is only a single screen layout. So when you open two session icons, and CMUD autosaves the layout, which session should get the new layout?

The answer turns out to be "neither". If you want to save a new session icon that automatically loads both sessions, then you need to select the File/Save Session As to save the double-window layout to a new session icon. Currently v1.13 saves the screen layout to the last session that was open, which can really mess it up. But in 1.14 the AutoSave Layout option gets turned off when you load a second session.

I'm also changing how packages are handled when loading multiple sessions. I'm going to try and figure out how to support loading multiple copies of the *same* session. In v1.13 it won't load multiple packages with the same name. So when you load 2 copies of your session, there is only a single copy of the package in memory, so you still only have a single window on the screen, which isn't really what you want.

Anyway, I'll be spending more time this week trying to get all of this multisession stuff working better, and to make it work better with converting your existing *.MUD files.

Today I also got side tracked on a bad parser issue. This was posted over in the Beta Forum, but it was a problem with #REGEX not recognizing the ID value before the pattern. I thought this was a trivial one, and when I looked at the code and compared #REGEX with #TRIGGER, it looked like it *should* work.

Turns out there was a huge bug in the parser when counting parameters to commands in some cases. Especially when there was an odd number of parameters.

This is partly a result of how Yacc works (the parser generator that CMUD uses to build the parser). I've mentioned this in a blog entry before, but Yacc always looks ahead one state. And in the CMUD parser, some states are psuedo-states that just execute some code. So there were cases where Yacc would look ahead, causing some code to get executed, but then Yacc could back up again if the correct token wasn't found.

In this particular case, the code being executed was doing a Push of the current stackframe. So Yacc would look ahead, causing a Push, and then back up and never do the Pop. So the stack could get screwed up.

This isn't the same stack as the runtime stack, but it *is* used to keep track of things like the number of arguments given to a command. Imagine the example:

Posted: Thu Nov 09, 2006 2:30 am

Zugg, sounds like you've had a really rough week. But it's kinda to be expected. Remember 13 is an unlucky number. Laughing

I have a gut feeling that 1.14 will be alot better (and rest assured we'll all bang against it.)

I'm looking forward to more discussion on how Event's will work I have to go search to see if there are any that I've forgotten.

You'll get the bugs knocked out soon enough. As an aside, I was hoping we could get an update on Chiara's CMUD experience and introduction to mudding.

Posted: Fri Nov 10, 2006 2:40 am

Another long day again today. This is really becoming a big struggle. I'm really not happy with all of the bugs I'm still dealing with (and I'm sure you're not happy about it either).

Today I found yet another problem that was being caused by the background database update thread. Have I mentioned recently how much I *hate* threads? This one was really obscure. But I found a case that was reproduceable. What I was doing was importing a *.MUD file provided by a user. It would import just fine. It had a main window, and 2 child chat windows. Upon exiting and reloading, the main window was no longer displayed. When I checked the settings editor, I found that the main window was now marked as a Module instead of a Window.

So I go back and add some breakpoints to the code and try it again. This time it works just fine. I take out the breakpoints and the problem happens again. Setting debugger breakpoints is NOT supposed to do this!!! Of course, setting breakpoints changes the speed of the program. And this was enough to cause the problem not to occur. So I added some code to try and trap where the Module/Window option was being reset. I had a heck of a time doing this without altering the speed and making the problem go away.

I *finally* got a setup working where I could capture some debug information and still get the problem to occur. Each setting in CMUD has an Options field, which is a bunch of boolean flag values. Each setting type has different flags. In this case, the Module/Window flag is bit number 9. Bit number 9 is also used by Triggers to indicate an alarm. Somehow, setting the alarm option bit for a trigger was instead setting the Module/Window option for the main window!

This is bad. This was happening in my low-level SetFieldValue routine. This routine takes a record number, a field number, and a value. It was being called with the record number of the trigger, but somehow changing record zero instead (which is the record of the main window).

Turns out that I was not Locking and Unlocking the database within this routine. So if the background database update thread was running at exactly the right (or wrong) moment, then in the middle of the SetFieldValue routine the database buffers could get changed, causing data corruption.

That was 5 hours right there. But this was a nasty bug that could have been causing all sorts of really wierd problems. I was just lucky to run across a case I could reproduce most of the time.

The next bug to fix was the one reported in the forums about settings getting deleted when you clicked on various things in the tree view. First I thought I had already solved this on Tuesday. And it's certainly possible that I did something that helped. I could not get it to fail just simply clicking on items in the tree. However, one time I accidentally double-clicked, which toggles the enabled flag for the setting. Then all hell broke loose and settings started getting renamed and deleted just like in the post.

This took about an hour to track down. Basically, my double-click event routine was calling my ToggleEnabled routine, which toggles the bit in the database record indicating if the setting is enabled or not. But I learned that the DevExpress tree view is doing some annoying stuff with Windows messages. Instead of doing some stuff right away, they post some messages to the Windows event queue. So when my double-click event is called, the Treeview isn't actually updated yet with the correct focused record. So it would change the database record of the wrong setting and then change the database record out from under the treeview. So when the treeview messages got processed from the queue after this, the tree wasn't in the same state as before, and that caused all sorts of data corruption.

So I had to create my own event message so that the double-click event routine would just post my ToggleEnabled message to the Windows queue, which would then execute after all of the other queued messages finished.

The good news was that, as announced in the forum, I also found the bug causing the preferences to not save. This is the issue with fonts and colors getting reset that has been reported for many versions now. I was very happy to finally fix that one.

Anyway, that was today's mess. You'd think that by now I'd have bugs like the database update thread issue fixed. These are not the kind of huge bugs that I should be dealing with at this late phase in the beta. I'm really starting to worry about the public release. Because of vacation issues at Christmas and some financial issues, the public release deadline is really pretty solid. I have a couple of days of flexibility, but that's about it. My preference has always been to just release something when it's ready. But I don't have that luxury this time around. So all of these bugs are really stressing me out.

Oh well, just taking it one-day-at-a-time right now. Getting all stressed about it certainly isn't going to help anyone.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Well, on the one hand you are seeing huge bugs that you didn't expect. On the other hand you are fixing these bugs and as a whole cMud is much stabler already than it was a few versions back. You could get to the point, and may already be there, where fixing one bug has a domino effect and fixes a lot of the bugs you did know about.

I'm starting to venture out of the strictly safe zones in the muds I play with cmud. I just wouldn't do that a few versions back.

Yes I know it isn't safe to do that. I also am not picking any fights while stepping out of hiding.

Wizard Joined: 14 Aug 2004 Posts: 1269

Yes, don't get stressed about the public release, Zugg. Just keep whacking the bugs as they pop up and you'll get there, or at least near enough.

Posted: Sat Nov 11, 2006 4:31 am

I'm going to take my two-day weekend on Saturday and Sunday this week just like a normal person Wink

So I went ahead and released v1.14 tonight. It has all of the major bug fixes that I've been talking about in this blog, plus a few I didn't talk about yet. There are still lots of bugs to be fixed, so don't get too upset if your favorite bug isn't fixed yet. But this made a pretty good dent in the really major problems I think.

As mentioned in the version history, I think I figured out how to allow you to open multiple copies of the same session. So give the multisession stuff another try and see if it works better now. It should dock the sessions a bit better, and it will turn off the auto-save for the layout so that your single-character layouts don't get overwritten with the multi-session stuff. You should still be able to use the Save Session As to create a new session with the full layout saved.

I tested a lot more *.MUD files this time around and played with the compatibility report a bit more and fixed several problems with that. So hopefully this version will work a lot better importing your zMUD files. In fact, I'd probably recommend re-importing your *.MUD files since the previous versions has the database corruption possibilities that I mentioned earlier in this blog.

I hope it's finally saving all preferences and session options properly now. That was a major focus of my bug fixing today.

I also took some time to add the Auto Append option for aliases so that they append unused arguments like they did in zMUD. The default is normally off, but this option is automatically enabled for each alias that is imported from a *.MUD file.

Anyway, I feel a bit better today about this release. I certainly think it's a big improvement over 1.13, so at least that's positive progress. But I think I'm going to log off now and try to relax a bit tonight. Even though I'm not doing any programming tomorrow, I'll still log into the forums and see how the 1.14 release is going.

So go find more bugs! Smile

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Sat Nov 11, 2006 5:49 pm

The main driving factor is when the existing zMUD discounts end. I've said that they end when the public version is released, and I need this to happen before the Christmas break.

Wizard Joined: 14 Aug 2004 Posts: 1269

I thought you said they were only valid during the beta period... but I suppose you've probably said both at various times, which makes it difficult to slot in a further release stage. Anyway, just an idea.