Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Yep. As soon as something is made idiot-proof the Universe produces a better idiot. It is much as Douglas Adams wrote, loosely quoted,

Beginner Joined: 09 Aug 2005 Posts: 17

Posted: Fri Jun 02, 2006 2:15 am

By the time "normal" CMUD users are ready to buy it, I'm sure there will be packages available for them. The Gurus aren't the only ones creating packages. Many of the beta testers will also create packages. And I'm not expecting the shared packages to drive the sales. I'm expecting *all* of the features in CMUD to drive sales. Shared packages are just one of the many features.

The people that will be buying CMUD early are the people who want to start creating packages, and the people who want to support CMUD in general. So, I am pretty sure it will all happen naturally. The excited early adopters will buy it and start making packages. By the time it's stable enough for a public release, there should be plenty of stuff in the package library to attract normal users.

"Normal" users should not be using the CMUD beta in most cases.

The purpose of the Beta testing is to help me find the bugs. People who are just looking to play MUDs and download shared scripts are not the type that should be using the beta. The Beta Test Agreement that you'll have to read before downloading it should make this clear.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I know for a fact that my scripts have caused several people to buy zMUD. I intend to make several shared packages for CMUD, but it will take a while to learn the new system and the packages might be better off waiting for the final release, after the addition of the package GUI code and other similar features.

Posted: Fri Jun 02, 2006 4:18 am

Today was a good long and productive day. First, I finished up some loose ends in the editor. When adding the ANSI color support, I had forgotten to handle the Copy/Paste commands. Those work now, so you can copy text from the MUD window and paste it into the editor, preserving the ANSI color, just like in zMUD. Of course, the HTML support in the editor also allows copy/paste of HTML as well. Eventually this should support MXP, but right now the editor just supports normal HTML.

Then I worked a long time on the integration of the package library. The package library was written a few months ago as a separate module, and today I integrated it with the rest of CMUD. When viewing a package in the settings editor, you can click a button to add the package to the package library, or to view/edit the entry in the package library.

One difficulty came when putting the real XML package data onto the server. The original module just used some test data. In this integration process, it was time to send the real XML data from the package to the server. Well, I ran into a 64k data limit.

First, I thought the limit might be coming from the Indy POST routines. I had read about a 48k limit when using the default url-encode content type. I found some routines in Delphi to support full multi-part POST commands, and added that, but it didn't help with the data truncation. Finally, I looked on the server side and found the MySQL has a 64k limit to it's TEXT field types. They added field types called MEDIUMTEXT and LARGETEXT with different limits. I choose the MEDIUMTEXT limit, which allows the XML text to be up to 16MB, which should be plenty large. I decided against the LARGETEXT because someone abusing the system could easily fill up the server hard disk and crash it.

Took a while to find this...I didn't expect the database to have this kind of limit.

Once the server was storing the XML data for the package, it was time to integrate the package download system to create actual *.pkg database files. Fortunately, I had already written the XML import and export routines for the package system. They are used a lot in CMUD. For example, whenever you Copy/Paste settings (triggers, aliases, etc) in the package editor, the data transfer is done via XML. In fact, you can select a bunch of stuff in the settings editor, select Copy and then go over to Notepad and do a Paste to see the XML. Then, you can take the XML from Notepad (or any other source), copy it, and paste it into the settings editor to create/modify the settings. It works really well.

This existing code made it easy to download the XML stored on the server and create the *.pkg package database file.

I've set it up so that you can easily edit your own package and upload the changes to the server. When you download and install a package, it defaults to "readonly" mode, which means that changes to the package are not written to disk. In the settings editor you can turn off the read-only flag to modify a package, but unless you make your own copy of the package, any changes you make will be overwritten when you update the package from the server.

Each package has a unique ID on the server, and each package is associated with an Author. Only the author of a package (or a moderator/guru) can modify a package and upload an update to the server.

All of this seems to be working nicely now. I'm sure there will be improvements to the interface based upon feedback during the beta process. But it's already pretty easy to create a package, upload it to the server, update it, download it, etc.

So, except for the detour to figure out the data limit on MySQL, everything went pretty smoothly. Tomorrow I'll be implementing a bunch of little stuff, and also replacing the sound routines with the new DirectSound and DirectShow routines that I wrote a couple of months ago. This will remove the DWSW32.DLL stuff that is used in zMUD. Not only does this improve the sound functionality, but it gets rid of the really slow sound initialization startup that zMUD had. Should be another day of lots of little quick and easy tasks.

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

Will CMud have the ability to have its own internal volume control? It would be nice so that you could have iTunes cranking out some music and CMud sound triggers softer, but still noticable under the music.

Posted: Fri Jun 02, 2006 6:23 am

Possibly in the future. Unlike zMUD, CMUD won't be messing with the master volume. So the CMUD sound system won't mess up any other programs that are using the sound card. That's one of the advantages of using the DirectSound API. The MSP support already allows you to assign different volumes to different sounds. So, it will just be a matter of adding a user interface control for the sound system. This should be easy, but I don't want to add more features right now until the beta is released.

Posted: Sat Jun 03, 2006 3:40 am

Another long day, although not as productive as I hoped. The DirectX sound routines that I wrote a couple of months were fine for basic sound playing. But when I tried to integrate it into the CMUD MSP code, I ran in a few glitches.

In MSP, there is an option to loop a sound and play it a specific number of times. This is actually used a lot on various MUDs. Well, the normal DirectSound routines for playing WAV files don't seem to have any event or callback to tell you when a sound is done playing. So I couldn't find any way to loop a sound.

The newer DirectShow interface *does* have events to handle this. However, for WAV file playing, DirectSound is more efficient (memory and speed) than DirectShow. For example, when playing a single WAV file more than once, DirectSound just stores a single copy of the WAV data but has multiple pointers into it. With DirectShow you use something called a FilterGraph, and if you want to play the same sound while a previous copy is still playing, you have to allocate a completely new filter and reload the sound into memory again.

What I ended up doing was putting together a class that gives me the best of both. If you play a WAV file, it starts by using DirectSound. However, if you try to use the "loop" argument to play the sound multiple times, then the class automatically switches to using the DirectShow interface. For non-wav files, such as MP3, MIDI, etc, the DirectShow interface is always used.

CMUD keeps a buffer of sounds in memory. However, it currently doesn't check the total buffer size, it only checks the number of buffers. Right now, 32 sounds can be kept buffered in memory at the same time. However, if these 32 sounds are all big MP3 files, then it takes a lot more memory than if they are simple WAV files. I'll probably improve this in the future to make it a bit smarter.

In any case, it all seems to work now. In CMUD, you can play up to 32 sounds of any kind at the same time. For example, you can play multiple MP3 files, along with multiple WAV sounds, along with multiple MIDI backgrounds, all with their own volume and panning controls. This is a big step forward from zMUD, which could only play up to 8 WAV files at a time, and could only play uncompressed 8-bit WAV files. zMUD couldn't play multiple MIDI files at the same time, and it didn't support MP3 at all. So the sound support in CMUD should help move MSP forward.

All of this requires DirectX 9 to be installed. I still need to write some code to detect what version of DirectX you are using. The DirectSound support for just WAV files exists in older DirectX...only DirectShow requires version 9. But I'm not going to worry about this for the first beta release. Most people who run Windows XP should be keeping it up to date, which means they should already have DirectX 9 on their system.

Can't believe it took all day to get this working. As usual, my ability to estimate the time to program something and get it all working is horrible. Then again, it was good positive forward motion. Tomorrow I'll be implementing a bunch of miscellaneous commands and functions that we've talked about in the forums. Stuff like #NEWVAR, %pref, %vartype, etc. All of the routines for these commands and functions already exist in the new parser, so it's just a matter of running the COMEDIT program to add the commands and function names to the database and then tie the code together. This will clean up a lot of the loose ends in the new parser and compiler.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Just wondering - I haven't used the DirectSound API at all - but could you create a thread and play the sound in 'blocking' mode, so the thread returns when the sound has finished playing, therefore generating your required event to know when to start looping?

I know when I've been playing with the sound interface on the PocketPC devices that's what I do - since I string together samples for example "go.wav" "to.wav" "location.wav" "alpha.wav" "three.wav" "five.wav" so have to know when they finish playing so I can queue the next one.

Posted: Sat Jun 03, 2006 4:11 pm

Yes, that's a possibility. The Play API method for DirectSound does have an argument to decide whether to wait on the sound or not, so putting this in a thread should work. Of course, there's all of the thread issues to deal with, but it might be worth a try later during the beta period. Thanks for the suggestion.

Posted: Sun Jun 04, 2006 2:19 am

I know your pain Zugg. I really hate when I've got a project I think will take a day, and a week later it's not done yet... Though this week was a good one, something I thought would take a month was done in two days!

Posted: Sun Jun 04, 2006 3:16 am

Wow, another long but productive day. Although I ended up fixing a bunch of stuff that wasn't on my list.

First, I started with some quick and easy stuff. I added the "Published" option to classes. It is enabled by default, which means that other packages can "see" inside of the class. If you uncheck this option, your class becomes "private" and other packages can't see any of the aliases, variables, etc within the class. Then I added the "Stop Processing" option to triggers. When set, this option will stop other triggers in the same package from firing if the trigger matches. (I think it was RainChild that requested that one).

In the process of testing these options, I ran into some wierd bugs that took a few hours to fix. It turns out that the kbmMemTable memory database component wasn't properly maintaining the current record when added a new record to the database. After "posting" a new record, it calls an AfterPost event, and in this event I link the new database record with the proper record in the linked-list of settings. However, in some cases, the current record wasn't being set after the Post, so in my AfterPost event, it was modifying the fields of some other record in the database! Not good...it caused all sorts of wierd crashes because the linked list and the internal database were no longer "in synch".

This turned out to be a bug in the kbmMemTable component. I added a line to set the correct record number after an Append operation, and that fixed the problem.

However, then I discovered a new problem: settings were not being created in the correct package. In zMUD, there was basically just one "package" in memory. Using a command like "#CLASS 0" you could set the current class to the top level. Essentially, this set an internal variable called DefaultClass to zero.

But in CMUD there can be multiple packages in memory. Class zero is the first package record loaded into memory. So whenever I did #CLASS 0 it would then create new settings in the first package (the Default.pkg default package). This was bad. I needed to modify everywhere that used #CLASS 0 to change it to set the DefaultClass variable to the DefaultPackage instead of zero. DefaultPackage points to the current package. When executing something from the command line, the DefaultPackage is the package associated with the current MUD window. When executing a triggers, alias, macro, etc, the DefaultPackage is set to the package that contains the trigger, alias, etc.

This also required "fixing" the syntax of /varname. This is supposed to refer to a variable in the "root" class. In zMUD, the root class was class zero. But in CMUD I needed to change this so that it refers to the DefaultPackage value.

Lots of little details that needed fixing. This is the kind of stuff I'm sure we will see more of during the initial beta period. There is a lot of subtle complexity from having multiple packages in memory. But at least it works a lot better than it did before.

Once that was done, I was able to implement the #NEWVAR command, which was pretty trivial. As discussed, it creates a variable in the current class without looking for the variable in any other class. This worked fine.

Then I added the argument list field to the settings editor for aliases. This allows you to edit the named parameters for an alias (or variable) after it's defined. But when I started testing this, I located a bunch of bugs in the parameter and local variable handling. I don't know what happened to cause these bugs. I had already tested this stuff a few weeks ago and it worked fine. But some other change broke it. I hate it when that happens...it means my design isn't as stable as it should be. The parser is tricky to work on...changing one thing can have lots of side effects.

In the process of fixing the handling of parameters and local variables, I also ran into another parser bug. When you referenced a function with no parameters, it worked if you used %function() but not if you just used %function. Actually, it only failed if this was followed immediately by another function call. Yeah, pretty obscure. That's why I hate working on the parser. The YACC parser typically looks ahead by one token, but sometimes it also causes the code for the lookahead node to be executed when it shouldn't be. It can be really tricky to get it all right.

OK, so once those parser problems were fixed, I then implemented the new %numparam, %param, and %params functions. The first two are just like in zMUD. The new %params function expands to the specified parameter along with all parameters after it. So, %params(1) is like the old %-1 syntax. The %-1 syntax is still supported. The big change in %param and %params is that they both accept *named* parameters. So, you can do something like this:

Posted: Tue Jun 06, 2006 4:24 am

Today was another productive day. It would take too much space to post all of the details. I got about 20 different items off my to-do list. Which means I was well below the expected one hour per item estimate! Found and fixed another pretty major bug in the DevExpress menu system. When saving/loading the toolbar to a file, it was referencing the toolbar by *number* instead of name. This caused all sorts of problems as each MUD window can add it's own toolbar, and loading a saved toolbar file could end up messing up existing toolbars. I changed this to reference toolbars by name and now it works great.

The Global Settings were finally removed. CMUD doesn't need the GLOBAL.MUD stuff because you can just do the same thing better using packages. In fact, the entire global toolbar has been replaced by a standard toolbar that can be customized, saved, loaded, just like any other menu or toolbar in the system.

I also tested nested menus and trigger conditions and fixed a couple of issues relating to that. They now seem to work, although I wouldn't be surprised if there are still some problems that I haven't found. In any case, it's a lot easier to make menu items now. And you can either tell CMUD to add the menu item to the normal right-click menu, or you can just drag them onto any other toolbar or menu that you want.

Tomorrow I need to go through and make sure CMUD doesn't use any existing zMUD files. I want CMUD and zMUD to coexist in the same directory. Right now, for example, CMUD uses the same mudlist.db file as zMUD. This will change as I want to add some of the new fields from the MUD Connector like MXP and MSP flags for the mud list. The MUD Connector has already set up a new XML feed for CMUD, so I just need to recode some URLs to use it and parse the new XML fields.

My current estimate is that a first beta release next Monday is looking *very* possible! It will depend upon how long it takes to get the new CMUD discount system added to the online store later in the week.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Wow, awesome :D

Though monday's bad for me... its long weekend here so I'm not going to be around to download it til tuesday *sulk* a whole day! I'll be branded as a 'late adopter' for life...

:)

Posted: Tue Jun 06, 2006 5:24 am

Don't worry Rainchild I'll download it twice to make up for that. I can't wait to get my hands on it.

I think first I'll just do general MUDding on it just to enjoy the spiffy new GUI. Then I'll try importing my old settings and triggers... Then I'll really go to work. Imagine the power and grace of CMUD!!!!!

Twisted Evil

Posted: Wed Jun 07, 2006 4:54 am

Well, the work continues. Today, instead of working on making the CMUD files separate from the zMUD files, I decided instead to work on finishing the crash report system. Remember that I found something called madExcept which performs exception handling in Delphi and does a nice job creating stack dumps with source code line numbers.

Well, I had tested madExcept using their email system, which would send me an email message containing the bug report. But I decided that I didn't want to receive emails for all of this. I'd rather have the crash dumps sent to my online bug tracking system (not the Mantis system, but HelpSpot which I'm currently evaluating).

Also, I wanted to implement the "Send bug report" button to the script compile error screen. This screen is displayed when there is a problem executing a script. As discussed in one of the beta forum threads, I wanted to make it easy for people to send me their scripts that didn't compile. Seemed natural to just try and call the madExcept stuff to use their same mechanism for sending a bug report.

This turned out to be time consuming. Their documentation was pretty poor. They had options for HTTP sending, but no documentation on what fields and stuff were actually sent in the HTTP request. Also, since the SendBug routine doesn't display a web page or show any results, I couldn't even see what the web server script was returning. I ended up having to write a PHP test script that wrote all of the $POST parameters to a log file so that I could see what madExcept was sending.

Well, they were sending the full bug report as a file attachment! That wasn't very nice. I don't want to enable file uploading. So I had to dig into the guts of madExcept to figure out how to add custom HTTP fields. I finally found their poorly documented hooks for this. Finally I got the basic crash dump sending to work with our server.

Then, when I tried to use the madExcept system for the compiler error, I ran into other difficulties trying to get it to just send the bug report (while still prompting the user for their name and email address) without actually showing an exception error message. *Finally* I got this all working. madExcept is very powerful and I haven't had to modify their source code...they have lots of hooks. But it's documented for Geeks. It's a typical case of documentation written by the programmer who already knows how it all works and assumes everyone else can figure it out. Took a while.

Anyway, it's now working and integrated with the HelpSpot system. If I have the time I want to further optimize this so that additional reports of the same bug just get appended to a single bug report. The madExcept system has a CRC value that is unique to the error message and location of the error. So multiple reports of the same bug have the same CRC value. I could use this when creating new help request tickets to append to an existing ticket to prevent from being flooded by tons of bug reports about the same issue.

Ultimately, in a future beta version, I'd also like to be able to return information from the server that could be displayed. For example, if someone is using an older version and a bug is already fixed, the system could return a message telling the user that the bug they reported is already fixed in a new version. I think all of the hooks are available for this, but it's not something I'm going to hold up the first beta for.

Still looking good for Monday!

Posted: Wed Jun 07, 2006 6:29 am

Sounds like a solid productive day. And with the CRC check it should make error handling a lot more efficient. It's so simple and brilliant I'm surprised other clients don't work like that.

Looking forward to Monday. And as a reminder, your hard work is truly appreciated.

Posted: Wed Jun 07, 2006 1:46 pm

I just hope that Zugg's servers can handle the hordes wanting to beta test CMUD. I started mudding again, and I really want to use CMUD for my new adventures. Razz

Beginner Joined: 09 Aug 2005 Posts: 17

Posted: Wed Jun 07, 2006 5:25 pm

I already evaluated FogBugz extensively. I decided on HelpSpot instead because HelpSpot handles the day-to-day help desk system a bit better, and I liked the interface better. Also, the author of HelpSpot has incredibly fast and useful support. Adding the small amount of my own PHP code to integrate the madExcept bug reports with HelpSpot has been really easy. HelpSpot is also a bit easier to integrate into the look/feel of our site and has better email integration. For example, I can redirect all support email through HelpSpot and Chiara can do all of her support work in HelpSpot instead of Outlook with better features for performing her customer support tasks.

It was a close call...FogBugz is certainly a good program and I'm a fan of Joel's stuff. But the extra little details of HelpSpot and Ian's fast customer support ended up winning me over, even though HelpSpot ends up being a bit more expensive.

Posted: Thu Jun 08, 2006 5:28 am

Getting closer and closer!

I've got CMUD using all of it's own files now (well, I think I do...I won't know for sure till I do the installer tomorrow). I also got the new MUD Connector code in. The MUD Connector data is now downloaded in XML format, and it also contains MXP and MSP flags. You can filter MUDs by MXP, MSP or both in the MUD listing.

I also did some clean up with the preferences. Some preferences require updates to other parts of the program. For example, if you change the input font name, the actual command line needs to be updated with the new font name. So I had to add a routine to the Save Preference database routine that would perform these other tasks when a preference is changed. In the past I did all of this when you clicked OK or Apply in the Prefs editor. But now that we have a %pref function, a preference can be changed at any time, so I needed something better. In fact, since it's a database that is always saved, the Prefs editor no longer has an OK, Cancel, and Apply button...just an OK button since the changes are made immediately when you click on an option checkbox.

Then I started setting up the Armadillo copy protection stuff for CMUD. I was really worried for a while. When I first tried it, CMUD completely crashed. I finally discovered that there is an incompatibility between the madExcept exception handler and the Armadillo wrapper. This really annoyed me. It is caused by the fact that madExcept attaches some debug information to the EXE file to allow it to perform the stack dumps that I wanted. I was worried that I wouldn't be able to use this nice crash reporting system.

Fortunately, after playing with the madExcept and Armadillo options, I came across some settings that seem to work. We'll see if there are any problems during the beta testing on other computers, but it seems to work on my computers here.

I also got the code working that requires you to be registered in order to use the shared package library. Using a feature in Armadillo called Secure Sections, it's set up so that if you don't have a valid license, the code for part of the package library is never decoded and never loaded into memory. So that will make it very difficult to hack...you can't just jump around some license check...the code needed just isn't even there. The only side effect of this is that the first time you enter your license key, you need to restart CMUD in order to use the protected features of the package library. But it gives you a nice message about this if you forget. So I think it will be fine.

Tomorrow I actually get to write the installer script! That's pretty exciting! I also get to start working on the discount offer code in the online store to handle the free and discounted CMUD copies for qualified zMUD users.

Monday is still looking really good!

Posted: Thu Jun 08, 2006 5:42 am

Will you add a Reestart CMUD now, option to the notification that it requires a restart? similar to the way windows update does?

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Discount schmishcount, I'm buying a full price copy! Giiive to Radiskull!!! Very Happy

It is exciting that you're up to playing with the installer - means that the hard part is all done Smile

Posted: Thu Jun 08, 2006 8:10 am

Shalimar: No. You get the warning in the middle of the package library. There is no easy way to restart CMUD at that point. For example, the package library doesn't even know if you are logged into a MUD or not. And it's only an issue the very first time you enter your license key if you try to download or submit something to the library. So it's not worth putting a lot of work into that.

Rainchild: That's what I like to hear! I hope lots of people do that Very Happy

Enchanter Joined: 10 Oct 2000 Posts: 698

I'm buying several full price copies. Twisted Evil

In fact, I think the full price beta should be available for several days[really weeks] before any discount is available! Twisted Evil

Sweetness! Pure sweetness! I can't wait.