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

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
Fang Xianfu
GURU


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

PostPosted: Mon Jan 15, 2007 10:34 pm   

New Years' Questions
 
Zugg wrote:
SSH Support

Will this allow simultaneous connections to different sessions with different SSH settings? I know some people play MUDs that allow SSH and those that don't at the same time.

Zugg wrote:
zApp Scriptable Forms

Is this what you meant by scriptable GUI front-end type things for CMUD a while ago? It'd be nice to see a tech demo of this when it's created, I'd like to see just how powerful it can be :)
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Mon Jan 15, 2007 10:47 pm   Re: New Years' Questions
 
Fang Xianfu wrote:

Is this what you meant by scriptable GUI front-end type things for CMUD a while ago? It'd be nice to see a tech demo of this when it's created, I'd like to see just how powerful it can be :)

What disappoints me a bit here is that a part of me feels that OpenGL would be nice to use in cMUD. If cMUD doesnt support plugins it would be hard to use OpenGL in it as I doubt zApp forms would support it.

On the other hand the lazy part of me says that I am too lazy to try make a 3D mapper anyway :P.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Jan 15, 2007 10:54 pm   
 
Yes to both :)

With SSH, it will be implemented on the socket level, so each connection can have different settings. I'll be using a 3rd party set of SSH components called Secure Black Box. Most of my effort will be in learning about SSH myself and what all of the options and terminology mean. I'll try to implement all of the features provided by the 3rd party component. These components also implement the SFTP stuff, which is why I didn't port the #FTP stuff from zMUD (I knew I'd just need to rewrite it again). But since I've never used SSH myself, it will take a while for me to learn how it works...there's a *lot* of security jargon to learn.

For the TeSSH standalone client, I simply need to add a bunch of conditional compilation stuff so that when TeSSH is compiled, it doesn't link the stuff like the mapper, etc. There is also a bit of code that needs to change depending upon this conditional compilation (for example, when compiled as TeSSH, the "MUD Connector" tab won't show, and the "My MUDs" gets changed to "My Sessions"). None of this should be very complicated. Most of the work will be involved in getting the 3rd party SSH socket components to work and to provide the user interface for setting all of the necessary SSH options.

For the zApp stuff, you can head over to the zApp Area of this web site. You will see a bunch of sample zApp applications along the left column. Click on one of those applications, and then there will be a link to see the ZML source code. That will give you an idea of what zApp looks like.

The difference between zApp and what CMUD will implement is that in addition to using "normal" scripting languages, you will also be able to use zScript itself. Also, I haven't yet decided whether I'll make *all* of the visual components available, or just some of them. It kind of depends upon how big the CMUD EXE file gets. CMUD already uses many of the zApp components, so, in theory, it shouldn't add much to the size of CMUD. But I don't want to promise anything yet. I also haven't decided which of the zApp libraries to make available. These are COM libraries of functions, many of which overlap existing zScript functions.

Once zApp is added to CMUD, then I'll need to decide how to implement the MXP hooks. To begin with, you'll just be able to enter ZML code for a "Window" object in CMUD. There will be a new tab in the settings editor for a "Window" where you will be able to enter your own ZML code to define the window widgets and scripts. But deciding what to allow the MUD to send via MXP is a separate issue and something I need to think more about. There will definitely be plenty of time to provide feedback and ideas on this when I get into the development.

Right now I'm still trying to decide what to work on first. My first priority for the next week or two is writing more documentation and getting the CMUD help files in better shape. Then I will work on either the SSH stuff or the zApp stuff. I'm leaning towards doing the SSH stuff first just because it could provide some increased sales from buying the SSH plugin or buying TeSSH.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Jan 15, 2007 10:57 pm   
 
Rorso: Since zApp supports *any* ActiveX object, you should be able to do almost anything you want within a zApp Window object. This is the main reason why I haven't done the plugin interface for CMUD yet...using the zApp stuff opens up so many new possibilities that I wanted to re-think the entire plugin concept and make sure it got implemented correctly in CMUD, rather than just porting the limited zMUD plugin stuff. Although to make an OpenGL mapping plugin, you'd certainly need to have zMapper/CMapper installed in order to get the COM API access to the mapper objects.
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Wed Jan 17, 2007 3:10 pm   
 
Does zApp have a future? Wink
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Jan 17, 2007 5:50 pm   
 
Honestly, zApp hasn't changed much at all. I'm really using the existing zApp stuff in CMUD with very few changes. I'm certainly not going to spend any time on the zApp IDE or anything like that. So any changes to the existing zApp will be pretty minor, and probably just bug fixes. But I don't know if I can justify taking time to make a real release for a product that isn't selling anything. Releasing a new zApp is more than just compiling...I'd need to spend a lot more time to ensure that the changes added from CMUD haven't screwed up anything else in zApp. Then I have to test all of the demo apps again. Then I have to document the changes.

I guess the bottom line is that I feel that zApp is already a perfectly good product. I'm using its code in CMUD and have not needed to make very many changes to it. In fact, I still use some small zApp programs myself for doing stuff like database management. For example, whenever I need to look inside a CMUD *.pkg SQLite database file, I'm using a zApp program to do it. I'll be using more of the zApp code when I enable the zApp form support within CMUD and make the various zApp libraries available. After I do that, then I'll have more of an idea whether or not I should release a new version of zApp itself.

But the fact that nobody has bought zApp in many months means that it's pretty dead as a business product. Maybe someday somebody will "discover" zApp and it will start selling, but I doubt it. But that doesn't mean that it isn't very useful in it's current form. I still offer it for sale on this site because I think it still works fine for what it was designed for.
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Wed Jan 17, 2007 7:33 pm   
 
I perfectly understand but I couldn't resist asking (being the beginning of a new year and all). Wink
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Wed Jan 17, 2007 8:05 pm   
 
I wanted to add that I totally agree with you. zApp is good on its own for small utility apps. I had some very ambitious plans for zApp but I think we needed more on board who did.

Also, take consolation in the fact that you made a excellent decision on focusing on Zuggsoft's core strength. I have found that it is not enough to write good quality software and put it out there if it isn't something others know about and want (or need). In addition, in the shareware world there is much competition. I had closed down my one web site that was selling two products I wrote. I got a few sales but I decided to start from scratch with a different angle. Basically, I am learning from my first endeavor.

Take care.
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Wed Jan 17, 2007 10:35 pm   
 
Btw, Zugg, I just had a thought. I think a working mapper for CMUD should be a higher priority than third on the list - the mapper was one of the most-used features of zMUD and I've seen lots of threads and spoken to lots of people who wish the mapper was working properly. I think there's more demand for a nice mapper than there is for SSH, and it fits with the theme of your New Years' Message, sticking to Zuggsoft's best weapons :)
_________________
Rorso's syntax colouriser.

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


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Wed Jan 17, 2007 10:49 pm   
 
Fang Xianfu wrote:
Btw, Zugg, I just had a thought. I think a working mapper for CMUD should be a higher priority than third on the list - the mapper was one of the most-used features of zMUD and I've seen lots of threads and spoken to lots of people who wish the mapper was working properly. I think there's more demand for a nice mapper than there is for SSH, and it fits with the theme of your New Years' Message, sticking to Zuggsoft's best weapons :)

Maybe it is time for a poll? :). A few years ago Zugg used to run polls to determine what to work on. I suspect as well that there are more people who want a better mapper than SSH support. Then again we can't know for sure, probably not even with a poll :P.
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Jan 17, 2007 11:14 pm   
 
Well, I already mentioned in my New Year's letter that the features are not given in any particular order. It is *not* the order in which I plan to work on stuff.

I have several reasons why I'm considering SSH first. One reason is that it will increase our sales, and that is still very important. Also, I know that the TeSSH client will take a while to get "discovered" so the sooner I can release it, the better. The more sales I can get, the less stress that I will have and the better everything else will be.

Another reason is that SSH will be the first real module that needs the new plugin system, or some form of "CMUD Pro" licensing. And I want to get all of this stuff worked out before I work on other, more complicated, plugins, like the mapper.

Also, rewriting the mapper is actually a huge job that could take several months. And not only do I need to rewrite the mapper within CMUD, but then I will need to write a new version of zMapper that supports the new SQL database structure. And working on a new zMapper is a bad "rabbit hole" because it's putting my time into a product that doesn't sell much. But I can't have a new mapper in CMUD that doesn't work with zMapper because that just isn't fair to the people who *did* buy zMapper.

The SSH support *should* be relatively quick and easy. The network socket code in CMUD is very well isolated, and replacing it with SSH sockets should be straightforward, once I get some experience with SSH. This will allow me to add this new feature and fix some bugs within a single month. Working on the mapper could delay a new version by much more than a single month. Anyone who remembers the last time I rewrote the mapper in zMUD will remember how long that took.

Anyway, it's not just a matter of running a poll. I can probably already guess which new features would be most "popular", but I need to plan the schedule in a way that makes the best sense based upon all of the development constraints that people might not realize.

And, the fact is that the mapper in CMUD *does* work. It's buggier than I'd like, but it still works. I've used it for my own MUD playing already. Now, it's possible that I will be able to fix some of these bugs without doing the full mapper rewrite, but it's too early to know for sure what can be fixed easily and what can't. This is honestly the first time I've even been able to consider looking at code like the mapper since all of the previous work has been with the new stuff like the parser and packages and trying to get CMUD stable enough for a public release.
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Wed Jan 17, 2007 11:20 pm   
 
That's fair enough, Zugg. My input was simply that I think a new mapper will result in more sales than SSH support, since the mapper is one of the main complaints remaining about CMUD. If CMUD had a new mapper, there'd be many more people saying how great CMUD is, which means many more sales.

Of course, like you say, the time is a factor too. The SSH sales may well plug the time gap left by working on the mapper, which will take months. I just wanted to make sure you knew just how much people are looking forward to that mapper rewrite.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Jan 17, 2007 11:27 pm   
 
The difference is that SSH is *new* sales. The SSH plugin is $10 (or CMUD Pro or whatever it will be called), and this is new sales from existing customers who want to add SSH functionality. The TeSSH standalone SSH client is $29.95 and is completely new sales for a new audience (more of a business audience).

Improving the mapper might cause existing zMUD users to upgrade to CMUD sooner, rather than later, but that's not *new* sales. These zMUD users will *eventually* upgrade once the mapper is fixed regardless of whether it's today or in 3 months. So that doesn't actually increase the total sales like the SSH stuff does.

And yes, we'd all like *everything* on my list to be done right now Wink I know of some people who are looking forward to the Scriptable Forms more than anything else. I know other people who want the new SQL database stuff before anything else. So, the answer is that I need to do everything, but of course I can't do it all at once and have to prioritize. But for now I'm going to prioritize on what makes the most sense for the business and for the programming efficiency (some stuff depends upon the zApp code, for example).
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: Wed Jan 17, 2007 11:44 pm   
 
Why does the mapper have to be a core part of the client, why can't it be a plugin? That way you don't need to rewrite zMapper because you will have already written CMapper.
_________________
Taz :)
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Thu Jan 18, 2007 12:09 am   
 
Zugg wrote:
And yes, we'd all like *everything* on my list to be done right now Wink

No, we'd like it all done last week :P
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Thu Jan 18, 2007 2:29 am   
 
Hi Zugg. Welcome back!

Mapper fixes and improvements are what I'd like to see most of all (out of the major things) but I think you might be right about SSH making better commercial sense for now, although it might be worth pointing out that not every user who would upgrade from zMUD to CMUD now if the mapper were improved would upgrade in say 9 months time if the improved mapper were released then. I suppose there is an attrition rate (probably not huge though) of users who just stop mudding. So delay does cost. Plus there will be people between now and then who decide not to buy CMUD because of some mapper problem or something. These people may not come back. Anyway, I didn't want to sound a negative note or start the stress off. If the SSH stuff will be a lot quicker than the Mapper stuff, I would go with that first if I was you (plus fixing anything easy in the mapper). (I'm sure I would use the SSH plug-in too. Smile)


Last edited by Seb on Thu Jan 18, 2007 10:03 am; edited 1 time in total
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Thu Jan 18, 2007 2:57 am   
 
I'm not sure about needing to redo zMapper for the few of us who actually own copies, make some of the advanced features available in CMUD by standard if you like and send out an email to those who own zMapper saying 'the product is discontinued, but we'll give you a 1/2 price upgrade to CMUD if you wish to use the advanced features now available by standard, you can of course continue to use zMapper standalone with your old map database'.

Are there actually people who use zMapper stand-alone (eg totally non-MUD related such as D&D maps)? In an older letter you stated you sold 540 copies, so (as might seem reasonable) if you were to charge us $14.95 to upgrade to CMapper that's only $8000 tops (and a lot of us probably wouldn't bother to upgrade because we don't use it anymore anyway), so for the time it takes to rewrite, is it really worth it?

Those people using zMapper for D&D type stuff can continue to do so, and those who use it for MUD type stuff can just send feedback saying "I really need this feature to be ported to the CMUD mapper" and add it to the job queue where it can be processed as the product matures.
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Thu Jan 18, 2007 10:31 am   
 
I'd like for Zugg to freeze zMapper development and just create an all-inclusive CMapper plugin to be sold separately. Instead of having a mud client with basic mapping functionality and a separate, stand-alone map upgrade utility, I think the division should be mud client and a separate, full-function mapper.

zMUD+automapper | zMapper
vs.
CMUD | CMapper

Am I the only one that feels this way? I've read posts in the past claiming zMUD was too bloated (yeah right - those posters just didn't understand zMUD's awesomeness), well they should be satisfied if the mapper is removed. I'd personally never want to mud without an automapper if I had a choice and would gladly purchase a mapper plugin if I were still mudding.

I think the biggest problem would be trying to rip the automapper code out of the client and still be able parse the MUD output for map creation. That's just my two cents and SSH should be done first anyway, especially if it adds a lot of value with little effort.
Reply with quote
bortaS
Magician


Joined: 10 Oct 2000
Posts: 320
Location: Springville, UT

PostPosted: Thu Jan 18, 2007 11:20 am   
 
I'm still waiting for the trigger wizard/tester. I really dislike doing triggers on the command line. I program all day, and want to relax when I play MUDs. Trial and error with command line triggers != fun/relaxing to me. I haven't used CMUD because of this.

I have to agree that completing the apps and features that use SSH is a high commercial priority.
_________________
bortaS
~~ Crusty Klingon Programmer ~~
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Thu Jan 18, 2007 11:21 am   
 
The trigger wizard is also great because with it come custom wizards, and they are the thing of the gods. I hope it's not too much trouble to import wizards so we'll have it before the new mapper ^_^
_________________
Rorso's syntax colouriser.

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


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Thu Jan 18, 2007 12:10 pm   
 
The custom wizards code in zMUD are a little painful for complex things, unfortunately. I'm betting that the scriptable forms will be capable of similar things but with much more flexibility and style. ;)

Keep up the great work, Zugg! Looking forward to bigger and better things from CMUD this year.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Thu Jan 18, 2007 3:10 pm   
 
As mr_kent says, I think in a way it does make sense to have the mapper as a paid-for plugin (or at least the new mapper). But I think Zugg is including the standard version free with CMUD as otherwise there will be less incentive to upgrade from zMUD to CMUD, and also because otherwise CMUD won't feel like an upgrade to some people.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Thu Jan 18, 2007 3:11 pm   
 
Also, I agree that trigger testing is pretty important.
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Jan 18, 2007 8:35 pm   
 
Trigger testing will be added soon. It's a smaller feature (like several others) that can be done in parellel with the "big" projects (mapper, SSH, database, etc). They are on a completely different list in my planning program.

The Trigger Wizard is waiting for the zApp forms, since that will completely change how trigger wizards are done and provide a lot more power and also make them easier to use and create. I'll also be integrating the trigger wizards with the Shared Library so that it's easy to share wizards too.

On the mapper stuff, I should remind people that zMapper/CMapper plays a very important part. There are two parts of zMapper: display engine + map-editing interface. zMUD includes the same "display engine" code within itself, which is enabled if it detects a valid zMapper license on your system. Basically, zMUD has a basic map display engine + zMapper display engine (enabled if zMapper is detected). I tried making zMapper a "normal" plugin a long time ago, but it didn't work well at all. There was no way to get the speed needed if zMUD just called the zMapper display engine remotely. So that's why the display engine was compiled into zMUD.

The core part of the mapper rewrite is to replace the MDAC/ADO database format for maps with a more general SQL interface for maps. There will need to be a new "display engine" written that can read the new SQL map database format. What I was saying in the previous post is that just writing the "display engine" in CMUD is only part of the job. The user interface for creating/editing maps is in zMapper/CMapper and not zMUD/CMUD. So, I will need a new CMapper program that contains "new display engine" + "new map-editing interface". Otherwise there would be no way to *create* the enhanced maps that are displayed when you have a CMapper license.

Remember that the map-editing interface includes stuff like creating new room types, exit types, room shapes, etc. I don't want to bloat CMUD with those editing features. Enabling the enhanced display engine does enable *some* enhanced editing within zMUD/CMUD itself (like being able to resize a room), but if you want to modify a room shape or bitmap image, then you need the full zMapper/CMapper interface.

The only part of the mapper that understands MUDs (captures room names, descriptions, etc) is within zMUD/CMUD. zMapper/CMapper don't have any network connection and doesn't know anything about MUDs...it just displays and creates/edits the map database files.

So, when I talk about the mapper rewrite, I'm really talking about both the "display engine" (in CMUD and CMapper) and "map editing interface" (just in CMapper). The MUD-related stuff, and the bugs caused by the new docking system in #find, etc, are all normal CMUD bugs that will be fixed independant of the mapper rewrite. I just didn't have the time to dig into the mapping code in CMUD to fix these issues during the beta.

Once the display engine and editing interface have been rewritten to handle the new SQL map databases, then I'll be adding more features to the mapping, such as tile-based graphics. And most of these enhancements will require the enhanced display engine that is part of CMapper.

Instead of having an SSH plugin, I am considering doing something called "CMUD-Pro" which would include the SSH stuff, as well as the mapper display engine (and eventual enhanced database module engine). This would allow CMUD-Pro to display enhanced maps (just as if you had zMapper/CMapper installed) even though you would still need CMapper if you wanted to edit the enhanced features of the map (like create new room types, etc). This might make CMUD-Pro more attractive to more people than just the SSH stuff would, and might help introduce people to the kind of stuff you can do with CMapper. It would also provide the COM API for the mapper which allows more scripting possibilities. Essentially, CMUD-Pro would enable the code within CMUD just as if CMapper was detected.

Hope that's not all too complicated to understand. It should get clearer as we go along.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Thu Jan 18, 2007 10:39 pm   
 
No, not too complicated. Thanks, Zugg, for what I think was a pretty clear description of how it fits together.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
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