Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum Goto page 1, 2  Next
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed May 28, 2008 9:23 pm   

Next CMUD version and mapper plans
 
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 ;)


Last edited by Zugg on Thu May 06, 2010 5:32 pm; edited 1 time in total
Reply with quote
Asilient_1
Apprentice


Joined: 26 Apr 2007
Posts: 113

PostPosted: Wed May 28, 2008 9:42 pm   
 
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. :)
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: 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.
Reply with quote
cuprohastes
Wanderer


Joined: 22 Oct 2006
Posts: 92

PostPosted: Fri May 30, 2008 5:32 pm   
 
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."?
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Sat May 31, 2008 6:51 am   
 
cuprohastes wrote:
... 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, ...


URLs are quite clickable in CMUD. You just have to create a script for it. And if your MUD doesn't support MXP, it's not going to be easy at all to make URLs clickable in the first place. Why? Because URLs are not always in proper formats on MUDs. For instance, most of the URLs I've seen consist of just blah.blahblah.com instead of http://www.blahblah.com.

As for a "still way buggy beta that's so un-ready for prime time use," I think you're quite mistaken. CMUD is pretty stable in it's current version. Zugg wasn't going to release it without a majority of the bugs fixed that people who actively tested the betas reported. If you didn't actively report any bugs that you had during beta stages, then you have no say in what bugs should be fixed and whatnot. I know I've reported several bugs that were fixed. So have several others. Zugg can't do all the testing himself - that's why he asks us to help him.

All in all, I'm glad I paid for CMUD, and if asked to pay again, I will. I'm not expecting everything to be perfect when I have to pay the next time around, but I know that because I participated, it will be a better client.

Thank you, Zugg. And I can't wait for the Mapper to be rewritten! No more having to wait 30 seconds for CMUD to load my maps. :P

Charneus
Reply with quote
Dumas
Enchanter


Joined: 11 Feb 2003
Posts: 511
Location: USA

PostPosted: Sat May 31, 2008 1:29 pm   
 
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.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Mon Jun 02, 2008 2:21 pm   
 
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.
Reply with quote
Standoff
Beginner


Joined: 24 Mar 2007
Posts: 15

PostPosted: Tue Jun 03, 2008 4:08 pm   
 
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.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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).
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Standoff
Beginner


Joined: 24 Mar 2007
Posts: 15

PostPosted: Fri Jun 06, 2008 5:36 pm   
 
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.
Reply with quote
Standoff
Beginner


Joined: 24 Mar 2007
Posts: 15

PostPosted: Thu Jun 12, 2008 12:12 pm   
 
OK! If I mark the app for DEP to ignore it it launches.

Progress. But still annoying.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Thu Jun 12, 2008 5:21 pm   
 
Zugg wrote:
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.

Actually DEP is quite nice feature. As I remember it applications that need to execute code need to mark that memory page as executable. After that it should work. By preventing executing "code" in ordinary memory areas you very effectively block stack overflow exploits that work by overwriting the return address of the current active procedure. I think the method is to cause upon return of procedure the instruction pointer instead jumps into the overwritten stack data that happen to contain whatever exploitive code that was injected. So "fake code" in the stack get executed but with DEP turned on the memory of the stack would not be allowed to execute.

I think most applications won't need to execute data in buffers, and if they do need it they should first tell Windows.

Edit: You might want to consider why DEP should be active for all applications and not only system applications. Say there is a buffer overflow issue in MXP in cMUD. Then a hacker might be able to cause the overflow to run malicious code in cMUD even though it is no server application. Atleast that is my opinion Smile.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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).
Reply with quote
Standoff
Beginner


Joined: 24 Mar 2007
Posts: 15

PostPosted: Fri Jun 13, 2008 5:28 am   
 
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.
Reply with quote
Standoff
Beginner


Joined: 24 Mar 2007
Posts: 15

PostPosted: Fri Jun 13, 2008 1:50 pm   
 
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.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Fri Jun 13, 2008 4:05 pm   
 
Standoff wrote:

I do think using DirectX would be a good investment

Personally I prefer to use OpenGL Smile. Using OpenGL it is very easy to draw.
Reply with quote
Standoff
Beginner


Joined: 24 Mar 2007
Posts: 15

PostPosted: Wed Jun 18, 2008 4:09 am   
 
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.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Wed Jun 18, 2008 9:57 am   
 
Standoff wrote:
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.

DirectX is used a lot in gaming. However there are games that use OpenGL like the Quake series. So it is definitely a good API. Many games also have OpenGL support implemented but still use DirectX. I think World of Warcraft support both APIs. Same with Unreal Tournament.

I think the reason a lot of companies end up using Direct3D is that they get the road open to easily move to xbox Mad. Though just because a lot of people use a certain technology does not mean it is good. It means they have fallen for marketing hype.

Well anyway the most important thing to know regardless of API is some graphics theory. Knowing that makes it a lot easier to use both.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Wed Jun 18, 2008 10:59 am   
 
I've coded with both DirectX and OpenGL. DirectX is a royal pain in the neck! OpenGL is much more straightforward.
Reply with quote
Standoff
Beginner


Joined: 24 Mar 2007
Posts: 15

PostPosted: Wed Jun 18, 2008 3:56 pm   
 
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.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Wed Jun 18, 2008 4:39 pm   
 
Standoff wrote:

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.)

Anim8or uses OGL(www.anim8or.com). Of course that is a 3D modeling tool but it is still a "desktop app".

Microsoft also makes opengl information available, but you can also find information at the OpenGL reference page at http://www.opengl.org/sdk/docs/man/. There is also the "red book" which an older version of is available online: http://www.glprogramming.com/red/
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Wed Jun 18, 2008 5:28 pm   
 
Zugg wrote:
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.

I think DirectDraw has been removed from the newer versions of DirectX. Instead you would use Direct3D but I am not sure exactly what support they have put to aid 2D drawing there.

Anyway. I look forward to standard specifications how mapping should be handled on MUDs. Personally I hope for an upgrade to MXP. To me it feels like exactly the kind of thing MXP should be used for, especially considering many MUDs/clients probably already have the basics to parse it. Will the standardization discussions occur here on the developer forum?
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net