Zugg Software :: View topic

Posted: Wed May 28, 2008 9:23 pm

There are enough problems in the 2.25 version that I'm planning to release a 2.26 public version either this week or next week. Nothing too major and the 2.25 version is surviving the public usage better than many public versions. Still some crash dumps coming in that I want to look at, but the number of crash dumps is far less than the 2.18 version.

After 2.26 I am going to start working on the new mapper. I originally thought that I might rewrite it from scratch, but I have decided that this is a bad idea. Mainly because it involves both CMUD and zMapper/cMapper. Doing a complete rewrite would take a year, and that's longer than I want to spend on that. Trying to make a rewrite compatible with existing maps would also be hard.

So, I've decided to work with the mapper that we have and improve it and fix it. This can be done much more quickly and helps maintain better compatibility. I've broken the mapper work into multiple "phases". Here they are:

Phase 1 : Database

The first phase involves replacing the current Microsoft MDAC/ADO database with SQLite 3.0. In fact, at the same time I will be upgrading the existing SQLite 2.8 databases (the session database and packages) to also use v3.0. Fortunately, the mapper already uses MDAC/ADO via the normal Delphi database controls. So the initial conversion to the ZeosLib database controls is pretty straightforward. The biggest piece of work is changing the Room Properties dialog so that it isn't a "live" database editor window. This is similar to the Settings Editor rewrite in v2.20. The current Room Properties uses Delphi data-aware controls, which makes the property window slow and clunky. I will be replacing those with normal controls and accessing the database myself. I'll also be making the Room Properties dockable and adding a new dockable window that can be used to just display the room name/description in a dockable panel (like beneath the map panel)....kind of like a status window for the mapper. I'm guessing this database conversion will take about a month.

Phase 2 : Map Configuration

The second phase involves improving how the mapper is configured. This involves a rewrite of the configuration wizard, and improving how the mapper works with #TAG triggers (and MXP and ATCP). I will add the ability to specify text color when capturing room names, desc, exits, etc. I will also make it easier to specify #NODIR and #NOMAP text for novice users who don't know how to set up triggers. During this phase, I will also make a way to store the mapper configuration in a package and share it via the package library. The ability to share mapper configuration (*with* the necessary triggers, etc) will be a huge feature that I hope will bring a lot more people to CMUD.

Phase 3 : Graphical improvements

During this phase, I want to implement graphical tile-based maps, and generally improve the quality and speed of the graphics. I want to make it easier to create maps where rooms are adjacent instead of being blocks connected by lines. More like a standard D&D map, for example. I don't know if I'll be using DirectX yet or not, but I'll at least be using the faster G32 graphics library. That should give a good boost over the current drawing speed that just uses the Windows GDI (which is slow on Vista). Some zMapper features, such as user-defined room types will be brought over into the base CMUD mapper, and I'll also be playing with various room flags to try and make stuff like "speed-swimming" or "speed-flying" easier to implement.

At the same time as Phase 1, I will also try to release a new version of zMapper (probably called cMapper) that will allow the new map database to be edited offline. zMapper doesn't even compile within Delphi 2007 yet, so there will probably be several weeks after the Phase 1 CMUD beta before the new cMapper is ready. But since this is just an upgrade of zMapper and not a completely new rewrite or new product, it will still be a free upgrade for existing zMapper customers. But the new license for cMapper will probably limit future free upgrades to 2 years, just like with CMUD. And cMapper will still always have more advanced editing features than the mapper in CMUD...and hopefully cMapper will actually work and be released as a public version instead of the existing zMapper beta quality.

Sometime during this project I will also be working with MUDs and other developers to design a standard protocol for MUDs to send information to the client to enable better mapping, and even graphical tile-based maps. Several MUDs who currently have ASCII-based maps have expressed interest in this idea. My guess is that it will be an XML-like protocol, maybe based on MXP that will allow the MUD to draw graphical maps in CMUD and send other information such as room type. This will be an open protocol available to any MUD server or MUD client developer. My guess is that I won't start on active work on this until partway through Phase 2.

The new version of CMUD that contains the new mapper will be the v3.x series for CMUD. However, I probably won't change the license key for the first few beta versions of 3.x. I want to figure out a way to reward the "early adopters" of CMUD, especially those that purchased the 1.x versions within the first couple of months. So I'm still trying to determine exactly when the pay upgrade to v3.x will kick in. Probably not until the Fall sometime.

I expect all of this work on the mapper to take a while. The mapper is huge and very complex. The last time I rewrote the mapper in zMUD 6.x (and created the first zMapper), it took over a year. This time I have more to work with, but I still expect this project to take most of the remaining year.

As always, customer involvement and feedback will be a crucial part of this project. Please don't post your mapper ideas to this thread. Start NEW THREADS for your mapper suggestions and ideas. If you suggested something in the past, you can bump the topic if you want. Although remember that for the next couple of weeks I'll just be working on low-level database code so I won't be fixing anything really obvious to end-users yet.

So that's the plan. As usual, it's all subject to change. But that's my roadmap for the rest of the year at this time. I've put the MyMuds stuff on hold until after the mapper. I've also put the TeSSH and free CMUD client on hold until after the mapper (people who need SSH can just use CMUDPro instead of TeSSH for now, esp since TeSSH was just going to be a stripped-down version of CMUDPro). This deviates from my original New Year's Plan, but I've gotten the message from many people that the mapper is *very* important and that an improved mapper could help with CMUD adoption more than anything else. So yes, I *am* trying to listen ;)

Apprentice Joined: 26 Apr 2007 Posts: 113

As a thought, why not have the "early adopters" of Cmud (Those who bought Cmud early) full access to 3.x and all upgrades in the 3.x line before charging again for 4.x (Assuming we continue in this method) In my opinion, Cmud didn't really take off until around the 2.x beta stages to the point where enforcing the "two years of upgrades" deadline would be more of a slight to them, more than any who bought at a later time. In short: I think "date" deadlines favors those who bought later more than those who bought sooner, I'd much rather see customers happy enough to pay for a full version upgrade (i.e. 2.x to 3.x, etc.) than they would just because they chose an iffy time to buy Cmud.

Just my thoughts. :)

Posted: Fri May 30, 2008 11:44 am

I like the plan and I can hardly wait to start seeing the results.

Thanks for the high level overview.

Wanderer Joined: 22 Oct 2006 Posts: 92

Please correct me if I've mis-interpreted your post, but are you seriously suggesting that all teh people who paid for CMUS while it was a way buggy beta, will now be told to re-buy the still way buggy beta of a client that's so un-ready for prime time use that it still can't reliably be used without having to kludge one's pages and poses due to the over eager scripting, a client that can't make URLS clickable, one that's so broken that my copy can't even send bug reports because the bug report crashes?
Are you seriously telling me I paid for CMud up front to help you finance the writing of what could be the world's best client, if you stop believing that 100% of all users jsut spend their entire on-line experience running and writing scripts, nly to be told "Hey, well I'm not fixing any of the big, show stopping bugs but I will ask you to pay me again so I can continue to wonk around with a mapping application while you're still having to put ~ before any quotes in your page poses."?

Posted: Sat May 31, 2008 5:50 am

Without addressing any of the bug reports in your post (because only Zugg knows whether or not a bug is on the list and what priority he's given it - I hadn't heard about the URL bug, for example) I would just like to mention that you weren't given any misinformation when you decided to purchase CMUD. You were told it'd be two years, and two years it will be. When you chose to buy was entirely your decision.

Zugg did actually mention above that he felt a desire to reward early-adopters, but that he hadn't decided how he would do that yet.

Posted: Sat May 31, 2008 6:51 am

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

The vast majority of bugs that remain in CMUD are bugs the average user will never run into, or at most will be minor annoyances. Is color bleeding really that vital to your mudding experience? Some bugs that get reported are not really bugs with CMUD either (bad scripting for example). Then, no matter what, there will be issues with operating systems. Or problems that are a result of a bug in the component tools for CMUD where Zugg has to bug the developer of the tool to change things. Zugg does a great job of keeping us informed of what is vital to take care of, and when he fixes it. He said he is going to get one more beta taken care of before he begins work on these new features we've all been waiting on since CMUD was first announced, and even then he won't stop working on fixing bugs in CMUD.

I started using zMUD when it was in version 5. There were still plenty of bugs in it at that time. But many people used it. Why? Because the product did most of the job people wanted it to. CMUD is almost at that same point now. When my two years comes up, I'll be paying my renewal.

Thank you Zugg for the hard work and I can't wait to see the new mapper.

Adept Joined: 04 Feb 2005 Posts: 246

Well, I figure I might as well put in my perspective here.

I am still a 100% zMUD user. And a pretty satisfied one at that. Why? Two reasons:

1. zMUD is ROCK SOLID for me. I'm not saying it's bug-free, but I never crash, I never lock up (unless it's my fault for doing a trigger loop), I never lose settings. I never get corrupted settings. It performs excellently.

2. The cost of conversion is high. I have tons of settings, done using zMUD's inherited settings. It is a massive, many-hour effort to convert, even using the compatibility report. (The "%1" -> %1 conversions are a huge PITA.) I've had some abortive attempts at conversion, I think 2.18 was the last try. That was mostly successful, but ran into a lockup, so I gave up for the time.

The payoff of conversion, for me, is low. I'd find a few things great, like local variables, and Lua scripting, but that's about it. I'd probably stay away from multi-threading because I know just how hard MT programming is to get right. I still am on XP, and have no plans to upgrade, so that isn't an incentive. I have no problems with zMUD performance, so improved CMUD performance is not a consideration. I neither write scripts for anyone, nor do I use scripts written by anyone, so the modularity of packages has no incentive. (And isn't likely to, since I exclusively play MUSHes nowadays, and z/CMUD is not heavily used in the that community, who are much more into free clients--MUSHclient and simpleMU being probably the most popular.)

I like the mapper, but it is a pain to use on MUSHes. The free-form output (that can even change room by room), and non-cardinal direction exits (and even non-reversible exits, meaning you go west into a room, but maybe go north to reverse direction), along with no prompt string make auto-mapping a pain to get right, even with #TAGging everything by hand. And most MUSH grids are small anyways, so there's not a big win.

I bought CMUD in the pre-1.0 days, and I'd have to think hard about whether I'd upgrade if the timer ran out. And I'm someone who buys a lot of software, commercial and shareware. At this point, I would heavily lean to holding off until I felt I really had a desire to switch--a Vista upgrade, for example.

I can appreciate the payment model. It's probably hard to make a living at software these days. And it's getting harder. People are coming to expect that client software is "supposed" to be free, driven by the open software movement. And gamers... well, they aren't the richest in the world, nor the most generous.... So you have to offer them quite the incentive to keep paying, I think. CMUD's payment model is likely going to "string" out your users as they buy it once, then refuse to upgrade. I guess it remains to be seen how it will work out in practice and whether it will become a support headache.

I dunno exactly, because I'm not an ISV myself, but it seems like server software and services are where it's at for money nowadays--and definitely not the end user. It seems to me there'd be more money in supporting/developing MUD engines, and maybe making "custom" settings for MUDs (paid by the MUD--and if you support/develop the MUD server as well, making sure that all the fancy MXP/etc. works flawlessly too) so that CMUD is the "premiere" client for them, supporting advanced features.

Beginner Joined: 24 Mar 2007 Posts: 15

Weyll, I can't get 2.22 or 2.25 to install right now, so I'm glad I haven't really been MOOing lately anyway.

But eh. I would have a hard time paying for this app again with the usability problems I've encountered, even though I really like the app. The installer alone has given me too many problems that I've never encountered in another app.

We shall see. I don't want to be a random troll, as I said I like CMUD, but it's not getting much use. If it wasn't for the installer problems, I'd probably pay again later.

Posted: Tue Jun 03, 2008 4:30 pm

No problems with the installer have been reported. Please create a new thread explaining what the problem is, what you expect it to do (or not to do) and what it is doing (or not doing).

Beginner Joined: 24 Mar 2007 Posts: 15

I'd love to but it'll have to wait. Not doing much today except thinking. Downloading on dialup is too 'fun', and uninstalling and tweaking things to test doesn't sound like it'd make my day any brighter.

Might be next week before I can get to it. Honestly I'm not sure it's relevant to the installer at all, since it's only cmud.exe crashing, but it does it when it's trying to install the app too. Not really sure I ever had problems with the installer as such, but I have had cmud.exe crash on launch way too often.

Anyway, talk to you next week.

Beginner Joined: 24 Mar 2007 Posts: 15

OK! If I mark the app for DEP to ignore it it launches.

Progress. But still annoying.

Posted: Thu Jun 12, 2008 5:10 pm

DEP is really annoying. You should really set it to only monitor system files. Lots of applications are going to have trouble with DEP turned on. I can't believe Microsoft turned it on by default for some installations. I believe this was already listed in the CMUD Troubleshooting guide in the CMUD support area at the top of the web site though. Read that document for other ideas.

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Thu Jun 12, 2008 5:47 pm

Well, let's not sidetrack this thread onto Windows issues. I understand the "purpose" of DEP, but the reality is that in it's current implementation, it breaks a lot of software. It also interferes with a lot of copy protection systems, since the purpose of copy protection systems is to usually decode/decrypt the application and write data to the code area. That's why it causes zMUD/CMUD to crash (and any other application that uses Armadillo copy protection).

Beginner Joined: 24 Mar 2007 Posts: 15

Yeah I know it can be annoying and I did have it set to main windows services only. When I changed it to All and set it to ignore CMUD it worked suddenly.

The only other app I've had any problems with DEP is Steam, but even that didn't outright crash...just wasn't updating quite as well as it was supposed to.

I've never heard of Armadillo before, and it looks like I should be happy about that.

Beginner Joined: 24 Mar 2007 Posts: 15

Fortunately, I should have another year before I have to make that call anyway, and at least it is working now so I'm not as miffed.

I do think using DirectX would be a good investment especially considering it maps natively to the Vista DWM and will do likewise with Windows 7, even though it looks like G32 may be easier to work with from the extremely little I've read on the subject. (Looks like the little I've read is dated anyway.)

Later peeps.

Wizard Joined: 14 Oct 2000 Posts: 1368

Beginner Joined: 24 Mar 2007 Posts: 15

Well, considering it wasn't mentioned, I'm guessing he isn't thinking about OpenGL at all.

OpenGL has its pluses and minuses but I've not heard of too many people using it anymore that aren't considering multiplatform.

Seems like it's been mostly ignored lately.

Wizard Joined: 14 Oct 2000 Posts: 1368

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

I've coded with both DirectX and OpenGL. DirectX is a royal pain in the neck! OpenGL is much more straightforward.

Beginner Joined: 24 Mar 2007 Posts: 15

I imagine it depends how deep you get into them. Traditionally OGL is easier to use as a learner but they're about on equal footing otherwise, from the dev forums and other comparisons I've seen.

People love to argue that the only reason to use DX is marketing hype, but truly. If there's one thing MS is good at, it's giving you the information you need. That's why people tend to stick with them.

Anyway, we're not talking about games in this instance, we're talking about desktop apps, so this conversation isn't terribly useful. I don't know if I've ever seen a desktop app that uses OGL, and since the display code for a desktop app usually has a rather limited featureset, it's unlikely to be terribly difficult to get going right. (Not that I'm dismissing the effort involved, just as a comparison.)

I'll be using .NET 3.5/WPF myself when I get going on programming. Oldstyle COM stuff sounds like a pain in the arse.

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Wed Jun 18, 2008 4:46 pm

This thead is starting to get waaaay off track, so beware. Since neither CMUD nor the mapper need real-time 3D graphics, I don't have any plans to use either OpenGL or Direct3D. When I talk about "DirectX" I am talking about a larger package that includes stuff like DirectSound, DirectShow, and DirectDraw. Since CMUD already uses DirectSound and DirectShow for it's sound/MSP support, it's more natural to use DirectDraw to speed up some of the 2D map drawing.

But please don't sidetrack this thread with a DirectX vs OpenGL discussion. Thanks.

Wizard Joined: 14 Oct 2000 Posts: 1368