[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Possible new client written using wxWidgets?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Possible new client written using wxWidgets?

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


Pages: 1  2  3  4  5  6  7  8  9 10  11  

Posted by Nick Gammon   Australia  (21,677 posts)  [Biography] bio   Forum Administrator
Date Reply #120 on Fri 21 Sep 2007 11:48 PM (UTC)
Message
I am starting to doubt that writing a new client is - for me - a viable proposition.

If a significant number of people had said they would like a new, lean, client which - in exchange for a smaller feature set - would run on multiple platforms, it could have been an interesting challenge.

However as soon as you get to the situation where you want multiple scripting languages supported - all of which have their own interfaces - plus most existing features (like multiple worlds support), the project grows to quite large proportions.

I am not sure that the end result would really benefit the MUD community a great deal. We already have a number of mainstream clients for Windows, MUSHclient being one, and there are a few other ones which are also well-respected.

Linux has its fair share, plus MUSHclient runs quite nicely using Wine, which is free.

Mac OS/X also has quite a few clients, plus you can run MUSHclient itself if you install VMware or similar (Boot Camp or Parallels) on the Mac (admittedly that costs extra money).

I am inclined to think that, if enough effort to develop a new client was going to be made by someone, that a new paradigm could be developed, by also developing a new server, that starts to use some of the new technology that has been developed over the last 20 years. In other words, drop the pure text-only interface between client and server, and have "event messages" that more neatly encapsulate what is going on in the virtual world, and lets the client display it, unambiguously, in a neater way.

Remember, the source for MUSHclient is publicly available, if someone simply wants to improve it, they are free to do so, which might be easier than writing a new client from scratch.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by tobiassjosten   Sweden  (79 posts)  [Biography] bio
Date Reply #121 on Tue 25 Sep 2007 07:57 AM (UTC)
Message
I'm sad to hear you say that, Nick, since I was very excited about you writing a new client on that basis you listed firstly.

MUSHclient is a great client. But it does have some downsides in that it doesn't run natively on posix and it doesn't provide much GUI functionality. It also have loads of functions which I don't use myself, but unless I write my own client, that is expected.

Currently I'm using MUSHclient through Wine only for its autocompletion function (can't live without it) and it's accelerators. I do the actual work in the back end using IMTS (imts.sourceforge.com) and it's ILua module. I used to have MUSHclient do it all but when I switched to Linux I also switched the setup.

I would very much prefer a leaner client with some minor GUI functions (mainly external windows with ANSI support), Lua hooks and Linux compability, to anything else. Please reconsider your project. It would help me immensely and as such I know that it would help others as well.

.. or I'd be forced to learn Python better and write my own front end only client. And we don't want that. :>

Simplicity is Divine | http://nogfx.org/
[Go to top] top

Posted by Jammet   (14 posts)  [Biography] bio
Date Reply #122 on Wed 26 Sep 2007 03:06 PM (UTC)
Message
It is true that Linux does have a fair amount of such clients.

The best are text based and immensively complicated to use, however. Except for TrebuchetTk, which is gui based - there just aren't any really good graphical MU clients that I know of. And TrebuchetTk is primarily made for tinyMU*, which I exclusively use, so I got lucky.

Many other gui client projects just went bellyup over the years, without ever really becoming stable or flexible to the point that they could be considered safe for everyday use.

Nick, I guess the decision lies with you, but if you are most worried about the integration of scripting languages, maybe all the client needs is a functional plugin API.

Don't forget, you don't have to support all the languages yourself.

If it's kept open source and the licence isn't something to worry about - and all you want to work with is lua - then other people might come up with perl, python, or whatever other script-integration they want through the plugin API.
[Go to top] top

Posted by Maxhrk   USA  (76 posts)  [Biography] bio
Date Reply #123 on Tue 02 Oct 2007 01:16 AM (UTC)
Message
well i have been using MushClient on wine.. but i am not comfortable with that because some feature might dont work on wine like... changing textbox's background to something else... but... it got stuck on black.. only thing color displayed was on text's background only. Wish i could get my hand on Mushclient Linux version. :P (at least that what I hold my hope for it.)

sorry to get off-topic regards wxWidgets. Wxidgets is interesting to have.
[Go to top] top

Posted by tobiassjosten   Sweden  (79 posts)  [Biography] bio
Date Reply #124 on Tue 02 Oct 2007 11:38 AM (UTC)
Message
I just came to think of a feature that I would absolutely love in a client (with some GUI functionality). Progress bars! That'd be so nice to have, to keep score on active defenses, respawning monsters and such.

Just throwing one in there, in case all hope for a shiney new platform independent client isn't lost. ;)

Simplicity is Divine | http://nogfx.org/
[Go to top] top

Posted by Drow   (10 posts)  [Biography] bio
Date Reply #125 on Mon 08 Oct 2007 08:02 PM (UTC)
Message
If there isn't going to be a new client, then have you decided what you are going to do with the current one?

To go through your list, here's what i think:

Go ahead with these:
- Extra panels (panes) for the world window (eg. statuses, coloured chat, health bars)
- Better support for some things like accelerator keys (binding keystrokes to actions)
- Store all colour runs internally as RGB codes, rather than the current (complex) system of ANSI, custom colours, or RGB. The current system makes it very fiddly when using colours (eg. drawing them).
- If multiple panes were going to be supported, design them in from the start.
- Drop "custom colours" in favour of simply specifying RGB colour codes where required (eg. in triggers).
- Simplify the script interface somewhat. A lot of early script functions (like WorldName, WorldAddress, WorldPort) can be achieved by doing (the equivalent of) GetInfo. Also, by only supporting Lua scripting, the script interface can become more powerful. For example, you can have optional arguments, supply tables as arguments, and return multiple return values.


If it helps you, I don't need these:
- Better font management (eg. multiple fonts in output window, possibly graphics as well)
- Drop the "macros" idea in favour of accelerator keys.
- Drop the "keypad" configuration in favour of accelerator keys.
- Drop the "default fonts/triggers/aliases" idea. This has pretty-well been replaced by plugins.
- Drop the "multiple output windows" idea (Window menu -> New Window) - as this makes things more complicated in various places.
- Maybe drop the "chat" system initially - I am not sure how many people use this.
- Maybe drop the notepad idea - after all you can always use your favourite text editor.
- Perhaps drop the ability to connect to multiple worlds. After all, many people would be playing one MUD at a time. If you wanted to play on more than one you can open multiple clients.
- Use STL (C++ Standard Template Library) internally where possible to simplify list (and similar) management. (I am aware that wxWidgets does not use STL internally, however as it is written in C++ there is no reason why I can't).
- Build in proper support for Telnet negotiation from the ground up, which would simplify things a bit.
- Some script actions (like plugin callbacks, or "on world connect") could be simplified by having some sort of event model, where you add a function to a table of events for which you would like notification. This could provide a more flexible way of intercepting things (like incoming/outgoing packets).


Be careful here:
- Simplify the "send to" part of triggers, aliases and timers. Perhaps everything could be "send to script", as you can script sending to all the other places. (eg. "Send 'go west'" to send to the MUD).


Not important:
- Internationalization (already done)
- Improvements to the configuration screens
- Removal of lots of configuration items from Registry to configuration files
- Support for Linux and Mac operating systems
- Use Lua for configuration files rather than XML. Lua configurations can be loaded and saved in a few lines of code, thus saving heaps of XML parsing and writing.
- Drop the various Windows Script Engine script interfaces in favour of straight Lua scripting.
- Drop MXP support (at least initially) as I don't think *that* many MUDs are using it. A quick search of MudConnector shows that about 151 out of 1,515 MUDs use MXP.


Just wondering...if frames were to be implemented, how difficult would it be to implement different types of window parsers. I'm thinking I'd might find useful a second frame that showed HTML code with tables, fonts, colours, anchors, images etc. Writing that from scratch would be a serious no no, but it looks like all bloatwares on the net can soon show HTML pages and burn a DVD, so I'm just wondering if there are open source pieces of code that already do this?
Next...CSS2 and Java? ;)

[Go to top] top

Posted by Jammet   (14 posts)  [Biography] bio
Date Reply #126 on Tue 09 Oct 2007 11:55 AM (UTC)
Message
> Not important:
> - Support for Linux and Mac operating systems

Gee, that was supposedly one of the core goals of having a new client. I'd strongly hope that should be stricken from a 'not important' list.
[Go to top] top

Posted by Ian Kirker   (30 posts)  [Biography] bio
Date Reply #127 on Tue 09 Oct 2007 12:56 PM (UTC)
Message
Drow wrote:
Writing that from scratch would be a serious no no, but it looks like all bloatwares on the net can soon show HTML pages and burn a DVD, so I'm just wondering if there are open source pieces of code that already do this?

The bloatware includes it largely because there are APIs that come with Windows to allow it - you can add an IExplorer widget to almost anything, and I think the CD burning thing is just in the Windows API. (Though I'm less sure of that one.)

Having said that, wxWidgets does seem to include both HTML (though I'm not sure how tricky it is to use), and RichText functionality.
[Go to top] top

Posted by Shadowfyr   USA  (1,783 posts)  [Biography] bio
Date Reply #128 on Tue 09 Oct 2007 05:41 PM (UTC)

Amended on Tue 09 Oct 2007 05:43 PM (UTC) by Shadowfyr

Message
Can't say I agree with your "don't need" list, and not just because I use a few of them or like how they currently work. Half the discussion of *new* clients, both hear and on TMS have been about *adding* features, not removing them, so when you start talking about how notepad isn't needed, or MXP isn't needed, or chat isn't needed, etc. you are seriously going the wrong way. Same with multiple open worlds. You do know that a **lot** of people that use these clients are admin right, and they often have 2-3, or even 4, worlds open at once, tied to different ports of the same mud, or even some to the main mud and others to a test server, etc.

Going the way of accelerators... Well, there are some benefits I guess, but right now, since doing that eliminates the ease of looking to see what they are set to via the macro list, they are a pain in the ass imho. Making them more so, by removing that list entirely, including for the keypad, which for most people is the *only* thing they are going to use at all, and which they are not going to be happy about having to script the settings for, is a bad idea imho. If one where to go that way, they *need* to be in a functional list that someone can edit without script, and they still need to contain "some" defaults, for some of the basic functions like the keypad commands.

Sort of agree with the event management, but only in the sense that such a system would, in theory, provide the means to also deal with object events from ActiveX (though that would "break" the ability to make it portable). The only problem being that its still going to require some fiddling to get it to work with the client as written, or a rewrite, so its supported properly from the start.

The careful here - Bad, bad, horrible idea. It takes extra time, even when using Lua, to execute script, instead of just handling normal output. Only allowing script therefor would tend to slow the client down. The only way you might do that is if you had triggers, etc. as part of the event system and required everything they did to fire a function in the script space, which would not have to thus be loaded, run, then unloaded every time. But, that would just make the learning curve higher *and* make those features less accessible. The only other alternative I could see would be to auto-create functions in the script space, containing the script you had in "send to", so its semi-permanent. This would mean that you would also have to automatically set the function to have parameters, which would have to match the number of wildcards in the original, so that something like:

if "%1" = "fred" then
  send "say Hi Fred!"
end if


becomes something like:

function F1AF3(12342)
  if 12342 = "fred" then
    send "say Hi Fred!"
  end if
end function


This obviously becomes a tad more complicated to do in cases where the %1 is intentionally left outside of quotes, so that its treated as a variable name, like counting the number of times you see Fred, by doing %1 = %1 + 1. How you would manage to project "that" into a semi-perm script space, so that you don't have the overhead from it I have no clue.

Point is, its not a good idea to do this, not without making changes that are possibly and even worse idea.

As for your list of improvements... The only one I think is a tossup is the simplifying of the script interface. This would a) break backward compatibility and b) make it even harder for someone to go from something like zMud or TinTin to this client, since half the stuff that is complicated involves things like CreateTrigger, which has two versions, but *still* requires you set some things indirectly, which is confusing to someone used to just typing in something like "#t blah". Heck, its confusing to me sometimes, and I am used to the client. A big chunk of the problem though arises from two factors. A) the original design is based on a limited library, which can't handle overloading and b) I am not sure Nick knows how to do that anyway. Strictly speaking, he is correct that you shouldn't change and interface "after" creation, but there are methods for overloading a function, which let you do something like:

fizbug(a) -> Calls original fizbug function.
fizbug(a, b) -> Calls fizbug 2.0 function.
fizbug(a, b, c, d) -> Calls fizbug 2.5 function.

The interface determines "which" one is called, based on the number of parameters. It can even tell the difference between a call that has a number, or a string, etc., and call a different internal function based on that. The whole, fizbug, fizbugEx, fizbugEx2 BS was a very early attempt to deal with this mess, and it caused huge problems for applications like databases, where the input needed to change, to handle new features, but where no one in their right mind wanted to have to recode billions of lines of programs that used it, just to use fizbugEx, instead of fizbug, just to get at that one feature.

But, as I said, there may be inherent limitations in MFC that prevent this kind of overloading, and result in us being stuck with the mess where you can't just tack on some more parameters, and have the function interface figure out "which" call to make.
[Go to top] top

Posted by Drow   (10 posts)  [Biography] bio
Date Reply #129 on Tue 09 Oct 2007 06:47 PM (UTC)
Message
Well there were my opinions accordingly to what I need. There's always someone using some option that has been coded. Only a poll might show directions to what people use...
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #130 on Tue 09 Oct 2007 08:35 PM (UTC)
Message
If the client is written using wxWidgets, multi-platform support (almost) comes for free. That said, given how easy it is to support multiple platform using cross-platform GUI libraries, it would be an unfortunate waste to not explicitly target multiple platforms from the get-go.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (21,677 posts)  [Biography] bio   Forum Administrator
Date Reply #131 on Tue 09 Oct 2007 09:23 PM (UTC)
Message
These are all helpful suggestions and I thank everyone who has taken the time to make them.

The problem with improving the existing client is that, due to the way it was originally designed, some things simply aren't easy. This is partly because of the use of MFC libraries means that anything that doesn't fit into a "template" supplied by the library is harder to achieve. Not only harder, but you are fighting the library which is expecting you to be doing something else, and it tries to "correct" you.

If I had written a new client, then from the start I would allow for "obvious" (to me, now) things like extra frames, status bars, coloured panes, etc.

I agree with Shadowfyr that there is probably not much to be achieved by removing existing features, except to annoy existing users.

Once again, I think that if heaps of effort was going to be made into writing a new client, then whoever did it could consider a new paradigm, and perhaps develop a new server as well, that supported better exchange of information between the client and the server.

As an example of this, my children play Club Penguin:

http://www.clubpenguin.com/

This is a sort-of MMORPG game (designed for youngish children), where you join up, can chat to each other, and wander off and do tasks. Thus it is conceptually similar to a MUD (except it is graphical). The interesting part? You don't download a client. As that web page says: "Nothing to download". It is all done in Flash (I think), and as you move around, and go into the mini games that are in it (like steering a sled through a mine), it must install a Flash program to make it work.

I suppose you could argue that it is downloading "something", or it wouldn't work, but there is no client program you use. It runs from your web brower. Plus, it is cross-platform. I have seen it work on Windows, Mac and Linux.

It is free to play but you can join for a modest amount (monthly subscription) and get the ability to buy your pet penguin more clothes etc. Believe me, this sort of thing is exactly what kids want.

I read about how Disney is planning to acquire it for around $700 million, so whoever developed it is probably laughing all the way to the bank.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #132 on Wed 10 Oct 2007 06:45 PM (UTC)
Message
That penguin game looks a lot like yohoho pirates. Both are run in flash and there are similar ideas like playing games to gain money to buy neat stuff. The creator of Aardwolf was looking to do something with a java client a while ago so that people could just visit the Aardwolf homepage if they didn't have a client on their computer. People weren't terribly interested though, so development stopped fairly soon. It's debatable whether the client had few features because people weren't interested, or people weren't interested because it had few features. I think the main problem people had with it was a lack of triggers/aliases and no saveable settings, but that's just my pet theory.

As for backwards compatability, that can be included in the first few versions similar to how the old file format was kept for a few years after it was changed. Granted, this would require quite a bit of extra work, but that is to be expected when you want to change the whole design of a program.

I still will support any effort to rewrite the client in wxWidgets, if for no other reasons than to include those "obvious" things and to make it cross platform to gain more users. It would be nice if we could extend a client as good as MUSHclient in a much more manageable fashion, rather than fighting with the base library every step of the way.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Shadowfyr   USA  (1,783 posts)  [Biography] bio
Date Reply #133 on Wed 10 Oct 2007 09:50 PM (UTC)
Message
Ugh.. Sorry, I want the client under "my" control Nick. Not just because it means I can do more with it, but because I personally hate stuff based on Flash or the like, which usually assumes you have broadband and a using something that *correctly* supports what ever version of the flash player or javascript, etc. it runs with. Imho, these things where not meant to run in a web browser. It might be nicer from their end to make one that does, but I personally dread the day they come out with something like, "World of Warcraft: Mega, no download or install needed, its all done in Flash!" lol

Though, I suppose, if you don't mind using a possibly broken web browser, with all the security issues that go with layering one possibly buggy program on a possibly buggy browser, on a buggy OS, and being told you are only allowed to do what their client explicitly allows you to (i.e., no triggers, etc.), then heh, go for it. I would just as soon not. ;)

Seriously, I think the path that is most likely to work is one that is more flexible than Mushclient in terms of GUI, etc., with some clear XML or other types of "layout" support, which includes the capacity to log into an "updater", which can patch the files needed for a specific mud. I also think that if you are going to include sound, images, etc. something more like a tracker/torrent system would work, since even on low bandwidth you can often limit the bandwidth used sufficiently to allow at least marginally lag free play, while still patching. Right now you still have the burden on the server to serve up all the files *and* no means to "patch" a client to add new features. At best you have clients that are hand coded for a specific mud, then you have to download the next version of the client *every time*. The big MMOs got smart and allow two options for their far more complex games - "Download as you play.", and, "Download *first*!", depending on your bandwidth. Though, mind you, I sometimes wish I had the bandwidth to pick the later, instead of waiting for the patch to finish over 10+ hours on dialup. lol One would hope that a mud wouldn't produce that huge a patch.
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #134 on Thu 11 Oct 2007 05:12 PM (UTC)
Message
Shadowfyr, I couldn't agree and disagree with you more on pretty much all of the points you mentioned. If that sounds like I have split priorities, it is because I do. I personally love the amount of control that MUSHclient gives us in how the client works, and I would like to see even more control implemented, if possible.

Having to download a flash client every time you play a game would be annoying, especially if they get around the settings issue by just having you download the stored triggers/scripts from the server. However, if there is an option of storing the client (or even just storing your personal settings in a cookie), this problem is mostly solved aside from updates (which may or may not be as much of a hassle). However, there is something to be said for having an option of a somewhat robust client if you are at a library or a friend's house. I would not like it if a flash client was the only way to connect to my favourite mud, but having it out there as an option would definately be a nice option.

As for the updates that most MMORPGs do that take so long, a lot of that is taken up by the part that deals with graphics. MUDs and MUSHes do not have to deal with clipping issues or updating skins for new items. Even with a possible graphic pack, a large change would be a pittance compared to a small change in WoW or Guild Wars. As for the "World of Warcraft: Mega" part, Runescape is an attempt at making something similar to Diablo in a flash client. That game seems to be doing pretty well, but I agree that although the client is much smaller than I would have expected it to be, it is an insane waste of bandwidth.

Again, this is me arguing both sides because I could see the benefit of worlds having their own clients off of a website, but I would personally stick with my own client whenever possible. This includes me having a copy of MUSHclient on a USB drive for the past several years, mostly because I love having my settings with me with no wait wherever I go.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] 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.


109,742 views.

This is page 9, subject is 11 pages long:  [Previous page]  1  2  3  4  5  6  7  8  9 10  11  [Next page]

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

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]