Just wanted to say thanks for all your hard work over the years, Nick.
MUSHclient is by far the most simple, efficient, non-bloated MUD client I have ever had the pleasure of using. I paid for my MUSHclient registration, and even though text-based MUDs seem to be a dying breed, have never regretted it.
I think Open Source would suit MUSHclient well, there is a LOT that fellow programmers could learn from it. :)
I think this decision is best, being shareware was probably the only obstacle to the spread of MC. The best MUD client also being open source, I don't see much competition for that.
Thanks Nick! Still glad I registered though. Your post wasn't entirely clear on whether you were planning to cut back on the amount of time you spend developing/supporting MUSHclient though? More power to you if you are, you've given us more than enough, but I was wondering what our plans were! -Tsunami
Ok.. Lets try to see if, once it is OSS, we keep it from forking. POVRay's license, which some twits insist isn't free, tend to provide better control over what happens to the application once its out in the wild. At most, there are:
1. Official version incorporating the best and most stable features, with an expectation they will get more stable over time.
2. MegaPOV, which is a catch all for new ideas, sort of like what the main OSS projects tend to end up being, but supported by a seperate team, since its not part of the official spec.
3. A very small number of specialty versions, usually only with 1-2 major changes or additions, which if they prove useful the tier 2 team will fit into MegaPOV, then later, if its stable enough and doesn't break the main teams intent for the application, will get incorporated there too.
In the case of Mushclient, it might even be possible to use the existing system that has distinct steps in it, to develop optional dlls that provide function. In other words, if someone developed GUI features, those could be usable "if" you download and install the module for it, but the standard client would only grow by the amount needed to check for the dll and support those commands "if" its installed. That solves one huge complaint we already have, bloat. If the client itself doesn't bloat, but *large* features get incorporated as optional modules, its not as huge of a problem. It basically becomes a class of plugins that provide pre-defined function(s), that are then accessable from the script system, as though they where built into the client. If its missing, and something trys to do, "world.newobject("blah")", but the module isn't installed, you get an error. Simple as that.
Well, maybe not simple, but with the source open, there are definitely some new options we will have available for working these things out.
Your post wasn't entirely clear on whether you were planning to cut back on the amount of time you spend developing/supporting MUSHclient though?
I regard it as a fairly stable program right now, if there is a problem that I can solve simply because of my knowledge of the application, I probably will.
Things like Shadowfyr is talking about - adding support for events in DLLs (or COM objects) is more likely to be a case of "if you can make it work, fine!".
There are potential pitfalls in making changes, generally I have tried to anticipate those, and put comments in the code to indicate why things are being done a certain way.
I will be a little less likely to support someone who adds a "cool new feature" but " ... unfortunately the client crashes a lot now".
The sort of things people could usefully do is improve the configuration screens for example, this would not change core functionality, but make the program easier to use.
you know i have wet dream where i can port mushclient to linux natively.
Well, the main problem here is that MUSHclient uses MFC. It's not that MFC is horrible or anything, just that Microsoft doesn't exactly release linux gui libraries. Porting it to QT or GTK is possible, but will require a decent reworking of a lot of code. That being said, I think I'm going to try doing just that until it either works, or I get frustrated enough to give up.
What I'm looking forward to the most though is just looking at the source code. MC is an extremely good program, and I'd like to take a look at how Nick pulled off a lot of the great things he has done.
I'm not sure there's that much of a problem in forking. It's just how the FL/OSS world works. And frankly large-scale forking doesn't really happen that often especially for small programs.
What would be nice would be a clear structure for the "official" source repository. Whether Nick himself manages it or he designates community members is an interesting question, but what really matters is that it be clear where exactly one goes to get the "real thing".
I'm looking at some distributed version control systems like bazaar-vcs.org and have been extremely impressed; it seems like exactly what would be appropriate for us.
I don't like the plugin idea for such sweeping changes because it is very hard to push too much into "modules". It's really easy to want to make your application completely modular until you actually start doing it. I mean, sure, I like the idea of modules, I'm just not sure how much work should go into it.
One thing I've admired about Nick's dislike for bloat is not that he dislikes bloat per se. My impression is that he tries to figure out what really is the problem being solved, and tries to see what the minimal solution to it is. Instead of throwing a 500k DLL at the problem he works to identify the precise need that is lacking and satisfy just that. That restraint, I find, is one of the reasons why MUSHclient is so clean.
I would like to see the ability to use addons to significantly add features to the mushclient program. Shadowfyr's idea of making an additional GUI with buttons and other things. But as previously stated the messages and other message issues are quite possible. On the other hand with the source, one could add something similar to zMud's button bar, perhaps not with its usage being as dynamic, but this will allow gauges and other things. Multi-State Buttons, Slide Bars, Up-Down Tickers, and MANY other controls are VERY possible. Also someone might perhaps implement the ability to re-order controls via a settings window, like MANY MS programs and others a well use to set where controls are located. Mushclient already has the ability to re-order the toolbars, but not the items ON the toolbars, so it is nearly there, just need to implement a little more code to complete the task.
Thank you for the complimentary remarks, everyone! :-)
I have released now a version that does not rely upon the proprietary spell checker, so the door is open for the release of the source code.
Any suggestions about a suitable license wording? Shadowfyr raises an interesting point about "retaining control", although I am not overly concerned about that. Basically I have in mind:
Anyone can make changes as they see fit
Those changes could be released for others to incorporate themselves
Precompiled amended versions could be distributed (eg. like Zeno suggested in another thread)
I am not sure I want people to make some (or no) changes and then attempt to sell the resulting version. The whole idea is that the client should be freely available.
There are various license flavours, although I don't pretend to be an expert. I think the GPL (GNU Public License) rather obsessively tries to stop people deriving works without releasing the source code for everything. I am not sure that is necessary totally. OTOH, Lua's license is pretty liberal, because they recognise that you may want to incorporate Lua into proprietary software.
I should point out, that as I have said many times, MUSHclient was built using MFC libraries. Thus, unless you have a commercial copy of the Microsoft C++ compiler (itself pretty industry standard I suppose), you won't be able to successfully compile it.
Also, I don't have the latest version of the MS C++ compiler, I can't say for sure how well it will compile if you have a recent version.
Off the top of my head, I'd suggest the MIT license. I don't remember the details off the top of my head, but I know that it allows for release of binaries without the source. I'm not sure if it restricts the sale of new versions though. I know I have a few articles somewhere in my bookcase I can look through.
I use a modified version of the BSD license for my software. (The BSD license is quite similar to the MIT license.) The modification is that you cannot sell it without my permission. I think something similar for you would work. The BSD/MIT licenses do not, themselves, forbid resale of your work. And the GPL is, as you say, somewhat obsessive about a few things.
This is what I use:
http://david.the-haleys.org/dev/shared-string/LICENSE
You stated that you do not have the CURRENT version of the C++ compiler, what version DO you use. I have Visual Studio 6, which is VB 6, VC 6, FoxPro, and a few other things ...
As far as I am aware that is the latest version PRIOR to .NET's existence.
I do hope that I will be able to compile it using that :)
If you can compile MFC, you will most probably be able to compile MUSHclient. As far as I know all versions of MSVC++ can compile MFC applications so there should not be a problem. I know for sure that MSVC++6 and MSVC++2003, at least, can compile MFC. (2003 was the first so-called ".NET version", I think.)
Quote: I would like to see the ability to use addons to significantly add features to the mushclient program. Shadowfyr's idea of making an additional GUI with buttons and other things. But as previously stated the messages and other message issues are quite possible.
As I stated on my last message about the subject, possible the problems may be, but solvable they are. The main issue was having the code to experiment with. Trying to find a solution where you where "guessing" what the code looked like, even when you found a possible solution, doesn't work too well. lol
As for plugin functionality... It might not be useful at all, on later thought. There isn't a lot missing in the client, and the things that I see that are would need to be permanent:
1. Threaded ftp/http file transfers. Useful for cases where someone creates something odd in script that needs to transfer data, but where freezing the client, instead of just lagging it, is not an option. Something with bandwidth throttling, which might not work well with some servers though, might be useful to lower that lag.
2. GUI support. See the first part of my comments. If its "in" the client, instead of trying to redirect it to something else, it should be solvable.
3. A output window re-write. Some people might want text positioning, real flashing, inlined MXP images, etc. I wouldn't mind at least the "option" of having those when I needed them. Though, fixing that is probably far less trivial than fixing the GUI.
Oh, and maybe 4. This was brought up recently on TMS when discussing designing new clients. Support for the older, "One character sent per keypress" method. Some older games you can play online, like Tradewars2002 not only use text positioning, but don't work by sending a return after every command. They "require" that the client send each character as is, then show the echo from the server. 99.9% of muds don't do this, but as someone pointed out, on reason muds tend to stagnate is not that its impossible to come up with good ideas, but rather that you are stuck with what the "client" you use to connect with supports. So, even if you want to do X, Y and Z, it doesn't help if the only client that does those things *won't* do A through W, which are far more important. You don't use MS Telnet to play games, because it sucks at 90% of the stuff that you "need" a game client to do. But 100% of those game clients can't and won't do certain things telnet "will" do.
Mushclient can simulate protocols through script to the point where you could probably play Everquest through it (with some adjustment to how the objects locations are displayed in text, instead of 3D. However, we can't support certain basic ANSI or MXP, etc., features, short of throwing out the client and using a different one? Am I the only person here that finds that, now that we can theoretically do something about it, just a bit silly?
Oh, and just to be clear. The main difference between MFC and other options is that MFC *hides* most of the application event messaging and provides certain short cuts. One of the issues of using late bound GUI with it is that you have to add in library functions from ATL, which give you *back* control over those hidden bits, or at least enough to bind objects and events. Likely and port from MFC to something less limited would involve adding similar code into the application. And, ironically, while its not necessarilly an option for the PC side, due to it not running on older OS versions, MONO (.NET for Linux) might be the best thing to port to on the Linux side. lol
And the best part about MC becoming open source is that you can get cracking on all these ideas you have. As you've said, most of these should be pretty simple to do. Just 10-30 lines of code. I look forward to seeing you making additions to the client, either with patches or getting an official repository.
A recent post (I am not saying which one) appeared to offer pirated copies of Microsoft's compiler to anyone who wanted it.
I am concerned that this forum may fall into disrepute, and possibly be subject to litigation, if it is used as a distribution point for pirated software.
Accordingly, I have amended the relevant post(s) to remove such references, and any follow-up post(s) that commented on it.
Please do not make posts here offering "free" copies of Microsoft's software. Whilst I support the Open Source software movement, I also support the right of software authors to charge, as they see fit, for their software.
Also please do not make posts identifying yourself, however indirectly, as someone who is prepared to offer pirated software.
Good luck with doing that. The current output window design is pretty tightly integrated into how a lot of things are done (for example, style runs, MXP hyperlinks).
It is also optimized for speed of adding to, scrolling, and drawing.
Flashing text is probably moderately easy to do - as for inlining images, well that would take a lot of work.
Quote:
"One character sent per keypress" method.
Do you really want to go back to the old methods here? One of the main reasons that was abandoned was speed. A typical packet might take 200 milliseconds to traverse from the client to the server (that is, 1/5 of a second). If all it contains is a single keypress (one byte), then it is an inefficient use of network resources for a start (as there is a packet header on every network packet). The TCP/IP packet header size is around 20 bytes, so using 20 bytes to deliver a 1-byte payload seems inefficient to me.
Plus, add up those latencies and typing something like "hi there!" (10 bytes including the newline) would take 10 x 200 ms to send (2 seconds), plus the 2 seconds you are waiting for the server to echo each character. And that is just network latency, you would need to add to that server "lag", if it wasn't ready to echo each character the moment it arrived.
The whole point of sending stuff in blocks is to minimize the delay. A 80-character room description which takes 1/5 second to send is acceptable. It isn't acceptable if the 1/5 second applies individually to each of those 80 characters.
Quote:
one reason muds tend to stagnate is not that its impossible to come up with good ideas, but rather that you are stuck with what the "client" you use to connect with supports
Putting aside the problems that MMORPGs (like World of Warcraft) pose, as a highly-addictive alternative, I suggest if you want to come up with better client support you would move forwards in your design, rather than back to what was used in 1980.
One idea I had, and this would be a rewrite of both server and client, would be to combine the ease-of-use of graphical MMORPGs, with the comparative ease of development of a text-based MUD.
For example, a custom client could have portions of the window dedicated to things like inventory lists, maps, mini-maps, quests, what the character has equipped, and so on. There might be sub-windows for chatting, etc.
Then, rather than sending a character at a time, you might design custom messages (eg. using XML format, or Lua format) to send things each way, rather than having to parse pure text.
For example, using Lua data structures as a guide, moving from one room to another might look like this:
action="move" room=1234 mv=22
That is, we are telling the client we have moved, what room we are now in, and our new movements points value.
Then the client might not know the description for room 1234, so it might request:
action="getdesc" room=1234
The server might reply:
action="roomdesc" room=1234
description=[[
You are before the cathedral's altar. Those of ill luck or poor faith often
come here to pray to their God for guidance, or chance. An aisle leads back
south through the cathedral, while a large public board lies to the west.
]]
roomname="The Cathedral Altar"
exits={"s", "w"}
mobsinroom={5566,8877}
objectsinroom={6543,6432,6546}
Now the client, if it didn't know the description for the mobs, or objects, might request (and subsequently cache) their descriptions.
This sort of thing would make scripting at the client end a lot simpler. Rather than having to try to parse (and guess) what each line means, they would have clear-cut protocols.
The main difference between MFC and other options is that MFC *hides* most of the application event messaging and provides certain short cuts.
The MFC source code in my installation is about 10.5 Mb, so I think it does a little bit more than that.
If you are going to chuck out MFC you will have to replace it with your own message management framework. It also has a lot of code for making handling of dialog boxes simpler. It also provides things like list management, memory management, string management. Getting rid of MFC will be non-trivial.
Personally I would start a new client, rather than attempting that.
I do not believe that the bit about sending each keypress to the server was for every world created. It was for very specific games which rely on that anyway. Currently, MUSHclient is a poor client for telnet BBSes that run old door games (not that it was designed for such a use).
Sure, but I was pointing out why it isn't a brilliant idea, for any newly designed MUD.
I think Shadowfyr is heading down the "why can't we have cursor addressing?" path. Again, the design of the handling of server input, and the way it is displayed, makes that very hard.
I've been looking into MFC libraries to use naitively in linux. There are a few projects to have a wrapper for wxWidgets to have the same API as MFC. This is taking quite a long time, mostly because of all the reasons mentioned. Doing a complete rewrite with wxWidgets or glide would probably be easier than debugging a jump to the different library.
My posting about the SASE was only due to the fact that MS no longer supports the non .NET compilers, whether it is VB or VC, or any other thing they have released. Sure the Knowledge Base still has references to such things, but there is no way of obtaining such a thing. I did not mean to offend, or blatantly seem to offer pirated things, as it is no longer considered to be pirated when a company no longer has any financial gains to such a thing.
And Nick the compiler you use is not THAT old then, when you had stated that you used an old compiler I thought back to VC5 or possibly even earlier lol
Quote: as it is no longer considered to be pirated when a company no longer has any financial gains to such a thing.
Distributing copies of software that is not officially free according to the vendor is piracy, end of story. It doesn't matter if they still sell it. If something belongs to somebody else, you do not have the right to hand it out for free unless they say you can.
Now, you might argue that if they don't sell it, they should make it free, but that is a different story. Even there I disagree, because if they were to make VS6 free, people would have less incentive to buy the newer versions, hence interfering with their business.
Piracy is piracy, end of story, there is no wishy-washy reasoning to it. Abandonware is something completely different.
Quote: [Nick] Getting rid of MFC will be non-trivial.
And Nick the compiler you use is not THAT old then ...
The date on the About box for Visual Studio is 1994-1998, so that makes it around 9 years old. In computer terms, that seems fairly old to me. However it still works pretty well. :)
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
The software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.
I think this covers everything. By retaining the copyright I retain the right to restrict its distribution in the sense that other people cannot place more restrictive conditions upon copies of it.
Well, first off, IANAL. However the license gives me the "right to permit persons to whom the Software is furnished to do so", not the obligation. I don't see why that license forces me to keep the same distribution policy. For instance, I get your code, and make some changes to it. Your license, as far as I can tell, doesn't prevent me from keeping those changes to myself and selling them, which seemed to be what you wanted to avoid previously.
I think the only way you can limit the distribution to the same terms as yours (i.e. keeping it unrestricted) you would have to introduce some kind of "copy-left" clause, which is what the GPL family tends to do.
And if you want to restrict the commercial use, you'd need something to that effect as well.
As I read it you have the "right to use it" ... "subject to the condition that" ... "the copyright notice be included".
Am I misreading this? It seems to me that the way it reads you can use it, but on the condition that the notice stays with the copy, and the notice gives you the right, free of charge, to distribute it.
Well, yes, I can do what I want with it as long as I include the copyright notice. That still doesn't prevent me from selling it, and in particular it doesn't prevent me from keeping my modifications to myself.
For example, I believe this license would allow me to distribute (and sell) binaries of a modified MUSHclient without distributing the source, as long as I include the copyright notice.
His plan to make a special identification sequence would come undone a bit if he had to supply the source code for his changes.
I understand the license permits selling, but how big a problem is that? If the official copy is available for free, how much money could you realistically make by selling a modified version? The modifications would have to be pretty damn good.
I think the other problem with insisting that source accompany derived works (like the GPL does), is that it can be a bit onerous. For example, a MUD makes available MUSHclient, possibly slightly modified, but has to supply 400 source files as well - to players who probably couldn't care less about them, and would just find them confusing. To say nothing of the size increase that would make to the download.
It seems to me that a potentially bigger problem is that someone might take the source, add trojan horses or viruses to it, claim to have made improvements, and then give it away.
To guard against that I would suggest that players obtain their copies from this site, or if they have got one from another place, compare the MD5 sums to make sure the file is a "good" one.
Well, you don't have to make the source available with the binary download, you just have to make the source available to those who ask for it, perhaps as a separate download -- is my understanding. (But yes, this would pose a problem for systems like Zeno's which require some secret to be exchanged.)
I think your license is fine in general; I was just commenting with respect to your previous reluctance of letting people sell it.