Zugg Software :: View Entry

Posted: Fri Nov 03, 2006 12:50 am

It's harder getting much programming time with all of the email support that I'm doing right now from the zMUD announcement. But I'm still trying to get some stuff done for the 1.13 (probably on Saturday).

The important new feature is the Compatibility Report. Currently it can be executed from the settings editor. It checks each setting to see if it compiles, and also checks most of the syntax changes from zMUD.

There is no way for it to actually "fix" or automatically convert your zMUD code. That would be asking for a lot of trouble since these cases usually indicate syntax issues, and trying to automatically fix them would probably totally destroy existing scripts.

So the Compatibility Report simply searches for these common problems, and flags them if they are found. Links to the Help system are given, and the name of the setting with the problem is also linked so you can click on it and view the setting in the package editor.

You can also save a text version of the report to a file (like if you need to send it to me for a support issue).

Seems to work pretty well so far. Tomorrow I'm going to add it to the *.MUD File import so that it gives you an option to run this report after it has converted a MUD file into a PKG file.

This should take care of the majority of support questions that I'm getting right now.

As you can imagine, I also have a pretty big list of bug issues to work on. I'm going to be focusing on parser issues and things that are stopping current zMUD users from trying CMUD.

The good news is that my big worry about the new settings editor being really unstable seems to be none existent. I was worried that I'd get a flood of crash dumps from the performance changes to the settings editor, but I'm hardly getting any. So it looks like the 1.12 settings editor changes are working better than I thought.

In fact, I'm probably getting more reports with syntax error problems and feedback on various things, than I'm getting actual crash dumps. That's not to say I'm not getting crash dumps...I am. But it's not as many as I worried about.

So, I'll try to get as much done for the 1.13 release on Saturday as I can, focusing on zMUD compatibility issues.

-----
As far as the announcement to zMUD users went, it went pretty well. I probably shouldn't have set the "track links" option in MailChimp, because this caused the links to be flagged as suspicious by a lot of people. And the click tracking didn't turn out to be very interesting data. Gee, people click on the CMUD information link and the Store link...imagine that.

Also, I accidentally forgot to filter the customer list by their order status, so people who got refunds for zMUD still got the email message. Fortunately, this didn't affect a lot of people.

Lots of people are downloading CMUD, and a lot of people are taking advantage of the Free offer. There are a lot fewer actual purchases (half-price or full-price), but I expected that most people would probably wait until the end of their 30-day trial.

Of course, we are getting a ton of email. People trying to get into their store account, people asking about "Will my zMUD files convert?" and stuff like that. A lot of questions are already answered in the CMUD Discount page and CMUD Information for zMUD users page, but it seems that a lot of people aren't bothering to read this stuff before just sending email. I think Chiara is going to start filtering my email and tell people to look at the FAQs before resending their question so that I can try to get more time to program and fix bugs.

Overall, it's going pretty well though. Chiara is filtering the "hate mail" from people who think they deserve a free copy or people who are just generally upset about CMUD. From the survey we did on this web site last year, I expected some complaints, and we are actually getting less than the survey suggested that we might.

Posted: Sat Nov 04, 2006 6:47 am

Today was a very long and frustrating day. I decided to work on some of the harder bugs that I've been avoiding. These are the bugs that deal with the window docking system and the toolbar system.

With the window docking, there is a bad bug where a "ghost form" can be left behind in some cases. For example, double-click the Untitled window to float it, then drag it back and dock it. Notice the floating ghost window that is left behind. These things end up causing crashes and can corrupt the saved layout files.

On the toolbar system, position the initial session window so that it overlaps part of the command line. Now close the session window and you'll see that the command line doesn't repaint properly. This seems like a trivial painting issue, but it turns out to be a worse bug that happens because the command line is being docked to a toolbar that is in a docked window rather than in the main parent window.

This kind of stuff is such a pain to work on. It's low level crap in 3rd party code. In the case of the ghost form, it was also related to the Theme Engine and how it intercepts window calls to draw themed borders. So that made it even worse.

With the command line painting, I traced the problem to a Windows API routine that didn't seem to be returning the correct value. The ChildWindowFromPointEx API routine is supposed to return the child window handle containing a given point. The child window, in this case, is a one-pixel dock control on the edges of the main MUD window that are supposed to be "hot spots" for drag/drop toolbar docking. Even though the point coordinates were within the dockcontrol, the windows routine wasn't returning the handle of the dock control for some reason. I have no idea why. But I wrote my own routine to look for a child control that contains a point and it seems to work now.

So now you can properly dock the command line to the top or bottom of any MUD window (docked or floating), or to the parent window. And the painting problem is also fixed.

After I fixed the ghost form bug, I also noticed that the task bar icon option wasn't showing in the system menu of floating MUD windows. I fixed this and also wrote some code so that the task bar icon is saved in the XLY layout file so that floating windows get restored properly with task bar icons when the session is loaded again. Took another hour to deal with some bad screen update flicker issues when the taskbar icon was toggled on and off (which causes the window to have to recreate itself). Really nasty stuff.

While I was working on the docking system, I also added the requested %autohide function. It takes the name of a window and returns whether or not the window is hidden or visible. You can also provide an optional value to set the window to hide or not-hide (if the window is set to autohide). You can also set it to -1, like

#CALL %autohide("tells",-1)

and it will display the tells window for a couple seconds, and then hide it again. This is also what happens now if you mark a window to be automatically brought to the front when it receives new text. So now you can autohide your chat windows and they will pop out when they receive new text (if you have this option set for the window). Keep in mind that each window has it's own "bring to front on activity" flag...it is no longer a global flag like it was in zMUD.

Tomorrow I'm going to focus on parser issues and hopefully get a new version released. Time for bed now.

Posted: Sat Nov 04, 2006 8:43 am

I know it was frustrating Zugg but it sounds like you made solid progress. You did stuff for the advanced users and the beginners as well.

It may be hard at this point, but try not to get burnt out and end the days a bit sooner. I know we're getting close to release date but I don't want see Chiara lock you out of the office again. At least not until a few days after the release. Very Happy