Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ MUSHclient now Freeware

MUSHclient now Freeware

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1  2 3  

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #15 on Sun 01 Apr 2007 11:32 AM (UTC)
Message
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.)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #16 on Sun 01 Apr 2007 06:51 PM (UTC)
Message
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
Top

Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #17 on Sun 01 Apr 2007 07:20 PM (UTC)
Message
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.

It is much easier to fight for one's ideals than to live up to them.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #18 on Sun 01 Apr 2007 09:19 PM (UTC)

Amended on Sun 01 Apr 2007 09:21 PM (UTC) by Nick Gammon

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #19 on Sun 01 Apr 2007 09:20 PM (UTC)
Message
Quote:

... what version DO you use?


Microsoft Visual C++ 6.0 with Service Pack 6 installed.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #20 on Sun 01 Apr 2007 09:43 PM (UTC)

Amended on Sun 01 Apr 2007 10:04 PM (UTC) by Nick Gammon

Message
Quote:

3. A output window re-write.


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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #21 on Sun 01 Apr 2007 10:03 PM (UTC)
Message
Quote:

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #22 on Sun 01 Apr 2007 10:04 PM (UTC)
Message
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).

It is much easier to fight for one's ideals than to live up to them.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #23 on Sun 01 Apr 2007 10:07 PM (UTC)
Message
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #24 on Sun 01 Apr 2007 10:09 PM (UTC)
Message
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.

It is much easier to fight for one's ideals than to live up to them.
Top

Posted by Onoitsu2   USA  (248 posts)  Bio
Date Reply #25 on Sun 01 Apr 2007 10:24 PM (UTC)
Message
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

Laterzzz,
Onoitsu2
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #26 on Sun 01 Apr 2007 11:22 PM (UTC)
Message
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.


Hehe. You can say that again. :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #27 on Sun 01 Apr 2007 11:58 PM (UTC)
Message
I believe Microsoft still release a compiler that supports MFC, see:

http://msdn2.microsoft.com/en-us/visualc/default.aspx

I see people are selling Visual Studio v6 on eBay for varying prices, one was selling for $15.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #28 on Sun 01 Apr 2007 11:59 PM (UTC)
Message
Quote:

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #29 on Mon 02 Apr 2007 12:12 AM (UTC)
Message
I think I might use an adaptation of the Lua distribution license, as below:




MUSHclient is not in the public domain and Nick Gammon keeps its copyright.

Copyright © 1995 - 2007 by Nick Gammon.

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.

Does anyone see any problems with that?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


95,000 views.

This is page 2, subject is 3 pages long:  [Previous page]  1  2 3  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.