Possible new client written using wxWidgets?

There have been various threads recently about proposed major enhancements to MUSHclient. Some of these are:

• Internationalization (already done)
  
• Improvements to the configuration screens
  
• Removal of lots of configuration items from Registry to configuration files
  
• 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)
  
• Better font management (eg. multiple fonts in output window, possibly graphics as well)
  
• Support for Linux and Mac operating systems

I wonder whether, rather than adding all these things into MUSHclient, it would be better to start from scratch (a bit like Zugg is doing with CMud, as opposed to enhancing zMud).

One thing that caught my eye a while ago was wxWidgets (formerly known as wxWindows), see:

http://www.wxwidgets.org/

This is a cross-platform, open-source set of GUI-oriented libraries (similar in concept to MFC from Microsoft).

Using that, a single set of source code could be used to build binaries that would run on Windows, Linux, and Macintosh, which itself would be a great thing.

Since it is open source there would be no big problems with writing a new client with it. Possibly wxLua could be used too.

Now I am well aware (more than most people I imagine) that writing a MUD client is a big job, however it might be worth it, compared to fiddling around the edges of MUSHclient.

I did a trial version a few years ago using wxWidgets, and got a rudimentary implementation going, before I got bogged down in problems of replicating things like multiple worlds being open at once. However times have changed a bit since then (hello, Lua!), and I think it could be a bit easier nowadays. For one thing, the goal would be to simplify a lot of the stuff that has built up over the years in MUSHclient, as I have added new ways of doing things, but retained the older ways for backwards compatibility.

Various things that could be simplified are:

• 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 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.
  
• 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 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.
  
• 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.
  
• Drop "custom colours" in favour of simply specifying RGB colour codes where required (eg. in triggers).
  
• 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.
  
• 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).
  
• 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.
  
• 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).
  

Now I realize there will be howls of protest about some proposed things, perhaps you love MXP, or are connected to 10 worlds at once all the time? However, remember the existing MUSHclient will still be available.

What I am interested in getting a feel for, is how much interest there would be in a new, cross-platform, open-source, client along the general lines proposed above?

If you are interested, please reply indicating:

• How interested
  
• Which operating system you are interested in (Mac, Linux, Windows)
  
• List any "must have" features - these are features, without which, it would be useless to you. (By "must have" I don't mean "the ability to turn my coffee-maker on in the morning"). Appropriate things to list might be: ability to open multiple worlds, spell checker, plugin support, MCCP support.
  
• List any existing features you don't use, or care about (for example, spell checker, MXP support, proxy support).

I am not necessarily promising to sit down and write this new client, but am trying to gauge where to best spend future effort.

# 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.
- Eh, works either way. Lua would simplify a lot of things though.

# Drop the various Windows Script Engine script interfaces in favour of straight Lua scripting.
- This could cause issues with people who have continued to use VBscript, Jscript, Python, etc. So long as a lot of these languages can continue to be supported, even just on Windows systems, this is a great idea.

# Drop the "macros" idea in favour of accelerator keys.
- Woot!

# Drop the "keypad" configuration in favour of accelerator keys.
- Woot!

# Drop the "default fonts/triggers/aliases" idea. This has pretty-well been replaced by plugins.
- So long as the Global Plugins stays, this is fine. I havan't used default triggers/aliases/timers since default plugins came in. The default colours and default fonts should be available though.

# 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).
- So long as there is some support of changing ANSI colours, sure. Lua tables can easily take care of ANSI and custom colour options.

# If multiple panes were going to be supported, design them in from the start.
- Another Woot!

# 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.
- That's still 10%, a significant amount. So long as MXP support is added back in again fairly quickly, the trade offs will probably be worth the annoyance for a short period of time.

# Drop the "multiple output windows" idea (Window menu -> New Window) - as this makes things more complicated in various places.
- Changing panels around could take care of the reasons to use this anyway.

# Maybe drop the "chat" system initially - I am not sure how many people use this.
- If it can be kept, it's a nice idea. I'm also unsure how many people use it, but you could always use the gAIM method for this... remove it and see how many people complain.

# Maybe drop the notepad idea - after all you can always use your favourite text editor.
- I like the notepads for storing text dumps and making notes before sending them to the mud while still being able to play. The only thing I really don't like about notepads is that they don't show up in the activity bar, and they kind of float around in the ctrl-tab order. Just makes it a bit harder to flip to what you were using. I have a few plugins I use on different worlds that rely on the notepad.

# Drop "custom colours" in favour of simply specifying RGB colour codes where required (eg. in triggers).
- Again, this can be taken care of by Lua tables.

# 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. I could probably deal with this, but there are times where people still like connecting to multiple worlds. - I've sometimes had a character open on Aardwolf's actual world, the builder's port, and the tester port at the same time. Immortals on the game will frequently do the same thing.

# 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).
- This would simplify some of the code quite a bit. I've only liked C++ when people use STL.

# Build in proper support for Telnet negotiation from the ground up, which would simplify things a bit.
- no opinion.

# 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).
- Depending on how this goes, everything sent to script could steepen the learning curve for new MUSHclient users. Send to world, output, and some of the other similar options have been useful to me for quick aliases/triggers for testing and showing people how to start off making aliases and such.

# 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.
- This would be a godsend. Again, as long as any other supported scripting languages can work as normal.

# 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).
- This would also lay in groundwork for adding in user defined buttons and such. I like it.

Multicolor text panes/windows are the biggie for me.

I've never used the chat system, and ditto with spell check - a significant number of mudders spell like retards or use 'net-ebonics' anyway, reverting to phonetics or 'Iyz in ur client testin ur triggaz' kind of thing, so the spell checker becomes somewhat redundant, as ironic as that may be.

The mud I frequent uses MXP, but it's not mission critical at all, just handy in certain situations, although I rarely use it to be honest.

I think a lot of users might have an issue with limiting one world per client, although personally it's not really a problem. Would having multiple clients open create issues when changing global settings though?

I use windows btw.

Hope that helps in some small way.

Hello. I'll probably only post once or twice, just to make sure that you have one more piece of feedback on your propositions.

* How interested

How interested am I? Very. Absolutely. I've been using tinyfugue and Trebuchet Tk for many years now. If MUSHclient had been available without having to resort to wine, it would've been my obvious choice. I do love tinyfugue, and I absolutely love Trebuchet Tk, but they have their respective downsides.

* Which operating system you are interested in (Mac, Linux, Windows)

Linux

* List any "must have" features: (not all are *must* have + mark), but some of them are *nice* to have(- mark).)

+ ability to open multiple worlds
- spellchecking (as-you-type) (via 'aspell list'?)
+ scripting support (via plugin? perl?)
- ability to run/terminate scripts in a sort of task list
+ triggers (ability to run anything from reactions in-mu*, to sound effects, visual-bells, external programs with the trigger as parameter - for example, to have synthetic voice output spelling out the trigger via /dev/speechd), highlighting, muting (regexp, colours, fonts)
+ customizable quick-buttons for actions withing the MU*
+ extensive logging functionalities
- SSL support
- clickable URIs run user definable applications to open them.
- plugin support
- per world configuration of logging, output (fonts, colors), triggers, buttons (having a way to chose whether any of that should be used globally or only on specific world(s)).
- scratch pad
- autocompletion for every word in the scrollback of a running connection, optionally cross-worlds.
- send stuff from a file or the scratchpad into the mu*
+ word search function all through the entire scrollback of current connection.
- log viewer?
- startup script?
- if multiple worlds are connected, ability to switch inbetween them with keybindings. (like <ALT>-1, <ALT>-2...)
- definable keyboard bindings (or typical pre-sets to chose from, so users can quickle decide whether they want their input window text editing done vi, emacs, word, or wordperfect style or which ever.)
+ notify of activity in background
+ ANSI colors shown

* I don't care about....
Not really sure, actually.

I hope this was a little informative. I know that list is quite length, but the client has competition, you know ;). Trebuchet Tk and tinyfugue do a lot of things *right*. :)

1. Everything set to accelerators = Thumbs UP!
2. Coloring Changes = Thumbs UP!
3. Plugin Support = Thumbs UP!
4. Language Only Lua = Thumbs DOWN (needs at least vb, js, perl, and python. I use Lua and VB (for certain COM tasks))
5. Everything through scripting = Thumbs DOWN (this will add to the learning curve as stated, as well as increase time needed for quick little additions)
6. Only 1 World = Thumbs DOWN (lots of people use multiple worlds at the same time, removing the Duplicate world window should not cause complaints. Although I CAN just run another session of the client)
7. Global Settings Reduction = Indifferent (I don't set things such as global plugins, fonts or things. I add each plugin to the world as needed)
8. Notepad Removal = Thumbs DOWN (I rarely use the notepad, but would like to see its continued existence for simple logging, or even just due to the "Fix Forum Codes" options, among other things that it can do)
9. Multiple Fonts/Sizes support = BIG Thumbs UP!
10. Simplify Script Interface = Thumbs UP! (as long as it still maintains a method for accomplishing the same or similar task)
11. MXP Support = Indifferent (Never use)
12. Chat System Removal = Thumbs DOWN (It CAN be used for more than just chat, such as the DB retrieval methods, and allows for a Queue-less communication system, that is independent of the MU*, granted you COULD use other IM services, but are not the same as the chat system (IRC would be closest))

Additionally...
Exposing the COM connection or even implementation of a DDE-like interface would be greatly appreciated, as it could allow external programs to be created as addons, similar to the Super Health Bar, among others. Or by exposing the COM interfaces you can, in an external program, embed a world file, very similar as you could do with a word document, or other things. This would allow for custom "skins" for the mushclient external frame, whilst still accessing the world in question via an even easier communication route.

Laterzzz,
Onoitsu2

I'd be very interested in a new 'MUSHclient'

I'd also, love to help with it anyway I could!

System: Ubuntu 7.04(Linux) Can run VMware, wine, ect.

Must have:



I'd request multiple scripting languages able to be used, much as it is now. I believe this feature, along with the speed of MUSH, are its greatest advantage. At the very least, continue to support python, perl, and lua?

I believe these are the 'most used' languages and wouldn't really draw too much away from the speed or OS compatibility. Every linux system comes with python, readily available through the interpreter, and windows user's could download it if they so wish as its done now. This way, the user could at least have two choices as to which language as to use, rather then be 'stuck' with lua.

Keeping the different scripting languages sounds pretty important to a few people I've talked with.

This was followed by an explanation that you can continue to use other scripting languages. I've had a few conversations like this with people who thought they couldn't run my scripts because they didn't use Lua as the default scripting language.

OK, let me explain a bit about sticking to Lua.

• Spporting the Windows Script Host (WSH) system for a client that is supposed to be multi-platform sounds kind of strange to me. How will Mac users get their Windows script languages to work?
  
• When I added in Lua support, since Lua doesn't use WSH, I had to write "glue" routines for each of the (approximately 250) function calls, to interface them with the WSH version. It would be tedious to have to do that again.
  
• If you are using the COM interface for scripts, it limits you to what COM supports. Thus, things like optional arguments, or arguments that can have different types, are hard or impossible to do. Also, functions can't return multiple things like Lua does. An example of returning multiple things is when you ask a function to do it, if it "succeeds" it returns a result, if it "fails" it returns nil, followed by an error message. You can use "assert" to check such calls.
  
• There have been reports of memory leaks when interfacing with scripts. Somewhere in the bowels of the WSH, and the way things are set up (eg. BSTR data types), something is not being freed up, when it should be. Using this proprietary scripting interface, and its proprietary data types, makes things harder to implement, and harder to debug.
  
• Let's do a thought experiment ... suppose (almost) all of the internal data in the NewMUSHclient (NMC?) is stored as Lua variables. This would vastly simplify a lot of scripting. First, when loading a world (or plugin), unlike what happens at present, the loaded world is simply the Lua table. It doesn't have to be copied, field by field, into C++ data structures. Nor does it have to be copied back when it is saved. So, instead of AddTrigger/AddAlias/AddTimer and so on, you simply directly insert new entries into the triggers/aliases/timers tables. To delete one, you remove it from the table. To disable it, you simply change an internal field. To find what triggers exist, you simply iterate through the table. Here are some examples of how you might do something like that:
  

  
  
  Add a trigger
  
     triggers.my_new_trigger = 
       {
       enabled=true,
       match="you are hungry",
       sequence=100,
       send="eat chicken", 
       }
  
  Delete a trigger
  
      triggers.my_new_trigger = nil
      
  Disable a trigger
  
      triggers.my_new_trigger.enabled = false
      
  Change a trigger option
  
      triggers.my_new_trigger.match = "you are thirsty"
  

  
  
  Looks simple, doesn't it? And no script function calls needed to be made.
  
• Quote:
  
  This way, the user could at least have two choices as to which language as to use, rather then be 'stuck' with lua.
  
  
  
  I don't want to get into a "language war", but I don't personally regard Lua as some sort of "second best" language, that is underpowered compared to the alternatives.
  
  Even supporting one other language could add significant extra work, since the concept of giving direct access to Lua data structures, rather than providing script interfaces, would not work if you had to support additional languages.

That is like saying you won't update because the chat system was added. You don't have to use Lua if you don't want to (in the current MUSHclient).

The confusion is that this other person thought the he would be forced to use Lua, and not the language he was used to. Several other people who didn't know that the world scripting language was separate from plugin scripting didn't want to load my plugins because they thought they would have to switch to Lua.

To be honest, the only reason I switched to Lua is because I was forced to with how wine was acting when I got my new computer. This was meant with grumbling and complaining that I'd have to use some 'crappy' scripting language instead of javascript. After a year, I'm glad I'm using Lua instead of javascript. I even got javascript working in Ubuntu, started running old scripts, then just converted them all to Lua and deleted the javascript settings. Most people get very attatched to their favoured languages, which is why they are so reluctant to change to a new one.

I'm all for everyone using MUSHclient converting to Lua, but some of the user base will be lost when they find out that they have to learn a new language to script. Even one as simple to learn as Lua. Granted, if they switch, they won't exactly find anything that offered as good scripting support as MUSHclient currently does, so they will be stuck with the old (now current) version of MC. Granted with the stability of MUSHclient, that's not a bad option, but nothing new will be added.

I'm very interested in getting something that will work smoothly on several operating systems. My primary OS is Linux, and while using Wine works, mostly, but there are enough annoyances that it would be nicer to have something with upfront support. But I also have occasion to use Windows and Mac machines, so cross-platform would be quite nice.

I do not have terribly strong preferences about many things; most of what you suggest makes perfect sense to me. But I would indeed howl if you removed MXP support. :-) While I think the protocol has a number of flaws, the ability to insert clickable links is crucial for many of my plans to make online building a lot easier. It might be a better idea to design a new protocol from scratch, and support that (on several occasions we have discussed advantages to custom clients for precisely this reason) but nonetheless not having support for basic MXP commands would be a show-stopper for me. :-/

# Use Lua for configuration files rather than XML.
No. XML is an industry standard for saving data and personally I feel switching to Lua would be not-so-nice.


# Drop the various Windows Script Engine script interfaces in favour of straight Lua scripting.
NO ******* WAY. I have always known I could use several languages. I tried each one when starting to use MUSHclient. I settled on Python. Why? Because some of my plugins have excess of 700 triggers with complicated logic, and Lua already makes me sick in a semi-complicated script of 10 triggers. To use Lua, it always means somehow re-inventing the wheel yourself and imo annoying syntax. Python gives me a huge standardized library, a very easy-on-the-eye syntax and more productivity: sets and generators are the simplest of things I can't think of doing in Lua without writing them myself or using a more clunky implementation.

# Drop the "macros" idea in favour of accelerator keys.
Sounds good to me.

# Drop the "keypad" configuration in favour of accelerator keys.
Sounds good to me.

# Drop the "default fonts/triggers/aliases" idea. This has pretty-well been replaced by plugins.
I'm not sure what you mean by 'default' things here. Is it pre-loading defaults from another world when creating one? Is it some stuff in Global Preferences? Anyhow, I feel loading defaults from other worlds should stay. Simply because it makes transferring settings to a new character easier.

# 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).
Sounds great.

# If multiple panes were going to be supported, design them in from the start.
Agree. Although add-on isn't so bad either.

# 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.
I think dropping support is not what you need to do. MUSH, as it is, is already quite small for as far userbase goes. Don't alienate the users that actually use certain features, since you'll only get more people that still use the old versions.

# Drop the "multiple output windows" idea (Window menu -> New Window) - as this makes things more complicated in various places.
I never saw a need for it. However, I think it is pretty useful, if you look at the traditional method of Observer-Observable taught in CS (even though that has its own flaws, too). Personally, I feel MUSHclient windows should no longer use MDI anymore, and make it 'optional' on whether they're contained. Although I can imagine that being quite difficult.

# Maybe drop the "chat" system initially - I am not sure how many people use this.
As I said before, don't drop features. Then again, I don't use this either.

(end of part 1)

# Maybe drop the notepad idea - after all you can always use your favourite text editor.
I don't see any issues dropping the notepad idea.

# Drop "custom colours" in favour of simply specifying RGB colour codes where required (eg. in triggers).
I'm torn on this one. I'd preferably have some kind of system where a use could these custom colour names in ColourTells and such, while providing a default in case the color isn't defined. That way, your users could essentially default the output on their screen no matter how they've picked their own colours. (I'm personally kind of annoyed with people using white backgrounds complaining my plugins are hard to read due to them using default grey.)

# 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.
Again, no go. I don't use it myself, but the part that I -like- about this feature is that I can still search the scrollbacks of other worlds easily. Another application means another taskbar button. Doubling of resources in other areas.

# 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).
No opinion. However, since I can't see a good other point to discuss this, I'm torn on using wxWidgets at all. I've never got to interact with wxWidgets, but I personally hate the look of other cross-platform libraries, which tend to feel far more clunky too.

# Build in proper support for Telnet negotiation from the ground up, which would simplify things a bit.
Sounds good to me.

# 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).
I see no issues with it. Make sure the GUI editor starts supporting editing of such functions in the worlds script file, though. Getting people to learn the concept of scripts is the most difficult one, since 'Send to Script' works wonders. Or, now that I read it again, do you want to do away with scriptfiles and triggers calling those functions? I'm against that.

# 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.
Simplify, yes. Only Lua: NO! Sorry to say it Nick, but I am not sure why every single suggestion or thread you seem to make as of late incorporates the 'only lua' concept. Optional arguments are nice, but nothing worth dumping other script languages for. Tables as arguments sounds nice, but where and when would you use it, and how effective would the gain be? And multiple return values, I don't like that either. Simply because it is another gimmick word to support the 'only Lua' argument, rather than adding something that gives a scripter something they don't have. Sorry for going overboard and being pretty much anti-Lua in this post (I feel it has its uses too, just not at the cost of other languages), but the entire post read to me as a Microsoft advertiment for XP and Vista saying DRM is in our own favor because it 'increases the experience'.

# 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).
I don't really mind, as long as what we get back is just as powerful. I've gotten fond of OnPluginSend, and I'd hate to lose my 'block this command' feature.

(end of full post)

I'm primarily a Windows user, and I mud from my Windows box (mostly because I never got MUSHclient working on my Linux box :( ).

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

That's an implementation detail. However, processing XML is only a chore if the language doesn't provide support for it (which I assume is the problem with Lua). I'd say, keep the XML, toss Lua. :D

• Drop the various Windows Script Engine script interfaces in favour of straight Lua scripting.

Scrapping WSH is a nice idea, however I write everything in Python ('cos Python > Lua :P) so multiple language support (at least to Python) is a must.

XPCOM or XMLRPC (or any RPC scheme really) would work but they're fairly heavyweight solutions for what we want to do :(

• When I added in Lua support, since Lua doesn't use WSH, I had to write "glue" routines for each of the (approximately 250) function calls, to interface them with the WSH version. It would be tedious to have to do that again.

Ick. That's what SWIG[1] is for. (I have Boost.Python[2] and Py++[3] because they make SWIG look tedious :D I think Luabind[4] is the same kind of thing.)

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

MXP equipped muds tend to be the more feature-riffic muds and hence have a disproportionate share of the total playerbase :(

The mud I play on has MXP (that kinda-sorta-works with MUSHclient) but I think I have all of the MXP features turned off. :-/

• Drop the "multiple output windows" idea (Window menu -> New Window) - as this makes things more complicated in various places.

I think multiple panes will do everything multiple windows would do anyway.

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

True for most people, though having multiple "worlds" for the same MUD is fairly common and I know of at least a few people who regularly connect to the live mud and the dev mud at the same time.


(1) If you use a sensible interface generator then the (Lua) world object is a proxy for the (C++) world object and no copying is done because assignment operations on the (Lua) members of the world object are translated to (C++) assignment operations on the member of the world object transparently.

(2) We want AddTrigger/AddAlias/AddTimer. Directly inserting entries into the appropriate data tables is Bad.

It makes the structure of those tables (an implementation detail) required knowledge to use the client.

It means you can't change the format of those tables without breaking plugin compatibility.

It makes it harder to detect (and debug) errors because you have no way of enforcing/asserting any of the (mental blank... object contracts? the concept that certain relationships within the object should always hold true, like a 'length' variable should hold the current length of its associated list and so on... in this case, match MUST be a string, sequence MUST be an integer). You might be able to work around this (and default parameters) with metatables?




What you really want is a system that allows for individually configuring plugins, ala Firefox and Thunderbird. At its simplest it could be something like the screen you get when you type about:config into Firefox (or opera:config into Opera): a list of settings and their current value (and maybe a description as to what they represent).

1. SWIG: http://www.swig.org/
2. Boost.Python: http://www.boost.org/libs/python/doc/index.html
3. Py++: http://www.language-binding.net/pyplusplus/pyplusplus.html
4. Luabind: http://www.rasterbar.com/products/luabind.html

Part 1/2

I personally would not use this new client, for many different reasons, mostly because you seem to want to throw out and change most of the features I use/like the way they are.


* Improvements to the configuration screens

I personally like it just the way it is.

* Removal of lots of configuration items from Registry to configuration files

Sounds good, but you don't need a whole new client for that.

* Extra panels (panes) for the world window (eg. statuses, coloured chat, health bars)

Sounds good, but I'm not giving up all sorts of other stuff just for thi.

* Better support for some things like accelerator keys (binding keystrokes to actions)

I don't see what the difference is, or what makes accelerators any different from macros and numpad, other than how difficult it is to associate a key combo to an action, I personally find macros and numpad config screens to be /very/ useful, both in appearance, ease to find, and as I don't want to have to script something to assign a key combo.

* Better font management (eg. multiple fonts in output window, possibly graphics as well)

This would be great, I've requested some stuff like this, but it's not a must have for me if I have to give up usability.

* Support for Linux and Mac operating systems

Doesn't even matter to me because I only use windows, mac sucks last time I tried to use it, and while I would kinda like to learn Linux if I ever have a spare computer to install it on, it would only be for compiling servers and such, and not for general computing, I would not be running clients on it if I could help it.




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

I personally don't like this idea, while it might simplify access by Lua, it could complicate it in any other language.

# Drop the various Windows Script Engine script interfaces in favour of straight Lua scripting.
Heck no, I'm starting to learn Lua(reluctantly), but I'm most used to JScript(Which I use most often) and VBScript, and if people have to learn Lua in order to script stuff, well, chances are most people won't be scripting stuff, unless they /really/ want to automate something enough to learn a new (what I assume to be)uncommonly used scripting language, or if they already are familiar with it.

# Drop the "macros" idea in favour of accelerator keys.
I still use the macros screen, and I fail to see the difference between them.

# Drop the "keypad" configuration in favour of accelerator keys.
No, I use that screen with just about every new world, mostly I use if for navigation, but I've customized it for other stuff, and if I have to manually type in the name of the key I wanted binded, or have to search through a list of keys, I won't be happy.

# Drop the "default fonts/triggers/aliases" idea. This has pretty-well been replaced by plugins.
I personally have never use default plugins, to be frank, it never even occured to me to use plugins, but I'd still prefer default aliases, triggers, and such, because they can be customized after they're added, unlike plugins which would need to have a copy made for that world and maybe customized in notepad.

Part 2/2

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

Uhm, I'm not to sure if I completely understand this one, so I'm just going to leave it be for now.

# If multiple panes were going to be supported, design them in from the start.

Yeah, sure.

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

I don't use MXP myself, since I'm not away of any MUSHes that use it(I think pennMUSH has been thinking about adding it, but hasn't gotten around to it.) and I usually don't MUD. Although I have been a couple places that use Pueblo before(even though most people have a problem with it, I don't see why, it seems to work fine, other than having to wrap @descs in <PRE></PRE> tags.)

# Drop the "multiple output windows" idea (Window menu -> New Window) - as this makes things more complicated in various places.

I suppose that's fine by me, I personnally was blissfully unaware of that command and thought it didn't do anything when I tried it.

# Maybe drop the "chat" system initially - I am not sure how many people use this.
I suppose that's ok, I've only used it a few times just to toy around with it, having to give your ip address out to other players isn't that appealing to me(I don't know whether to trust em or not, although I personally am not aware of anything bad they could do with my ip address since it's dynamic and changes when I connect to the internet, I'm sure somebody knows someway of using it against me.), although I suppose the chat system does have other purposes, like communicating info between plugins, or like that one thing listed about sending information to other people in your group or something.

# Maybe drop the notepad idea - after all you can always use your favourite text editor.
I don't use the notepad all that much, I mostly use TextPad, the only uses I might have for notepad is logging stuff to them, and I don't do that much anymore.

# Drop "custom colours" in favour of simply specifying RGB colour codes where required (eg. in triggers).
Uhm, I'm not sure, having to manually pick a color every time you want to change colors might be a hassle, I think it might be nice if you could select some 'favorite' colors and keep them within arms reach, and then maybe customize them on a per usage basis, but having to pick a certain color code every time... I do wish the custom colors let you select foreground and background seperately if that's what you mean.

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

No... my system resources are limited, I don't want to have two clients eating them up.

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

No idea.

# Build in proper support for Telnet negotiation from the ground up, which would simplify things a bit.

No idea.

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

Uhm, couldn't that potentially cause some kind of memory leak or something, or more processor usage?

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

I've already commented on your Lua only idea. Other than optional arguments(which can be worked around), I can't think of any use I'd have for those other things off the top of my head.

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

Uhm, no idea.



Anyway, I /think/ that's all I've got to say.

To keep it short I'm just going to reply to what affects me.

>Drop the various Windows Script Engine script interfaces in favour of straight Lua scripting.

Unfortunately all of my scripts are in Python at the moment. I tried converting them to Lua but its been a slow processes needing to learn a whole new way of doing things. I'd prefer if you could some how keep access to some other scripting languages.

>If multiple panes were going to be supported, design them in from the start.

Definately something I'd want.

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

I actually connect to quite a few worlds at one time. I'm a big multi-tasker and enjoy that feature about Mush. I'd prefer if you kept it in.

Oh and I'm primarily a windows user at the moment.

Ok, I'll throw in my two cents too. First off, Python can be linked in much the same way as Lua, instead of via Windows scripting, and it also has a wxwidgets version, so its more or less an interface issue with how/if you can duplicate some of the table tricks that are so handy when using Lua. If that can be overcome, then that is at least one added language that can be supported in a new design. Of course, what would really be nice is a "basic" clone that was wxwidgets capable, but... lol

MXP support - keep it. Mind you, I wouldn't mind having Zugg *at least* make a change to the implementation, such that you could do something like:

Can do MXP?
Will do MXP.
Supports strict?
Will do strict.

Where "strict" means the client acts like Mushclient does. So, no response would mean the behavior that Zugg's client has. There may be situations where having fallthrough is nicer than having to trap errors, but its a matter of taste, and it would lend itself to backward compatibility, with all the bloody muds in the prior MXP version that don't work right (since the default would be "fall through").

But in general, MXP is used by enough people that removing it isn't imho a good idea, especially when several of the recent posts on the TMS forums about clients have all been along the lines of, "What can we add to clients to help bring in more people?", not, "What should we remove from them?"

I happen to like the XML system. It means that other things can parse it, if needed. The only real problem we have right now is that if we are trying to hand code, nothing that exists *supports* the exact syntax of the functions for Mushclient (and adding that isn't entirely trivial in most of them), the internal editor is a control that doesn't work right (since its based on something that went out of useful application in Win 3.1, when 64k limits made sense, not that they did then either really), and there is no GUI system to edit things the same way as the ones in the main world. The later issue being imho, the biggest pain.

If we wanted to rework that, one might consider making the script in a parallel window to the triggers, etc. So that when you select a trigger, timer, etc. to edit it would also move to the "script" function called by that element, or show the code in its send field, if its not in the main script space. Cramming the whole mess into a single file, all of it script, just makes things worse for the casual user imho, and one of the things you are trying to do, by fixing some of the screwy function calls we have collected as things grew, is to make things simpler, not harder. ;)

Not sure how we deal with COM though. One of the biggest fracking pains in the rear using Firefox on Windows is its *lack* of COM support, which means most stuff won't work, and what does work only barely works, if it involves *using* anything that is based on COM. I have to open an IE tab 90% of the time to watch video clips in it, because 100% of all methods it has to handle running players fail too often to rely on it. One solution would be to support MONO, but that gets you into .NET, which means it might not run at all on machines earlier than 98, and I am not sure how/if it solved the problem of trying to use COM objects under Windows, where you *may* have situations where you want to talk to, and have talk back from, Windows applications that use COM to do that.

Also.. Some plugins *can't* be running solely in Mushclient, so some stable and straight forward means to get the plugin to talk to an external is needed. UDP and other solutions we use right now are neither straight forward, nor imho, entirely stable. Why do we need to do that? Because, not everything can run as a suspendable process, or as something that interrupts the client until it finishes. We sometimes **need** parallel execution, and short of creating a client script space that has restrictions on operation (like not being able to directly send anything to a mud itself), which can thus run in a separate thread, its just not possible to do some things using plugins, especially if it involves sockets and internet traffic, where delays may be in seconds, and responses can't be *held* until something checks for them.

I have to say, I agree with about half of your suggestions, mostly. The rest... I think is trying to fix issues by removing things that are complicated, rather than actually improving things by figuring out why they haven't worked right. The likely result is probably not a client I would use.

Oh, and one slight gripe. Mushclient uses Windows scripting, not WSH. The distinction might not seem like a big one, but WSH is a stand alone implementation, which includes several io functions not allowed in the embeddable version, and native event support, which is also not *natively* supported in the embedded version of any of their scripts. You can think of it as WSH-lite, or WSH-brain-dead. Much like other MS products, which work in one context, which 10% of the users actually find useful, but won't in the context that the other 90% are going to try it in. lol

There is also a wxJava, wxPHP, wxTCL, wxRuby, wxBasic (this one can be flakey)... I don't know how well some of these work, but it seems like there is an option for most of the languages currently available.


The part about xml is a good point, but the problem I currently have with everything being in xml is editing plugins. I have to swap the syntax highlighting back and forth between xml and whatever language to double check things as it is. And that's hinders things even more when the XML wrappers throw off the script language highlighting. At least if it's all one language, the parsers would have no trouble with it. Granted, this could cause plugin files to have to be named differently based on script language, with .lua .py .js etc, which honestly isn't a bad idea. It allows for quicker recognition.


I thought WSH was the first thing Microsoft released to deal with adding scripting into programs. It even came standard in Win98. Do you have any sites handy that explain the difference?

All that is different, that's not binding PHP, Java etc. to wxWidgets; it's binding wxWidgets to the scripting language (so that you can write your wxWidget application in that language). It's a little different to have an application that hosts several scripting languages.

That being said, it is possible to embed several interpreters into an application. It's just a fair bit of legwork to support several at a time, depending on how much you want to support.


Frankly I'm not sure I agree; Lua is very, very easy to parse, arguably easier to parse than XML, and besides there happens to be a parser that is very small and easy to embed into an application; namely, the Lua interpreter itself.

Besides, as somebody said, the config file is really more of an implementation detail and the vast majority of users wouldn't care either way. For instance, it will not complicate anything for other scripting languages.

With wxLua at least, it can do both. I just figured it was the same for the rest, but they might not have all the same functionality as each other.

from http://wxlua.sourceforge.net/docs/FAQ.html

hah! Found it. There's a wxScriptInterpreter class in script.cpp/script.h which can be initialized to either Lua or Python from the documentation I've read so far. No reason to think that there isn't currently or won't eventually be a way to use a class inherited from the wxScriptInterpreter class for the rest of the wx* languages. Personally, I just care about Lua, so I'm not going to bother looking it up unless I have to.

Here's the most succinct doc I've found on the subject:
http://wxcode.sourceforge.net/docs/wxscript/classwxScriptInterpreter.html

You are probably right here. I wasn't sure when I wrote that. I probably mean "Active Scripting" judging by what I read when I looked into it again.

Thanks for the comments so far, keep them coming. :)

I am getting the impression at this stage that a lot of people are happy with MUSHclient as it is, and in particular like the support for multiple scripting languages.

Hmm, that's good news. It still means, though, that you'd need to do all the legwork of providing your application bindings in all of the languages. It also means that Nick would have to do a lot more work to let people do the cool things he was talking about like directly manipulating the client data structures in their 'native' language.

[quote[It also means that Nick would have to do a lot more work to let people do the cool things he was talking about like directly manipulating the client data structures in their 'native' language.[/quote]
I think some encapsulation would still be required. Like having everything localized within plugins so they can't directly affect world aliases and triggers and such. I'm usually a bit wary of letting users directly manipulate data. Lua can get around some of the issues by using metatables to allow for the rejection of bad values, but I'm generally quite paranoid about data structures.

That's why you use an interface generator like SWIG. As I understand it, you write the C++ functions that you want the script language to be able to call (and the classes etc...) and then write the description file for SWIG, telling it what you want to export. Run SWIG over it and get a .cpp file for each language with all the tedious legwork done for you.

Most of the time "tedious" = "write a program to do it for me".

Looking over SWIG, it looks like we're comparing apples and oranges here. SWIG seems to just create an interface to the C code for the scripting languages. It does not appear to provide script support within the C program. Granted, I just poked through the very basic examples that were on the homepage. If it can go the other way, there's still the matter of needing a script interpreter which wxWidgets can provide.

SWIG will only get you so far. My understanding from following Lua list traffic is that it will get the most horrible leg work done for you -- writing the code that export the functions to the Lua namespace. But that's still unfortunately a far cry from doing all that needs to be done across all languages. My impression is that you still need a fair amount of manual tweaking with SWIG.

Besides, you still have the issue of needing to export the Lua data structures (that aren't in C++ to begin with) into the other scripting languages. For SWIG to help, you'd have to find a way to mirror the Lua structures in C++. SWIG definitely won't solve all the problems here, unfortunately.

Well, I am not sure where you can find a page to describe it. The scripting help file for it explains the main one, which basically amounts to looking through the list of functions and finding that IO like directory lists, opening and closing files, etc., are disallowed in ActiveScript. Also, CreateObject in WSH will, when it creates an object, also create a lookup table of event sinks in that object, which can then use a connection function to link the reference address for a script function to allow you to handle the event you link. There also seems to be some sort of differences between which exe you use, since it has a cscript.exe and a wscript.exe file... I would guess that one has different restrictions than the other, but I have no clue what those would be. Its kind of a screwy system, all done for what MS calls "security", never mind that they never seem to manage to truly secure anything that way. lol

Basically, WSH assumes the task of dealing with object events and IO, while ActiveScript **assumes** that the hosting application will handle those things more securely, so doesn't allow them to be done via your script, and in fact, in the case of IO functions, doesn't even provide them at all (while object event handling *exists* in ActiveScript, it just assumes that the host is keeping track of it for it).

Perhaps I misread.. if the proposed new client means that we can no longer use our external scripts if they are written in anything but lua, then that's a big no for me.. I use VB for that, and if the proposed client means having to rewrite 7 years of accumulated scripting to another language I don't know, then forget it, I just don't have the time unfortunately.

Yeah, I got it when Nick mentioned Active Scripting. I just hadn't heard it referred to as Windows scripting before. Either way, the point is kind of moot, since one of the benefits of wxWidgets is that it is cross-platform, and the only thing MS does evenly throughout the various operating systems is filing law suits.


I'm agreeing with this even though Lua is all I use anymore. Too many people like MUSHclient because of all the scripting languages available. This is certainly a huge concern, which is why a lot of people have been suggesting ways to support all or most of the scripting languages currently available.

I wasn't really imagining that existing scripts, in any language including Lua, would be useable, because a new client would have new interfaces. For example, unless it was a clone of the existing client (in which case, what would be the point?), then triggers/aliases/timers and so on would be a bit different.

Say we got rid of the notepad window and put in a pane attached to the main window - then all the SendToNotepad (etc.) function calls would not work. Say we got rid of the Info Bar and instead had an "info pane" which worked differently. Then all the calls to write to the Info bar would fail.

If you want backwards compatability, then the way to go is probably just enhance the existing client.

There is still a huge difference between changing the interfaces and having to switch languages while changing all the interfaces at the same time. At least with being able to keep the same language, the general flow of the plugin will stay the same in most cases. I don't think anyone is expecting to just drop their old plugins into the new client and have them run with no problems. However, having to start from scratch with a completely unfamiliar language on a very complex script is a different story.

Ok I keep hearing complaints about switching to another scripting language, and cannot understand the reluctance in doing it. I initially when using mushclient did not know Lua, but the moment I heard that it was cross-platform (as much as is possible) I stopped using VB, and learned Lua as fast as possible. I mean if you are familiar with ANY scripting language that mushclient uses, then you can easily LEARN another one, due to the massive similarities between them all.

Notice I did not say it would be easy to CONVERT them to another language, but the same scripting principals apply.

I LOVE Lua for the tables, as they are much easier than the standard (as standard as the term can be) arrays, and accessing of them. As well as the ability to import new scripts on the fly, unlike many languages that are a pain to use dynamic scripting features.

You all might want to consider learning it, not consider using it, but at very least learn a few syntax techniques that are used in Lua. I mean even the help file as it exists now makes learning the language very easy, as well as converting concepts and commands from one language to another.

Just my 2 cents,
Onoitsu2

Onoitsu2, I can't help but reply.

Yes, languages have a lot of similar features. However, can you tell me where I can find proper set behaviour for Lua? Generators? Read/write to the registry? Preferably without inventing the wheel itself -- Pythons extensive library of functionality is why I chose it over Lua. Like Lua, it is free to use, works on all OSes (except for MUSHclients implementation using Active Scripting, ironically) and I pretty much think the syntax is far more desireable than Lua's.

I know how to make my basic plugins in Lua. I also know I spend time looping through tables, implementing stuff like v_in_table(value, table) and similar. But for anything other than elementary scripting, I am very glad I'm not stuck with Lua.

Anyhow, sorry for the slightly offtopic reply. I'm just saying that Lua is not a solution for everyone.

While I agree that it's not really useful to argue one language's functionality over another, except for very objective concerns like presence of standard libraries (where Lua is (somewhat deliberately, actually) lacking), I did think I should try to address your concerns.

Set behavior:
Make a table. An object is in the set if the table keyed to that object is non-nil. An object is not in the set if the table keyed to that object is nil. Pretty simple.

Generators:
Well, I've seen this word used to mean several things, so I'm not exactly sure what you mean. Lua has closures, and so you can return functions with 'state', e.g. a function that returns a number that grows by one every time you call it. In fact this is trivial to do.

Registry access:
Deliberately absent from standard libraries; whether or not that is a good thing depends on your needs. You would have to provide this functionality yourself (or from somebody who wrote a registry extension). But, if you had such a thing written (and I'm sure it has been already) it would be a one-liner to include it.

Like I said, I'm not sure there is much point getting into religious wars about scripting languages, but I get the impression that you are knocking Lua more because you don't know it than because you've fully evaluated both languages. Syntax is one thing (I think it's a subjective preference issue, really) but you make it sound like Lua is only good for the simplest of scripting needs.

Yeah. Python is sort of an oddball in some ways. Basically, *it* includes IO functions, some GUI, etc., in its *main* system, since it presumes you are going to be coding applets with it, not just scripts, even if not everything you need to make truly complex ones exist in its standard libraries. Lua presumes you are, well..., just writing a script, not an entire applet. As a result, all the extra stuff Python has is relegated to "other" libraries. This also means, ironically, that half the stuff in something like the wx extensions for Python are *redundant*, in that they already exist in some fashion, if sometimes limited, in the main Python.

Its like complaining that you hate C++, because you can't just too the program, "a = new frames.window(blah)", or something, but you, or someone else, has to **gasp!!** actually tell the language what the heck the 'frames' class is, and what its 'window' function does. Yes, that is moderately annoying if you don't already have the library to do it. So what? It also means that you can, or someone else can, design one that does what "you" want, not what some person you never met thought it should do.

And just one point.. I am sure there are .ini style configuration libraries around, since that is more cross-platform than using the registry, so unless you are doing something dangerous (and imho potentially stupid, not to mention possibly restricted under things like XP or Vista), you shouldn't need to screw with the registry anyway. Why is it dangerous and possibly stupid? Because when you start making changes to code that handles that, its damn easy to forget a " or get something wrong, while thinking about something else, and accidentally scramble something else's data, your own data, or even nuke an entire branch of the tree full of keys (at least on older OS versions, where there *are* no restrictions on editing the registry and no "restore to previous state" function). Oh, and then there is the fact that under 95/98, the registry is buggier than a termite mound. lol

That's understandable :D Lua > VBScript for everything that doesn't involve COM. (Afaik VBScript doesn't even have a native associative array type? Relying on a COM object to get that functionality.)





(Example taken from the Python manual.)

The PEP (Python Enhancement Proposal) that described generators also includes a how-to for turning them into coroutines.


The _winreg library is part of Python's standard library, but then so is pwd and fcntl on *nix and Carbon on Mac OS X.

What I'd miss most of Python is the interactive mode that allows on-the-fly debugging


Syntax: yes and no. Most people think of syntax as a preference, but there are syntaces(?) that are objectively better than others. I haven't seen a comparison between Lua and Python. (I have seen Python vs C, C++, C#, Java, Ada and VB. Python pwnz0red. :D )

I won't say that Lua is only good for the simplest of scripting needs.

I will say that the most complicated (function points) script I could maintain in Lua would be much less complex than the most complicated script I could maintain in Python.


Tkinter requires knowing Tk. (And it is a full implementation of Tk not just "some GUI stuff".) Tkinter however produces Tk-looking components. wx produces native-looking components.


If you use "crippling" instead of "moderately annoying", I'd agree with you :P

In terms of programmer (me) effort, the difference between: (1) importing the necessary library (which is well documented); (2) finding a library that does what I want it to do (AND has adequate documentation) somewhere on the web, downloading it, getting it to work in my environment and then importing (and possibly converting between data types) and (3) hacking something together from scratch is something like (1) five minutes, (2) an hour, (3) upwards of six hours depending on complexity.

Trying to reimplement Python's _winreg in Lua (where "in Lua" may mean "in C, but with Lua bindings") could take weeks to months :P


Python has ConfigParser in the standard library for reading and writing .ini files.

Though, I am wondering why you say "use an external library" (which may or may not have working cross-platform implementations) in the previous paragraph and then complaining about the portability of anything built on the registry in this paragraph.


The Official Microsoft-Enforced Jargon for HKCU/HKLM/HKCC/HKU/HKCR is "hive(s)". Draw what conclusions you may :D

It would be trivial enough to provide a library that supports accessing the Registry, in Lua, however I am not sure I would want it to be available to plugin writers. "Hey, install my plugin and let me get full access to your Registry!".

In fact, as far as I can see, PCs (including Macs and Linux) have a fundamental flaw in their security design. They seem concerned about whether the user is who he says he is, and what rights that user has. For example:

• Who is the user? (name/password) - eg. is the user "Nick Gammon"?
  
• What is the user allowed to do? (eg. is he an administrator, can he install programs, can he access certain directories, etc.)

However it seems to me the germane question is: can the program be trusted?

Let's take an example, say I download a program that purports to tell my horoscope, or predict when the moon will be full again. I would be annoyed to find that such a program:

• Opened files in my personal folder
• Connected to a web site somewhere in the world
• Sent those files to it

Now, I am allowed to open my personal files, and connect to web sites, but I may not want some unknown program to do it.

I don't know of any security system that lets me specify things like:

• Unless I say so, this program cannot read files, except in certain directories (eg. its configuration files)
  
• Unless I say so, this program cannot connect to the Internet
  
• Unless I say so (eg. by saving a file), this program cannot write files

Note, that I am saying "this program", not "this user". I trust the user (myself), but not necessarily programs I get from who-knows-where.

With my firewall, I sometimes find that a certain program (that I have not heard of) is trying to make a connection to some site on the Internet. This is the sort of thing I am talking about. There have been cases a while back (probably is still happening) where when you play some game you bought, it is connecting to the manufacturer's site, and uploading information about the fact that the game is being played, and by whom, and what sort of PC they have, and so on.

Microsoft don't want you thinking about that. The Windows XP and Vista install processes both "phone home" to Microsoft with your system specs.


Most firewalls (ie everything but the Windows XP firewall) will allow you to control which applications are allowed to access the network.

*nix has trusted applications (that are installed in /bin/ or /usr/bin or /usr/local/bin and have the full rights of the user) and untrusted applications (that some user has installed in their home directory and can never have more rights than the user). If you're a superuser it's fairly straightforward to set up an application to run under another username, with no access to anything but what it absolutely needs. (This is SOP for http servers.)

XP (and Vista) will let you fake this by running the program with another user ... of course this is not easy and it screws itself up fairly regularly. It is theoretically possible though.


Blizzard and Steam are both famous for it. Most copy protection schemes are doing it now though.

More like a few minutes: http://www.lua.org/pil/27.3.1.html The registry becomes a Lua table. You can then use SWIG to create a module for Lua with the functionality you want. Lua is missing this because of the reason Nick mentioned: hurray security risk!


Vista seems to actually be trying this out, with horrid design flaws though. Programs, peripherals, and data files all have security ratings, and can only do things based on that security setting. Granted, the first answer I hear to "I can't get this program to..." is "Just run it as administrator." Being able to do this, to me, defeats the entire purpose of this security.


These are two of Python's greatest strengths... It seems like Pygeeks have made EVERYTHING into a library, including turning on and off the kitchen sink. It's the most extended scripting language I've seen. Python also forces pretty nice style into the scripts due to syntax, and it's quite easy to follow script flow.

I personally prefer Lua due to being able to create some weird, yet simple data structures. I assume that you like Python for the very same reason, so it's all a matter of preference. This is why you have someone who is a diehard Lua convert pushing for having more scripting language options in the client. Arguments over scripting languages are never really "winnable" since they quickly turn into personal opinion.

I don't think that's the Windows registry?

http://www.lua.org/pil/27.3.html
The registry mentioned here is a global table for storing static data from C functions. NOT the windows registry.

And access to the windows registry is less of a security risk than unrestricted write access to the disk. Under XP there are keys that cannot be changed without Administrator permission but user.dat can be trashed by any program.

Ah, got confused with registries. Either way, it is easy enough to make a module which uses a standard C library to access the registry. Lua meshes in with C extremely well.

Once again though, this is probably a moot point, since most information will have to be saved in a state file if MUSHclient becomes multi-platform.

Since I feel the Python vs Lua issue is derailing the thread, I'll keep this short and only mention why I needed scripting support. I got this little tool from someone that saves its settings in the registry. Depending on the world I have open, I want to adjust certain settings before starting it. I could rewrite the tool (don't have the source), but the tool does what I need, despite my silly workaround. (Btw, not everyone has a c++ compiler, knowledge of binding that and lua together in order to write a working regex interface. A link with said library is nice, but it is one more dependancy and source you may not be able to trust. All-in-one package for such things atleast gives me the 'I can trust this stuff' feeling, which loose libs will never have for me. But okay, I'm derailing again, sorry!)

In other words... I don't feel registry support (or other bigger features) should be a basic client feature, but the fact it is accessible through scripting makes scripting useful. You can't know the extremes some people go in scripting before someone has gone to said extremes.

I'm pulling these figures from a different thread, and they may be out of date, or even misleading (I'm not sure what is in each download exactly), but comparing sizes of script engines:

• Lua download (lua5_0r2_Win32_bin.tar.gz) 72.5 Kb
  
• Ruby installer (ActiveRuby18.msi) 4.5 Mb
  
• Perl installer (ActivePerl-5.8.4.810-MSWin32-x86.msi) 12.4 Mb
  
• Python installer (ActivePython-2.4.3.12-win32-x86.msi) 18.7 Mb

Lua is the only one that comes in at under a megabyte, in fact well under (like, 1/10 of a megabyte).

Looking at those figures, Lua is the only script engine you could reasonably include as "standard" with a client, because its size will have a minimal impact on the overall download size.

Maybe there are ways of including Python without needing to increase the size of the installer by 18.7 Mb, I don't know for sure.

However it seems to me that as soon as you say "in order to run this program you must go to www.some_script_site.com and then download a 15 Mb file (possibly giving your email address to start the download), and then install it", you are making it harder for people to use your program.

---

Anyway, I am sure Shadowfyr will be pleased to hear that I am looking at wxLua - this seems on the face of it to be a way of writing GUI applications with Lua as the base language.

Eh, maybe I am missing something trivial here, since I'm not all that awake right now. What prevents you from writing support for Python? If the interface is the same, you can just link against some headerfiles and be done with it, right?

Supply Lua as default scripting engine. MUSHclient (any client for that matter) needs a default sure-fire way to script in it. Merely leave the option there to use Python, Perl, Ruby and so forth if the user has those installed. E.g... like the current situation, except without Active Scripting.

Edit: Just looked something else up... Latest ZMud is around 6.7 MB, while the latest CMud is almost 10 MB. I realize size is important, but eh.. downloading a new mudding client is something you don't do daily, but usually only once. So what if it is a one-time 15MB download? Does wxLua support W95? If not, any pc after that should easily be able to deal with the storage space required. (Just an argument why size alone shouldn't be a deciding factor, but I fully agree with Lua being standard language.)

Currently MUSHclient supports all the languages you mentioned above, and yet is only a two meg download. There is a big difference between requiring the scripting language for the program, and requiring it for the plugins and such. Granted, people using Python will need to have it installed on their system, and they will have to go through whatever scripting engine is being used (causing some issues like the current memory leak with ActiveScripting), but this is obviously acceptable to the people who prefer said language.

Vista tries to *fix* the security issue also by not allowing any but system level applications access memory of any other system level application, which even XP still allows. Only problem is, they had to leave a *hole* in it, so that installers could set drivers as "system level", and let those do stuff that others are not allowed. This means that a driver can be crafter to not only **see**, but depriviledge any process on the system, dropping what ever secure application was previously inaccessable back to the level of the user logged in, as though you where still using 98 and had effectively full access to them. All I can say is, "Sigh!!". I means, its pretty damn hard to *secure* something which has relied for years on insecure systems to function correctly. Its **going** to break, and any fixes for the breaks are invariably going to breach the security. lol

This is ActiveState's Python-for-Windows installer and I have no idea why it is so big :(

However your point works even with the reference implementation (Python-2.4.3.msi = 9,462 KB and the latest, Python-2.5.1.msi = 10,714 KB) to which you need to add pywin32 (4,250 KB) to get the "same" install.

OTOH that includes more than 6MB of documentation and several libraries that you can probably skip for an embedded scripting language (IDLE and Pythonwin to start with)

The last number I remember hearing as to how much a Python scripting implementation bloated the executable was 2-4 MB? Which seems to be about the right order of magnitude ... and is still larger than my entire MUSHclient install :D

OTGH wxPython2.8-win32-unicode-2.8.1.1-py25.exe is 7,183 KB. I'm sure wxLua isn't much smaller.


I think the problem is that MUSHclient supports the languages by (dynamically) linking against Active Scripting which is guaranteed to be present on a Windows machine (>W95/IE4). Linking against the actual scripting language is a different problem... unless you dynamically link against the dll with a LoadLibrary(?) call and cope with its absence?

In any case, if Nick releases a(n open source) wxWidgets client with Lua-only support I'm sure one of us can hack support for the other languages back into it and release a patch against the source. :D

(Got to say, downloading the 100+ MB gcc toolchain/Visual C++ Express makes interpreter downloads look wimpy. :D)

Unfortunately, no. You still need to have provided bindings for all of the various whatevers you want to extend the scripting language with.

A few quick points to Isthiriel:

Sets:
Yes, Lua doesn't have a set library (that is intentional). But, and I know this won't satisfy you, the operations you described can be implemented in a number of minutes.

Generators:
That is a coroutine, and Lua can do that quite easily. I'm not entirely sure what you mean by saying that there is a proposal to turn what you showed into a coroutine.

Registry:
As I said, Lua deliberately does not include the registry because it is Windows only; in fact, Lua does not include anything by default that will not compile on a standard ANSI C platform. That being said, I strongly dispute the claim that it would take months to provide registry access. It's just a few simple API calls.

Debugging:
This is one area where Lua is lacking, yes.

Syntax:
I'm not sure what objective measures you are talking about, so I'd be interested in seeing them. I'd also be interested in knowing who ran the study. :-)

Lua for simple things:
Well, ok, but it's extremely different to say that Lua as a language is only good for those simple things, and to say that you as a programmer can only use it for simple things. I would dispute the former with empirical evidence, but I am happy to accept the latter. :) I am "read-only" Python, so I also would not use Python for much of anything but that has nothing to do with Python as a language.



And now for something completely different and back on topic:



It's not so simple as just linking against the scripting language's implementation. Every language has different ideas of how you're supposed to talk to it. Embedding Perl "manually" by directly talking to the language implementation is something of a nightmare, at least compared to Lua which is almost a 1-2-3 process. I haven't played with Python yet, nor PHP, so I don't know how things work for those.

Sets: I know. I've done it in C++. The point was that sets are a primitive type in Python so you don't have to.

Generators:Python gathers features by community request. Anyone can write a "Python Enhancement Proposal" and submit it to the development mailing list where it gets debated, etc... and the final form is added to the Python documentation (because they usually have useful examples as to why they should be added).

PEP 342 "Coroutines via Enhanced Generators" http://www.python.org/dev/peps/pep-0342/ is what I was talking about specifically.

Python also comes in a reference (CPython) and Stackless implementation and I think they can be treated interchangably for binding :-/

Registry: A hack that gets the job done and a library of similar quality to _winreg are two different things. Yes, it is a handful of fairly straightforward C++ API calls, and you only need to repackage them with lua bindings so the lua interpreter can find them and then test them. Given that this isn't my day job, a "month" of programmer effort is something like 30-40 actual programmer hours -- during which time I'd have to learn what it takes to write the lua bindings :P

Syntax: I'll see if I can find the site again, but the example I was thinking of was a time/loc comparison between various project groups for a university software engineering course. The groups got to choose their language and they had to write to a specification.


Yes and no. Lua is Turing-complete and is technically as powerful as any other Turing-complete language. That doesn't speak to how "good" the language is for programming large/complex projects.

I don't think Lua is designed for large projects. Python isn't either, but Python has a lot of glue features (and libraries) for interoperation with other modules and languages which help.


I don't think I said that it was. I was pondering whether it was possible at all to write linking code that could detect the presence of the script interpreter and activate itself as necessary.

Embedding Python is supposed to be fairly simple. It's something I've been meaning to try and haven't actually gotten to do.

Registry:
I'm not sure what features _winreg provides, but, it would be quite simple to bind a Lua table to the registry table by wrapping around API calls. But of course, if this isn't something you'd know how to do, it would take a lot longer than if you were already comfortable with the whole process. But then again, the same can be said of anything of this sort.

Syntax:
I'm not sure it's appropriate to proceed like those studies. When I program in a language, I want the syntax to be obvious to me both when I read and write it. I don't really care (as a user) how complex it is to specify a grammar for the syntax. And yes, C++ has nasty, nasty syntax as far as the parser is concerned. But I'm a human, not a parser, so I don't need to reason in context-free grammars. :-)

Besides, a language being 'clean' as far as a grammar concerned isn't necessarily helpful. I can write pristine context-free grammars that would yield a language very difficult for humans to deal with. So again, I'm quite unsure that measuring how easy it is for students to write a specification is an appropriate way to measure how good a language's syntax is. I guess it depends on what 'good' means. (I thought we were talking about how easy it is for users to write in it.)


Actually, I was referring to you personally, since you were talking about what you personally would do with both languages. I was not talking about what Lua is technically capable of doing, but what you are capable of doing with Lua. (And on the flip side what I am capable of doing with Python.)


Wasn't sure that you were; just wanted to throw that out there. And yes, I think it is be possible to do what you describe.


I've heard the same, yes.

I don't see how you can easily support lots of script engines, short of using the Microsoft scripting interface, which itself is working directly against the idea of making a client available on multiple platforms.

For one thing, each language has different facilities (sets in Python were mentioned), so some sort of "common" interface would have to use the lowest-common-denominator that is provided by all languages (eg. you can forget sets).

Already in MUSHclient there are two completely different ways of calling a callback function - the MS scripting interface way (where variables are turned into variants), and the Lua way (where variables are pushed onto the Lua "stack").



As I said before, I don't want to get into a "script language war", because choice of languages is rather a subjective thing.

However I would like to point out one fact, as opposed to an opinion ...

The MMORPG game "World Of Warcraft", which (claims to) have over 8 million subscribers, each paying around $US 15 per month (work that out!) chose Lua as its scripting language. Now, Blizzard is big enough to write their own language, or spend weeks evaluating the various languages available. One supposes that they compared Lua to Python, Perl, TCL, Java, and all the other possible languages, plus the option of developing an in-house one. Surely the fact that they chose Lua says something about the language?

They use Lua not only for end-user scripting, but the client they supply (the GUI client that displays you running around and fighting) has a considerable amount of scripting support supplied as default by Blizzard. For example, incoming chat messages are routed to various panes on the main screen by its supplied scripts.

They have documented their scripting interface (there are hundreds of them), which allows scripters to create additional panes, write to them, move them around, catch events, and so on.

There are thousands of end-user addons (plugins as we call them here), which do all sorts of things. There are plugins to manage raids groups (groups of 10 to 40 people on a large quest), plugins to manage your inventory, and your auctions.

Despite being implemented in Lua, there are very rarely pauses or slow-downs in the interface, excepting perhaps when you go to an "auction house" initially, when there might be a 1-second delay while the tens of thousands of auction items are loaded into memory from the disk database (a Lua table).

They also have the advantage that, since Lua is cross-platform, it also works on their Mac version.

Again, the more popular plugins supply multiple (human) language support, by having files of messages in English, French, and so on.

Blizzard does not support other script languages for WoW, just Lua. By doing so they simplify their work load. They don't need to develop methods for converting variables from one language format to another.

@ Nick : without having to read reams of technical info that I wont understand easily if at all, will Lua enable you to achieve what most of the MC users would like to see - that is, configurable panes with multicolored text, and with dimensions that users can configure?

Additionally, will it be detrimental in any way to the existing MC feature set, meaning that will some features not be able to be mirrored using Lua, or performance levels (speed) be adversely affected?

Also, will you still able to configure new aliases/triggers/timers etc via the client itself in the same way the existing MC does (Shift+Ctrl+8, Shift+Ctrl+9 etc)?

If Lua, as some have said, is relatively easy to learn if you already have some understanding of VB or JS, then perhaps it's not that big an issue.. some sort of import feature to convert existing trigger/alias etc files to the new client would be nice, then all that would be required would be for users to convert their own called scripts to Lua.. there's a good community here, so perhaps we could help each other out in that area.. there's already plenty of example snippets in the list of script functions on this site, which is great.

Appreciate you even considering all this. Cheers.

If I were to write a new client, that would be one of my objectives, yes - regardless of the scripting language.



The new client would not attempt to be a clone of the existing one, however I would expect features that most people find useful to be present.



Ease-of-use would be one of the important design principles.



Like I said before, it is hard to import existing things (except simple ones) without providing equivalent script routines to what is currently available. And do to that, the overall design has to be similar, so we are getting back to a clone then.

---

Just to clarify, I am toying with the idea of a cross-platform, cleaner, simpler client. One that is possibly written using wxWidgets, and has Lua (at least) for a scripting language. Possibly written using wxLua, so that the client itself is in Lua, so other people could modify it without having to download hundreds of megabytes of C++ compilers, and learn C++.

For existing huge scripts, I would stay with the existing client, which works perfectly well.

My objective is always to have code that runs fast - I grew up with PCs - if I can call them that - that ran at 1 Mhz and had 256 bytes of memory, so writing code that is compact and fast is pretty-well second nature to me.

All this reminds me of another thing I would LOVE to see, but figured it would be a large rewrite of what MUSHclient currently has. Currently, when you pop open the configuration windows, Your ability to send commands is killed, since the focus is set to the config menu. I would like to see the ability to cut/paste back and forth between config menus and the world window. This would also help when I need to make a somewhat involved trigger or alias while in a situation where I have to react to the mud fairly quickly. Granted, right now I can use the notepad to make an xml version, then cut/paste into the trigger menu, but I would like to just have the config menu set to alway floating on top.

Current benefit to non-Windows users... I can mark the configuration menu to exist on all window consoles of my X session, and flip through them to grab stuff off of the forums. For this reason, I wouldn't want the configuration menu to be forced to stay inside the client's main window panel.

Well, yes and no. If the new one supported omit, but differently, then there is no reason it can't be converted. Custom colors, instead of pure HTML colors? Just have the conversion look up the custom color and "translate" to the HTML color for that. And so on. Short of completely removing a feature, to the extent that no analog at all exists, and the behavior once exhibited is now impossible, there is no reason, in principle, why nearly anything could be replicated, by conversion to the "new" method of doing it, and that includes functions in scripting. Fact is, while we have a lot of redundancy, some concepts that where poor to start with, since it took some arguing to point out why it was an incomplete or maybe less than usable solution, etc., there isn't anything in Mushclient I can imagine wanting to "lose", just stuff that needs to be reworked, so it is done more logically, and with less half-functional redundancy.

Mind you, in retyping this a few times, one things does occur to me. We where previously badly limited to how we could treat things like triggers. You where/are suggesting moving to something that does a lot of setting/reading info about worlds, etc., using "GetInfo". Imho, this is a bit silly, given we are trying to change to something that is "easier" to use. Why not a different approach:



And stuff like that? Why use the clunky system that we where forced to deal with active scripts methods of dealing with things. It makes more sense, in an object driven system, to use methods that let you deal with the data in a way that makes sense from the viewpoint of the language(s). Mind you, it would require that all triggers are "named" so you can treat them as objects, which you can then reference, but.. Imho, it would make more sense than the currently screwball system we have, which has three methods for "making" a trigger, and at least three, maybe four, ways to change things in one, one of which is "manditory" if you don't want to just reimport the xml for one, but do want to change/set something that isn't supported in the other two methods of creating the thing in the first place. It wouldn't make much sense to do this in the existing client, but rewriting a new one, it wouldn't make much sense to "not" do it.

I don't think that it would exactly require all triggers to be named, just the ones that you would want to access in the fashion you suggested. Very much like how it is now, where you can have unnamed triggers, but they are not as conveniently accessible to functions like SetTriggerOption as named functions are. Also, if the triggers and aliases and such were saved as Lua tables, it would still require each scripting language to have a function to access the data (even just translating the data types back and forth) similar to GetTriggerInfo and such. On a brighter note, if everything is stored as a string of some sort, a Lua metatable can convert everything as needed, and toss back error messages as appropriate.

If we can stop worrying about which script language is the "best", for a minute, it might be more interesting to think about: "What features in a new client would make it much easier to use?".

Here are some ideas:

• Smart auto-completion
  
  Say, for example, you type:
  
  
eat

  
  And maybe hit a key like <tab> or something. Now the client could know (somehow) what you can validly eat at this point (eg. something which is in your inventory, and can be eaten). Thus, a small menu could pop up from which you select the item to eat. A similar thing could be done for "cast" or "walk".
  
• Smart "mouse-over"
  
  Say you have a database of mobs you have killed - you might mouse over a mob name in the output window and a small window pops up giving its known stats (eg. how hard to kill, what it usually has as loot).
  
• Mini-map generated from exits list
  
  A small map could be generated (similar to SMAUG FUSS 1.8) which shows the current room and its exits, and maybe nearby rooms, based on recent "Exits" lines.
  
• Plugins with dependencies
  
  Some plugins authors have written plugins which depend on other plugins being present. It would be nice if they could be auto-loaded.
  
• Auto-load plugins in a directory
  
  Rather than having to load plugins manually, by simply placing them in a certain directory they could be loaded for any new worlds.

What I am trying to look at is a good reason for developing a new client, and "it must support everything the existing client does" is not really that reason. After all, the existing client does that.

Seems to me that this would require some degree of cooperation with the MUD server. And I think that would be incredibly cool.

It would be a good opportunity to cook up a new extension protocol that focuses on text features, not "graphical" features (even frames fall into that category for me). It seems to me that the server should not be saying that it wants something in a frame -- you want the server to say what something is, and then you decide what you want to do with it.




Seems again that both of these would be easier with server cooperation.



While I don't use plugins too much myself, I think this sounds like a fine idea. You might want to look at LuaRocks, esp. if you plan on implementing this in Lua. There are some interesting issues with versioning and so forth that they're trying to deal with. (Unfortunately I believe the keyword is "trying", to a large extent.)

This can be done with minimal server input. I have a script I've made to track how many of various potions I have. I could easily modify this so that it would send a command to drink the most appropriate potion

Smart "mouse-over"
This would be a great thing to have as a user-controlled thing. I would love to have a mouse-over do various minor tasks if panels were put in. Possibly having 3 or 4 panels open, with the typing going to panel 1, unless the mouse is over panel 2, in which case all typing goes to panel 3. Odd example, I know, but it could have uses.

Mini-map generated from exits list
Having even a decent graphical mapper would be a huge boost for client use. Frequently I see people on the mud I play on ask about clients other than zMUD, and whenever another client is suggested, the first question is "Does it have a mapper?" Aside from Zugg's mapper, I can't really think of any that does a great job with it, especially one that's integrated within a client itself.

Plugins with dependencies
Could be useful. I just test to see if one plugin is active whenever another plugin is supposed to access it.

Auto-load plugins in a directory
This, to me, amounts to the same as having a list of plugins to load on startup. I can't really see the harm in including it.


Now for my own:
Password hiding
A friend of mine as over one day, and I logged in without using the popup password bit. My password was displayed on screen, and he commented on it being insecure. Although I changed my password (I trust the guy, but I always rotate my passwords anyway) and set MUSHclient to connect with a name and no password, I would like a way to prevent as many windows popping up as possible. Or even potentially use the same world for multiple characters. Might be a good idea to have an option to star out the second command entered.

Tree style alias/trigger display
An option to set up the trigger menu as a tree with the various groups as branches. It would help sort out things much better if I could collapse/expand them.

Multiple sort conditions for alias/trigger display
An ability to pick a primary, secondary, tertiary sorting field. That way you could do things like sort by sequence/group/label in that order.

Mouse over field gives info bubble
Toss in an option to make putting the mouse over a trigger's "match" field pop up a 'hint' with the full field in it. With limited screen space, it can get annoying to have a few really long triggers that all start identically. It's also aggravating to check the file path of a plugin.

Remeber last trigger/alias/timer
Have an accellerator able to pop up directly into the last trigger you were editing. Or keep track of the last trigger and leave it selected for the next time you open up the trigger window.

Another idea... far far down on list of things expected:
Console mode
It would be nice to be able to ssh into my computer and be able to use the same scripts that I have for a GUI client. I know a LOT of things would have to get killed for that, but I did say it was far down on the list.

And then the next time you want smart completion, you have to write up a whole new set of client-side scripts to handle this. The point in adding such a feature to the client, IMHO, is to avoid having to deal with this. Of course, a script-based completion system would still be an improvement, but it seems that there is more that could be done here.


This is something I asked for a while ago, actually... I quite want it, although it does introduce a number of complications. For some discussion, see: http://www.gammon.com.au/forum/bbshowpost.php?id=7261

That discussion seems kind of backwards to what I was talking about. I was thinking more like I could hop onto a computer, ssh into my computer, then open up MUSHclient in a text only mode, similar to tinyfugue or mudix. It could be based off of ncurses, which is multi-platform as well. I would especially like it if I could just connect to a running MUSHclient session via something like screen. This, however, would pose so many new problems, I seriously doubt it would be worth the effort.

The "time" part of the "time/loc" measurement was how much time they spent implementing new features as the specification evolved on them.

IMNSHO a grammar is "better" ("simpler", "more powerful", "more concise", ...) if you can write and maintain a functionally equivalent program with less programmer time.


Wouldn't the actual language interpretation be left to the embedded parser you're linking against? So if you don't write any script functions that require a set to be passed to them, you don't need to know if the language supports sets or not?


They've sold over 8 million boxes which is a good enough metric for me.

However, WoW is developed by Blizzard. I have no confidence in their programming team :(

WoW is King of the MMORPG heap because Blizzard spent more marketing dollars on it than most of the competition have so far grossed. Add to that it's Warcraft (a recognizable name) and the network effect (ie. I'm on WoW so I'm going to get all my RL friends onto the same shard). It would be more of an anomaly if it wasn't #1 for market share.

On a side note, Garry's Mod (for HL2) also uses Lua.

Sid Meier's Civilization 4 from Firaxis Games uses Python. EVE Online from Crowd Control Productions/White Wolf uses Stackless Python. Vampire the Masquerade: Bloodlines and Return to the Temple of Elemental Evil from Troika use Python.

Of course, Firaxis make good games but they aren't very good programmers. EVE is four years and something old and I think that demonstrates something. Troika died the one true and final death some time ago... but VtM:B is still being patched by the community to fix bugs that were present when the company ceased operations and the source code reverted to the parent publisher. That's impressive in my book BUT it doesn't really matter what language it was scripted in, just that it had a scripting language.

(Garry's Mod and VtM:B are both built over Valve's Source Engine.)


So was Bethesda when they wrote Morrowind, Bioware when they engendered NWScript and Gas Powered Games for Skrit (the declarative(!) language underlying the original Dungeon Siege).

I call all three languages abominations :P


One hopes. Unfortunately, being a games developer on a time table, it is just as likely they drew names out of a hat or picked the language the developers were most familiar with.

The Mozilla Foundation has all of their plugins (.xpi) written in JavaScript... primarily because that was the cheapest language to implement when it came time to extending the client ($0.00 as they had it already, they just needed to add functions for scripting the rest of the window).


If you choose to write the new client (and open the source) then if anyone feels the need to add Python (Ruby, Perl, Tcl, Java, Smalltalk, PHP, VBScript, C#, Ada, Fortran) support, they can.



Most of my timers/triggers/aliases/etc... don't involve scripting. They're simple Send-to various places or recolouring. I'd hope they could be converted programmatically to the new system if/when it's written and I migrate :)



Err. Weren't Altair 8800s clocked at 4MHz or so? And the "PC" (IBM 8086) was 8MHz/256KB?


Cooperation would make it easier (MXP already has the potential). It could be done without, provided you have triggers for every inventory interaction &c..

Further to that, the ability for Mud developers to produce their own plugins that possibly made the client semi-graphical ... like MXP on steroids and better integrated at each end :-/

Legend Entertainment made text adventure games once upon a time that had a static image for each room and images for each item. That's more than most muds would want and the Pueblo image stuff / MXP can theoretically do that already but it's something to think about.

Throw the current room description into a pane (with image?), put the current list of people in the room into another pane, items on the ground into YA pane (or different section of previous pane), redirect chat to chat pane, combat to combat pane... could be interesting?

That is completely subjective though. If you get someone who knows Javascript inside and out, and barely knows anything about Python, obviously the 'test' will show that Javascript is 'better.' Given Python's similarity to C syntax, a lot of people are going to feel more comfortable with it than Lua or VBscript, or Perl (the latter causing a lot of people to twitch).

Honestly, recoding a stat tracking plugin in Lua has proved to take FAR less time than the other languages I have tried this in, and it is much more readable. I could get rid of all of those crazy case statements that I had before, I have a much more simple method of changing settings, and even with the extra functionality and blocks of commented code and notes, it takes up about 70% the space of the three plugins it has replaced (all three with comments stripped out). I don't know Python, the same could be said about that language, but I have no basis to make any claims.


Blizzard makes some extremely good games from any perspective you look at it. So long as you ignore the fact that they postpone everything they release a good 1-2 years back because of 'setbacks' that they keep having. The thing you should be looking at with this example though, is not the game itself, but the plugins created by the user community. WoW has a very extensive list of plugins for it, doing pretty much anything you could possibly want. There are even highly effective levelling bots. None of these plugins take up terribly much room.

EVE Online also has an extensive plugin list, and from what I have seen of both games, the scripts for EVE and WoW are pretty similar for functionality. Both have easy to installation methods, and neither slow their respective games down an appreciable level.

I'm highly tempted to start a new thread on which scripting language has the biggest eNis now. That way this thread can be left for new features instead of just being a Python vs Lua argument.

Sorry Shaun, you're right, I read your post too quickly. :-) And yes, that would be very nice as well. I have very often wanted such a console mode, although I'm not sure how much of that is related to Wine's quirks.


Modulo the fact that you need to also bind the MUSHclient data structures and functions, yes. And what if you do want to pass in sets to the scripting language? Having to only worry about talking to Lua will make an awful lot of this an awful lot easier.

And as you say, if somebody really wants Python or something else, they're free to add it themselves (assuming Nick opens the source)...


Yes, it could be very interesting, and it's one of the things that has motivated discussions of custom clients in the past. But again, I think it's important that those decisions be made client-side, instead of the server dictating how to lay things out.


Then that test assumes that the programming teams are equally proficient, and all set out with flexibility in mind (as opposed to getting it done very quickly); it assumes they adopted comparable paradigms... basically I have strong doubt that this measurement is worth much. :-/


As Shaun pointed out, that measurement is completely flawed for practical purposes because it assumes a pristine environment in which the implementer is equally proficient in both languages. Since Shaun mentioned Perl, I could write programs in Perl oodles faster than I could write them in Python, but I wouldn't consider Perl's syntax to be "good" by any measure.


If we're going to debate Lua vs. Python (the discussion up to now has not, for the most part, been terribly interesting since it hasn't been about terribly objective things) we should be discussing precisely how the choice of one over the other affects the new client. And if that choice is irrelevant because people can just add Python if they want it, then we shouldn't be talking about this in this thread anymore at all. So I'll do my part and just drop this topic except insofar as it relates to what would and would not be possible in the new client. :)

Ok, mouseover sounds nice, right up until I ask, "So, what will is actually allow, just text?" Obviously the "standard" tooltip system is pretty limited. I would, if I where making something like that, want to at least allow it to be a true window, which I can add things to. I was already considering it nice to be able to display an "inventory" like the graphical games do, so I would also *personally* love it if such a tooltip was able to allow itself to be scripted flexibly enough that mousing over a special link would give the same image, along with the data on it, as I use in the inventory system. Not that raw text isn't good. Mind you... an MXP link could do that, sort of, since clicking it might trigger the server to send back the image + text on the item, which would normally be put into the output. Presumably, if there was some clear way to trap the data from such a link, one could trigger on a mouseover, send the request, trap the lines, then place all that, including the image, into the tooltip style window you pop open. It would require the cooperation of the server to manage. The only thing I could see in a client which "wanted" to do that, would be to add special data to such links, such that they behave based on what they "contain". Item links would, if you mouseover, give a tooltip, if clicked, would open a window showing the same info (or alternatively) attempt to use the item, but that doesn't work if the link is "embedded" in chat or such, where people are just talking about the item. The question is if you want to replicate that behavior on muds that don't support it, in which case you "do" need and internal database to check against that create links (which is going to mean slowing down the display), or which is checked against when you move the mouse over some word (possibly better idea, but it doesn't provide a visual clue as to *if* its an item you have info on).

The real question is, will the behavior be static, or trappable, so you can change the behavior, and is it server reliant, i.e., it would only work with an MXP mud, or one you can adapt, such as a "OnMouseOverWord" function, where you can trap the event and decide to show a tooltip after looking up the item some place?

---

Err. Weren't Altair 8800s clocked at 4MHz or so? And the "PC" (IBM 8086) was 8MHz/256KB?

---

I was thinking of something that predated them somewhat. :) I still have the manual, and scanned in the relevant part. Take a look, it seems I exaggerated a bit, it ran at under 1 Mhz.

It was an 8-bit address system, so the maximum memory you could have was 64 Kb, some of which was used for the internal ROM and peripheral devices. When I built it, it had 512 bytes of memory (2 x 256-byte chips). And, don't get me started on the "audio cassette interface", which is how you saved your files. ;)

Yes, internally the languages could do anything. I was saying that the interface to the client would have to use something that every language supported.

For historical interest, this is what my first PC looked like:

I have labelled the various parts - note the 1Kb operating system in ROM (nice and small, huh?), the 512 bytes (not Kb or Mb) of RAM, and the clock running at under 1 MHz.

Next, there is the keyboard and "display":

Note that you entered all your programs in hex machine code, by pressing the hex keys. Your output was shown in the 6 x 7-segment LEDs at the top of the screen.

Finally, after working with 512 bytes of memory for a few months, I splashed out and bought a 16 Kb "mother board" from Pennywise Peripherals, which increased my memory capacity substantially:

You can see from the date on that board that this all happened in around 1977. That board cost me a few hundred dollars, which was a lot of money in 1977 (like, a few weeks pay).

---

You can imagine that, if you only have 512 bytes of memory, have to enter all your code in hex machine code, and your PC runs at less than 1 MHz, you get into the habit if writing compact, efficient code.

What I'd like in a client is programmability, usability and portability.

Programmability: the ability to touch everything with the embedded language (in this case Lua). Support for regex are a given. Also, since I tend to throw a lot at Lua and I play on a MUD where response time really matters, have you looked at LuaJIT? Scripting speed is my main reason for choosing MUSHclient.

I think just having a few speed-critical or C++-library-facing sections written in C++, and the majority of everything else (i.e.: 90% of the code) in Lua would be great, since I could modify anything without needing to have C++ source and a compiler lying around. To test: just fire up the damn client, or reload a part. What a win.

I'd like to contribute to MUSHclient, but I've had enough C++ for one lifetime, and I don't like compiling either because it's such a killer on turnaround. There's a big different in mindset between fixing something on the fly and doing something in a compiled language.

If you add the ability to actually program the interface, that'd be an even bigger win (e.g.: the previously-mentioned wxLua). Almost every power user would be all over it.

Usability: I think the biggest problem with MUSHclient at the moment is usability. It's a great piece of software, but it's almost a case study in how to not design a UI. If you haven't read them already, I *highly* recommend The Design of Everyday things, About Face: The Essentials of User Interface Design, and The Humane Interface: New Directions for Designing Interactive System.

For example, a spell-checker in the GUI is a "yes, please" if it were easy to use. Microsoft Word-style underlining is a good thing; the current way I doubt anyone makes much use of.

Portability: I use Windows, Linux and OS X. Windows isn't going anywhere, but the trend appears to be gradually away from Windows (and with my next machine I probably won't be using it anymore either).

Separating the GUI from the back-end would be nice if it's possible, since I sometimes play through SSH and I'd like to have all my scripts available anywhere, or just leave it running headless. There are other benefits to this separation as well, if you consider the things it lets you do with the GUI and back-end relationships. Allowing a single back-end working with a single world to control an arbitrary number of windows would be wonderful. Likewise, a single window could switch between several back-ends running different worlds.

Oh, and one other trick: if the back-end is separate, I can use it for a more than just games and MUDs.

Random addenda:

I have never used, chat, and I never will. Everyone else seems to be using AIM or some other mainstream IM.

XML as a configuration language is plain wrong in my opinion. The only program that'll use MUSHclient's config is MUSHclient itself, and I have yet to meet a single person who uses an XML editor (as opposed to using an editor to edit XML). Its verbosity give us nothing in return, compared to the alternatives.

Mapping really is a crucial feature. It really is the first thing most people ask about. I currently use Imperian Modularized Trigger System, which is an external proxy that adds a pretty good mapper with a mediocre interface, but if MUSHclient supported that by default, I'd be even happier. It's not on the top of my wishlist though.

I use audio a lot. Please keep support for the bells and whistles.

Thanks for the comments - I am glad you like the speed of it. As for the UI, it evolved rather than got designed. However, I have seen worse.

> * Mini-map generated from exits list
> A small map could be generated (similar to SMAUG FUSS
> 1.8) which shows the current room and its exits, and
> maybe nearby rooms, based on recent "Exits" lines.

That is a feature I would definitely like improved. I'd really like a map that can handle places that don't always use North, South, West and East, but something like: "[Enter] Valley", [U]p the [T]ree, or [U]nderwater [C]avern, and other variations thereof, some using brackets, some using whole single words, some using other marks to identify obvious exits.

You see, a lot of mucks out there have rooms that are basically made by the users who play. Including their exits, and the way you actually have to type the exit name.

What I really would like is a way to create a map by moving around places in those mucks, a feature that *generates* a map *without* North, South, East or West. It could be sort-of drawing a flow-chart-like map on the fly. Or make it tree-like. Connecting-the-dots.

Can we come up with a method to do this sort of thing? Even if it involves a /map command that takes parameters like from-to exit names and the name of the current location?

That would be one feature that would make me slobber. Some of my favourite places have become so big, it is outright impossible to remember how to get anywhere if you aren't walking those ways on a daily basis. Annoying.

Automated mapping to that extent is something of an unsolvable problem in the general case, unfortunately. There have been several discussions here as to why, but a simple example problem is how to tell if two rooms with the same name/description are in fact the same room. You need to let the user intervene in the map, which makes the problem quite a bit harder since the GUI needs to be a fair bit more complex.

I shouldn't have said that. I'm sorry. :(

Let me restate how I feel: should you decide to make a new client, I hope the UI will be an important consideration.

I see a lot of discussion about programming here, and that's great from my point of view. I'm just concerned that UI might get less attention than it should, since the main audience appears to consist of software developers, a group that has other priorities.

Nick has repeatedly said that MUSHclient needs a GUI revamp. Starting off from scratch will be far easier to do than trying to make something that has to conform to the current MUSHclient code. This way the GUI and the code can be developed keeping each other in mind. I have no doubts that the new GUI will be much more easy to use and look at. The current one is ok once you get used to it, but it certainly could be better... it's the only downside I have for using MUSHclient.

I have always felt that maps need to be more than two dimensional, for one. I mean, first off, if you have up and down, then its **going** to be 3D at least in that sense. But more to the point, its not always practical to fit odd exits into the system, so dropping them under or over the room they go from, until the program can make a decent guess as to where the entire section its mapping should be, would be quite helpful. I see the problem as one of algorythms. Obviously, if you go up, then south 4, west 6, north 2 and then northeast, and you end up at the *same* place you entered from (assuming you tell the program that, 'yes it is the same room', then the mapper should be able to adjust the layer info to "show" that you went back down, by either adjusting color darker, or shifting the "coordinates" to a percentage of one unit. You can always go back later and adjust it so the "gentle slope" is where the height change happens.

In probably 90% of cases, it shouldn't be impossible to make an adjustment for where something should be, even if height changes happen, but it needs to involve "warning" you that its about to connect section A to B, or, if you say, "not now", "I am not sure" or what ever, then it should change the apparent color, so even if rooms "overlap", they do so in a way that makes it reasonably obvious that they might be the same room. Adjusting it later just means something like ctrl-clicking the two rooms, then right clicking to pick "link", on a context menu or something. The few times that won't work mostly involve teleports and the like. Point being, the mapper should only provisionally assume that rooms are the same, unless the threshold rises above some point, like 10 rooms that are identical in exits, features, etc., *after* you reach the first one that seems like its the same as one you where already in, and in the same general location (mind you letting the user always decide should also be an option). Hand editing is always going to be needed though, just because people design muds to trick mappers. The real issue is which format to use, boxes + lines, in 3D, where you can partly see the layers "under" and "over" them? Or, the other one is to show the "current" level clearly, then all "visible" rooms (not covered by others), as darker/lighter than the one you are on, with some visibility threshold, like 2 units above and below (normally two levels). That would be a lot harder to deal with imho, since it would be a fixed grid with only one view direction, but might work OK. Existing mappers don't even try to show things in a way that gives you clear clues about how far above/below you may be to something. You get lost, you get lost, unless you are lucky and 100% of the rooms you are looking for are on one layer.

Oh, and one other trick one could do in 3D. A search path system could not only provide a "speed walk", if you intended to run there, but instead also make the map locations "pulse" so you could simply follow the map to get there slowly. Most of them, if they support that at all, probably dim/hide the entire rest of the map, so only the rooms you are passing through are clearly visible. That is imho, not optimal, since you may find that the path accidentally leads through a room you don't want to travel through, so having the other rooms still visible means you could go around. As per the pathing in something like MMOs, it may also be nice to have it dynamically adjust the path, as you move closer, or take alternate routes around something, until you reach the intended location (or disable the pathing).

---

Oh, and to DMpk2k, a lot of the discussion about programming here is directed at providing ways to do UI stuff that isn't currently available, so, I presume, most of us agree with you. ;)

Up and down are still completely possible for a 2d map of a 3d area. This adds a level of complexity, but you can have diagonals for up and down for any mu* that doesn't have ne, se, etc. Something else could be done for those mu*s, but I'm not quite sure what. My clan uses diagonals for up/down when making jpg maps of Aardwolf, and it seems to work very well.

Non-directional exits are going to be the biggest issue though. They have no actual direction, so it's difficult to show them even on a 3d map.

As mentioned in another forum, the ability for a window to have tabs to hold different docked panels of display. Kind of like how you can tab through gaim's conversations.

I think that this feature would need to be toggleable on a per world basis, as I, myself, would prefer the a window that pops-up when a new activity occurs of that type, sort of similar to how a Query in mIRC shows by default.

The tabs is a nice feature, especially if you can filter things like inventory, obviously scripted to log it into that other tab, so that you can save having to press the inventory button (if you have one) or having to type inv. Also logging the worn EQ would be nice in the same fashion.

I am amazed at all the comments, and actually some of the ideas I would never have though of. Nick I think that this project, if this task is ever done, well it will probably be the best client out there just for its sheer feature set.

I chose Mushclient due to its scripting, and its "windows" default style of GUI, that and I think zMud having its own language that is FAR from standard is just HORRID.

The GUI could use some tweaking as for ease of use, but I tend to be a "traditionalist" when it comes to the look of the GUI, don't get me wrong, I LOVE the XP color scheme of titlebars, as well as the start bar.

As always, just my 2 cents,
Onoitsu2

I was thinking more of selecting a side panel that this could be done in. I personally can't stand having things pop up while I'm trying to do things, and I know others feel the same as well. One of the reasons I brought gaim up as an example is that it allows you the option of having a different window per conversation, or one tabbed window.

Also, to cover a message I forgot to comment on earlier, I liked the suggestion to have the spellchecker underline misspelled words as well. Especially with right click showing possible word options like Firefox and several other programs.

Another idea:
Have an option to check the client's server for updates on startup.

Have a plugin system similar to Mozilla's extensions. Have a website which is a repository of submitted plugins, and have the client be able to check for updates to the plugins. Yeah, this one is a bit of a stretch, but I'm treating this thread as a wish list :)

I like this idea, but then this will require the ability for the author to update the plugin that they submitted, via a system similar to the one in use on sourceforge.

It would help me to keep people using my plugins updated a lot easier than by making another installer each time I update something.

-Onoitsu2

About the problem with mapping in places without North, South, East or West, and the fact that the mapping algorith can't know if it's *really* in the same place or not:

I think it can still be done, but not fully automagically, you see. I would still be happy if I have a /map command that is flexible enough to aid the user in creating a map for such places on their own.

All the map feature would have to provide on it's own would be that it gives me the ability to know where exactly I am in the place, meaning, showing a map that is human readable. A flow-chart or tree, like I mentioned before. And secondly, if possible, be able to go quickly from A to B by just clicking somewhere on the map. The map should simply be drawn for me, and all the exit names should be stored, and where they point at. If you connect all the dots, or most of them you get a fairly accurate map with little effort - and that's the goal.

Well, as I said, some user input is bound to be needed in most cases, to verify the algorithms guesses, if nothing else. As for diagonals.. Sorry, but I just don't see it. Where I play we use more than just the cardinal directions, so it doesn't make much sense to use diagonal for up or down there, and I would tend to suspect that a *lot* of others use things like northwest (nw) too. Up and down make more sense imho as an icon, where the next "level" is clearly visible above the one where its pointing at. Think isometric 3D, which is just a 2D grid really, with each "layer" a set distance above the one below it. You have the "lower" ones hidden, the "upper" ones transparent, so you can see the current level clearly, while still getting a sense of where you are otherwise. Its not any harder than a pure 2D (or not much more), but has the advantage that you can more clearly show what is going on. And, with the right library, you would even rotate the view to any angle.

Full 3D would be more complex, and is probably not needed at all. The key is to allow the player to verify that the rooms "do" connect as predicted, or drag ones, like odd rooms which don't fit otherwise, to better places. The only real advantage 3D has over 2D isometric is that 3D could draw lines directly from one of those moved rooms, to the one it connects to, so you can clearly see what goes in/out. That isn't *quite* so easy without at least some 3D calculations, if you have to place the "room" some where other than directly adjacent to the one it connects to (which may happen). But, since any such support is probably going to use OpenGL, there might not be much point in only doing isometric anyway.

well for me.. uh.. i am interested in being mud client supported on linux(without using wine to run it...)

Building accurate maps would probably be even impossible on the mucks I'm on. Even if it was in full 3D with every bells and whistles.

The thing is, my idea of such a map doesn't need accuracy as in, visually showing that one room is in a specific direction. I'm already satisfied with a solution that draws rooms closer to each other on the map when they are indeed next to each other. The muck itself is a total chaos of user created content except for it's core. The user created rooms make up about 90% of it. The users never really cared much if a room was there or there.

They just connect them in the order they want, using exit names that represent the room names. Trying to make a directional map out of this will never work because there will be dozens of rooms that may or may not have to be drawn on the same spot on such a map. But if it's a tree-like thing, it's doable.

But I agree with everything you say about how difficult it is to actually generate a map from this. Definitely not gonna be easy. It's going to look extremely chaotic, because there are going to be rooms connected to each other that supposed to be far away. And I don't mean teleporter exits. Users make'em that way. As long as it works for them, playability outranks logic on that front. If you draw a map in 3D with dots representing rooms, connected by lots of lines, you'll see a mess on-screen, a total mess. Bringing order into that chaos - fully dynamically, that's another hard part. It should be flat and might even look much like circuit board.

Hmm. Well, logically one needs to limit the number of visible rooms to those that the program knows are within some specific distance. For a completely chaotic map, normal mappers are not likely to work so where, true, but then you could always support a more general map, which does a spherical projection, out to something like 3 rooms for where you are. If you path to some place, then everything "except" the rooms needed to get there go dimmer/grey, while the others stay visible. That sort of map would work in cases where the standard one doesn't, and can even work for a space based one. The only major problem, for either design, would be trying to show the "entire" mapped world/universe. That **would** require a complex predictive system, far more complex that needed to simply generate a "local" map of how rooms connect in the spherical system. It a isometric system... Since there is a clearer grid, with reasonable expectations of where things "must be", the predictive system only really needs to deal with the rare sub areas that require one. Unless some nut adds 150 rooms to the game, with *no* clear directions, this isn't that bad. And a few lines that go way off into some blank area, where the mapper can "find" some place to put it, wouldn't be any where near as bad as dozens or hundreds of lines. Most of the map, even in a user made world, isn't going to be impossible to predictively map, or adjust to fit better.

In other words, a hybred might be useful. One that is predictive, like the spherical system, when needed, but more generally predictive, by gridded locations, for 90% of the content. I am sure there are systems that can do that, the real question is if any are a) opensource or b) described some place, where they can be adapted to our needs. Making one from scratch would probably be a serious pain. :(

Well I have ONE solution to this problem, but it is by no means a good one... Anyone know ASM, and of the possibility of reverse engineering zMud, by no means do I mean a recent version, but the free version that has the mapper. That might shed some light on methods that have already been implemented, and then we can take those theories and "working" methods and implement them in mushclient.

-Onoitsu2

Surely you don't think this problem is so hard to solve as to require disassembling zMud to see how to implement a simple GUI? The problems are not technical, they are design issues of how to lay out a complex map, and how to create that map in the first place.

This is the reasoning behind disassembling zMud, is the methods used to "layout" the map, or the methods used to "predict" rooms. I am not talking about using the discoverd coding methods, but they sure as heck can be learned from. And as for the GUI area, that I won't think would be necessary, just the actual detection and data storage of the rooms.

I know for a fact that in the newer versions that you can open a saved map in MS Access, and it is a series of psudo-random numbering with at least a dozen sections per "room", and the first 6 sections are cardinal direction links, containing the room "number". The next several sections are dedicated to "non-conventional exits" which have pairs of command, followed by room number. There is also flags on each one that lets it know if it is a oneway exit, or a door, or a locked door.

I don't think that automatic mapping is something implemented easily, but perhaps have a method of "drawing" the map, like there is in zMud. I know that I've never had the zMud mapper work right to log the map, but if I drew it out using its keypad entry method. I could draw it in sections, then go and actually visit those rooms and it would log the information for those rooms, as they already "existed" and did not have problems with overlaps or duplicates, nor confusion of links.

-Onoitsu2

Well, I don't believe there is anything to be discovered about "layout techniques" by disassembling zMud than what you could discover by just looking at it. Same for room prediction. Besides, unless you feel like spending many weeks of your time going through the assembly, it won't give you much insight anyhow. My point in the previous post was that the issues we face are not at all coding issues, so looking at source isn't going to be terribly useful.

I do not endorse in any way the idea of dissassembling zMUD. For one thing, it is a proprietary product, from which Zugg is making his living. Even if you found an earlier version, the mapper code may well be the same as in the current version.

Apart from the ethics of the thing, zMUD is written in Delphi, and I imagine that the assembler code would be somewhat convoluted, to say nothing of the fact that you won't see the original data names.

It would take weeks and weeks of work, from a competent assembler programmer (who are probably a bit thin on the ground these days), just to work out the basics of what it is doing.

If you used an earlier version, you may well find that Zugg found a whole lot of bugs and has rewritten it, so you would simply be incorporating his bugs.

One approach would be to simply send Zugg an email and politely ask for the technique he used in his mapper, and if he would be prepared to share it.

Another approach is to simply work out how you want the mapper to work, and design it from the ground up. In doing this you might look at the zMUD one and get ideas (general ideas, not stealing the design), and see if there are places that could be improved.

Again, as no one seems to read my posts fully, I am not saying to USE it explicitly as it is implemented in zMud, as you stated Nick, "If you used an earlier version, you may well find that Zugg found a whole lot of bugs and has rewritten it, so you would simply be incorporating his bugs." Well this is completely folly to think such a thing, as the only thing that would be derived from this would be the method or few steps to a generic algorithm to create such a mapper. I believe that the ability to code the GUI is already there, as well as other features, but there has been quite a lot of debate as to the precise methods of "learning" or even gleaning the map. I am not for stealing coding, as that is quite wrong, BUT theories and methods from something that is deriving no profit, as it is a FREE version, can hardly be called stealing, it can however be considered using a "quality product" (sorry but *cough* *cough*) and creating something SIMILAR but in no way exact. Since there are many programs that do similar tasks, such as DVD to VCD (SVCD or AVI even) they ALL do things quite similarly, BUT are all by different companies, and initially only ONE company could have released theirs first, and all the "good points" were more likely than not implemented in the other companies releases, as it was already marketed.


Unless Zugg has a patent on the mapper methods themselves then there is no point arguing the fact that a "mapper" is in no way stolen intellectual property of Zugg, as well as the coding will be NOTHING like what he as used in zMud, but it will be a mental stepping stone in a better direction.

Sorry this went on and on, but I was interrupted many times by RL things, and my train of thought was broken repeatedly.
Also sorry if this sounds like a rant, but it is not meant to be one, it is meant to be a VERY strong attempt at a push in ANY direction on the mapper.

-Onoitsu2

There is a LARGE difference between reverse engineering and using the original code to create a program. Even just comparing someone else's code to your own can result in severe issues legally. The phrase "Intellectual Property" should also severely insult anyone who has an intellect, as it is one of the most insane concepts ever created by a legal team. Pretty much it makes any mapper created after looking at Zugg's mapper's code the property of Zugg, even if said code was not used. Regardless of whether or not the code is patented, it is copyrighted, and also covered by 'prior use.'

Creating our own mapper would probably be easier than trying to pick apart ASM, and it would most likely mesh better with whatever system we are going to be using. I can poke a few of my friends with computational mathematics degrees to see if they have any idea on how to have the map displayed in a sensible manor with various room exits which may or may not match cardinal directions. I'm sure they would appreciate getting an entertaining problem to solve during boring work days.

Probably? You mean absolutely completely certainly beyond any shred of doubt... :-)

Nick correctly points out that not only are good assembly programmers in short supply, and furthermore that it would take weeks of full-time work anyhow to get something figured out. And then more weeks to actually implement it. In all that time (probably a fair bit less, to be honest) you could have done it yourself.


Wait, why is it so technically hard to display the map? The programming for the display is relatively easy (assuming you know how to write the GUI code). The hard part is figuring out how to display the information in some sensible way; that is not really a technical issue.

As for the issue of correctly "guessing" the map, that is something for which you will need human intervention, plain and simple. Unless the MUD provides some way for the client to uniquely identify rooms (which is very unlikely), there will always be ways for the mapper to make mistakes, perhaps even because the MUD is intentionally sending confusing data. In this sense, the issue is yet again not a technical one of how to deduce the map, but rather, how you are going to let the human correct the mapper's mistakes and input the map themselves.

I think Nick is correct that the best solution is to (a) ask Zugg for his suggestions and (b) think about the problem from scratch anyhow. But if I may suggest something myself, it would be to try to keep that discussion separate from the more general issues of a new client, except insofar as it impacts the design of the client in general.

Displaying the information in a sensible way is what I would be asking people about. Trying to make a abstract map fit into a sensible manner in an efficient manor is going to be an exercise in discrete math. Selecting a way to sort out how the map is displayed should just need a little bit of GUI work and a few templates.

Asking Zugg for suggestions, or even just trying to see if we can get his mapper to work for this client would be great. I personally don't like zMUD, but I have to admit that Zugg's mapper is the best out there, hands down. I should see if I have my ancient copy of zmud floating around somewhere to poke around with it and see if I can get something working. Aardwolf at least has a nice way of telling if you are in a new room, so it should be easy to test there.

I still say that having a mapper able to be integrated into the client would be a good idea. Even if it's just a little panel off in the corner with very basic info displayed.

A note on "reverse engineering": Companies that do this either determine the *behavior* of a product, then recreate the behavior, code unseen, or *if* they do use code, they usually have a team, who will have no direct access to, or contact with, the people that produce the final product, dissect the code/product, then write a detailed specification. Someone else, who have had no contact with the first group, share no members, etc., then takes that specification and builds a product from it.

This depends a lot on if the intent is to produce "compatibility" or "replication". For compatibility purposes, which would mean something like having Mushclient generate "data" that Zugg's mapper would act on as though it came from the original zMud mapper, anyone can rip apart the program to see how it works. We however are discussion "duplication", the making of a competing product, which replicates the entire behavior, and doesn't need to be compatible at all. That sort of thing requires greater separation, if for no other reason than to protect against *claims* of code theft, and not just design theft.

Its not too hard to guess how the predictive system he uses likely works. Even similar rooms will "usually" contain a mob, object, etc. that can make it unique, not to mention exit names, so figuring out which room you are dealing with is *usually* going to be a matter of assuming that its on a set grid, then "predicting" that two seemingly identical rooms *can't* be the same if they "appear" to be 500 rooms away from each other when you come across the second instance. The only question, and this could be tested, is if zMud's mapper can handle situations where 2-3 ways exist to get into a room, some from 20+ links away, but it can't tell if its the same room until you then start moving through additional repeats outside of it. Either a) it can decide that it made an error and try to correct it, or b) it can't, since making such a predictions isn't all that easy to start with. The more complex issue is handling muds where the "logical" location of rooms might place them in the same locations as other existing rooms. That is why I don't think showing the "closest" by stored coordinate is a good idea, but rather that any "map" display needs to be generated by looking N rooms from the "current" room. The odds of two rooms, a mere 3-4 rooms apart, overlapping each other visually isn't too high, and if they did, a good mapper could still "adjust" the view, if in an isometric design, to appear someplace other than the same physical location as the other room it overlaps. The only real question is how much the offset should be, if its only a "this isn't the same room" display, not an actual change of altitude (going up/down).

I would suspect that zMuds' mapper has a more primitive method of handling up/down too, but can't say without checking, in that it probably "hides" all rooms not on the same apparent "level". I.e., if you go up, then everything below/above you is then hidden, and only the rooms on "that" level are shown. This is probably the only practical solution for a 2D flat display, which is why I think some sort of isometric system would be nicer.

I hope we aren't going too much against the purpose of the thread with all the map-talk. It's still mainly about getting a fresh start on multiplayform, right?

I'm not a fan of reverse engineering that feature, but why not talk to the author of zMud if it's that good?

I'm inclined to agree that the issue of the mapper is a bit separate to other things, except as a Good Thing to have.

I believe even in Zugg's case he has isolated out his mapper module to something called zMapper, so a similar thing that works in conjunction with MUSHclient, or a new client, could be considered.

Perhaps people with good "mapper" ideas might like to start a Mapper Thread.

If I may comment on the OT for a moment...

wxWidgets sounds ideal, although I'm always somewhat dubious about the snappiness of cross-platform widget libraries.

I'm interested in a good client for Windows, Linux and Mac - I currently use Atlantis on Mac, and tinyfugue on Linux, but they're both lacking in several departments.

I would really hate to lose MXP from MUSHClient. If it's really that hated/difficult to implement, can we see if we can produce something a little more standard-worthy? From what I see of MXP, it looks like a bit of a kludge.

MCCP is a dream for MUDs with many players, I'm told.

While making all the send_tos into script ones would be convenient, it would probably put off those who fear actual code(parenthephobia?). You could easily do it under the hood, of course.

Oh, and I've never used the spellchecker. Or the Chat system, but the Chat system looks interesting and I have some ideas I'm pondering for it.

Just to give some perspective, this is what we are up against, in terms of the type of client the games with large playerbases, pay to play, and custom clients are doing:

http://www.4players.de/4players.php/screenshot_list/PC-CDROM/4908/Screenshots/0/0/Aeonfalls_Online.html

This is obviously, from the standpoint of how you deal with the "rooms", a mud. Its development is currently suspended, according to their actual page, but I have seen other clients going the same way, including a long discussion of these very things on TMS. The way I see it, a client doesn't have to support all this stuff for most of them, certainly doesn't want them enabled by default, etc., but having the ability to do them... The problem with custom jobs is simply lack of flexibility. Not only are they going to limit your scripting, if they allow it at all, but you can't change the client behavior, add things you think are missing, or just redo the client for a different game. You can do all of that with Mushclient, as it stands, just so long as you don't want GUI elements or mapping.

People running large muds, which take in money, *are* looking to design clients that do these things. Smaller muds might like to see such things, but can't afford to pay for developers. I don't think we really need to have a *huge* gap open up between two different branches of the mud community. Mapping is certainly "one" of those things, and personally, I don't see the point in replicating, or using, someone else's design, instead of aiming higher, for something that is in improvement to it. Though, it might still be useful to allow an overhead view, for those that want it. Your going to be using the same algorithms in both cases, just that the 2D overhead throws out the layer over and under your current one. The layout functions would be essentially the same. If anything Aeonfalls seems to take the path of, "Lets only show where you are in a gridded area (if the screenshots are any indication), which just shows the weakness of such clients, they have to "Force" someone to use a specific design, rather than provide a flexible solution. And that is, I think, one area a user programmable client has a huge advantage with, if the basic for the GUI elements are in place to handle it.

Wow, that is about the worst setup of a screenshot page I have ever seen. I'm not sure what you are getting at for a comparison here for this custom client. Custom clients are really just a niche market per game. It's not like you can often take a custom made client and connect to a different mud with it and expect the same quality or anything. There is also no way to make sure that a general client has anywhere near the same benefits of a custom client unless there is someone who is constantly maintaining a theme/plugin/whatever specifically for that mu*. I think that any comparisons made for what to have in a new client should be against current general clients instead of any custom client which has been designed for only one game.

Also, with your 'layer' idea for mapping.. that has some severe limitations to it. Tower areas, for example. There are some areas in the mud I play on where you can go up 10 levels or so, and having a mapper need a layer for each would be much more confusing than other options. The following link is a map to an area with 9 up/down links in a row. This would be a nightmare to deal with in a layer system, but pretty easy to deal with in a flat method.
http://www.adverserealms.com/cgi-bin/emerald/cgi-view/openmap.pl?type=gif&file=dreadtower
The following link shows a large area spread out over several layers in a 2d method.
http://www.adverserealms.com/cgi-bin/emerald/cgi-view/openmap.pl?type=gif&file=hell
Granted, if the mu* you play on has more directions than the cardinal directions, there is the option of having a 22.5 degree line showing up/down, or some other method. Even having coloured stars or letters marking different points on the map that are connected like the dreadtower one does would be better than a layer if the layers do not always match up. For example: moving n,e,n gets you to the same place as up does.

Unless you establish some kind of protocol for providing data descriptively instead of prescriptively. That is, instead of telling the client what to put in which frames and in which color, you (= the server) tell the client that this piece of data is the inventory, and that this piece of data in the inventory data is an object, and so forth.

Basically, you describe the data, instead of just telling the client where to put things.

If a client could speak such a protocol, then any MUD could talk to it, providing whatever data they liked, and the client would have client-side layout engines for putting stuff where they would like.

And then the MUD, instead of providing a full client, would merely have to provide the layout logic to their players.

And of course, more enterprising players would be able to customize their layout if they wanted to. (This is, as I understand things, what WoW does with Lua and its GUI.)

This would still require either getting the authors of the client/server to write the protocol in a way that any client can interpret, or (as I said earlier) having someone maintain a plugin to interpret the protocol. It's not really something that we should be focusing on for getting a new client off the ground, but even now with the OnPluginPacketReceived functions, this can be vaguely emulated now. So long as the new client supports plugins, multiple panels, and scripting on a packet level, this should not be hard for anyone create a plugin to deal with a specific game.

Actual event handling is on my list of things I would like to see, and that would take care of any other issues on interacting with servers that have custom clients. OnMouseOver, OnClick, OnPacketReceived, etc would allow for fairly easy GUI inventory manipulation among other things.

Well, there already exist general data description languages, XML for instance. You don't have to specify all the entities in the language; you just specify how to, well, specify entities. And then the interpretation of that is up to the client-side engine, which presumably would be provided by the MUD server or by the technical-savvy client person. And for what it's worth, I disagree that this isn't something to be thought of early on, because it could have potentially very far-reaching consequences for the client's design. And also, part of the point would be in creating such a protocol that other clients could presumably use without having to resort to plugins -- and besides, said plugins would need to have a great deal of access to the client's GUI to make what I'm talking about possible.

If what you are suggesting is creating a whole new protocol for mu*s to use, then that is a completely different topic than just creating a new client. I am not so sure that many existing muds and mushes and such would switch to a new protocol simply because we or someone else created it. There are already several protocols out there that can be used which do specify inventories and chat channels and such. Few games actually use these, and instead stick to straight telnet. I'm not saying that this protocol idea would be detrimental, I just don't see it as being widely used. Look at MXP. It was a great idea to allow for images, hyperlinking, font changes... but only 10% of muds on mudconnector use it. And this is a protocol which has been around for quite a while and it is supported by a decent number of clients.

Also, having such a great deal of GUI access in plugins is something I would love to see. If you are going to allow all these neat images and panels, you might as well do it all the way and allow people to actually use them instead of just being out there to look at. I think more people would find GUI manipulation more useful than adding a protocol that no games currently support.

Can't MXP be used for the data description anyway? You just need to specify a canonical list of entity definitions that your client will parse appropriately.

Most of the muds that are on MudConnector are very close to stock. If more stock muds had MXP built in that would be reflected in the stats on MudConnector. As it is, there are no MXP libraries for drop-in support so every mud that has MXP has had to roll their own version. :(

Well, yes, but also consider that this is a one-in-a-million chance to have a client developed around a protocol that you or I might want for our MUD. I have several motivations for having a custom client built, but I don't see a huge point in making a client that only supports one MUD.


Perhaps, but that would be a natural consequence of what I'm suggesting, because to support the protocol would necessarily mean near-total scriptability of the GUI.


Sure, in the sense that MXP looks a lot like XML in many ways. But MXP has enough serious flaws that I would find it better to distance this from it, if anything to make it clear that whatever comes of this isn't MXP.


Nick has one, along with a tutorial on installation IIRC, although it's only publicized in some parts of this website.

Yeah, screenshot page stunk, but you should have seen the one on some other site, where every large view of the pages was 404. lol The *main* site for the game is down at the moment, so I couldn't link there, where I would hope they had better examples.

In any case, not sure MXP would work better than a protocol specifically meant for it, but any such protocol would still "lock" you into presumed default ideas. Maybe someone would have something *other than* inventory type things? Not sure MXP entities are entirely good enough, but yes, something *similar* would be the right idea. In the best world, I suppose you might want to send a "layout" description, rather than an "entity". The layout would provide how things get placed, along with field names, so data can be inserted where needed. Then any further data sent would reference that "layout" and tell the client what to add/remove from the subfield in that display. You don't get stuck with one size fits all displays.

Now, this **could** probably be done, with some clever manipulation of MXP entities, but its not really designed for that. You could also use the "error" traps that Mushclient has already, which I presume would carry over to the new client, to capture unrecognized tags that "did" support a <layout>some_XML</layout> type data block, then use a plugin to parse the resulting layout/fields to the client GUI. This is a more advanced handling that what I had always envisioned. My own thought had been to do something simpler, like having the user create a .frm type layout, which the plugin could parse in to generate a window, then use normal triggers to do something like capturing the "inventory" when you look at it, and parsing it to display the right icons. Clicking on food, etc., would have its behavior defined by if the event for that icon is trapped, and what the script says to do about it. The only thing that adding a "layout" tag to MXP would really do is provide an inbuilt way to generate the GUI, based on the mud developers version of what it should look like. This is a good idea, since some place like Aeonfalls could have simply designed the GUI elements, provided a plugin to handle data parsing for those elements, then changed the layouts on their end, as needed, instead of doing a client update (or forcing the users to download an upgrade). The client itself could be as generic as TinTin++, and as long as the scripting was available, GUI was available, and MXP, with the added layout functions, was available, you could make it *act* like anything from the current Mushclient to one of these custom jobs.

---

As to your map examples Shaun.. They don't even work in 2D, since they require intentional displacement, and special markers, to show them on the *same* 2D plane. Not only is it unlikely that a mapper could do that very well, it doesn't do anything for you, if you don't have an entire extra display available to put the map on. The reality of text gaming is that, if you want that kind of map, you are **not** going to be using the internal map system to do it. Heck, even the MMOs have entire printed Atlases, since the maps they provide in game are flawed when trying to do this, and that is despite attempts in EQ1 to have a way to auto generate the maps, based on where the player marked the start and end of the path they walked on. It worked, but not well. The new one in EQ2 doesn't even bother.

Fact is, for a text world, **most** maps are going to be limited to a fraction of your screen space, and even if you allow for them to pop open a much larger version, to get their bearings, you **still** can't give them a map that is good enough to cover areas past some X number of rooms from where you are.

Mind you, in your tower example, it might not be impossible to find some way to pop open that bigger map, and thus *see* all 9 levels, stacked one on the other, just like looking at the skeleton of a sky scraper. That could be practical. It might even be possible to mouseover the levels, and thus get them to show up clearer. And, as I said, one useful trick would be to have the path finding system "mark" each room between you and a destination, so you can see where you need to get to. I wish I had an easy way to show what I mean..

I can apply all these statements to the layer idea. For the example I gave earlier, where n,e,n will land you in the same place as going up, how would a layer show this? There would have to be some sort of intentional displacement or marker to show that the two layers do not match up. Now imagine trying to do this with some sort of maze area where this will happen several times. If leading off of room1, you have the following exits: n=room2 e=room3 s=room3 w=room4 u=room2 d=room4 and then in room2, you have a variation on the same pattern leading to rooms 1,3, and 5. That map will be a nightmare to try and put into a 2D or 3D model without having some sort of special markers. Even the one quirky exit at the bottom of the decent to hell map would extremely difficult on a 3d map because the two south exits would have to cross each other.

Also, claiming that the maps I gave as examples would not be effective without an entire extra display available is not changed by making some sort of 'layer' effect. All you are doing there is forcing parts of the map to be invisible, which is the same as showing just a portion of the 2D map. If you think you can fit all of either of those maps into a 3d version that will fit into a 200x200 pixel area, please make a jpg of it and post it. I'd be very interested to see how that turns out. As it is with the dread tower map, the only real reason for the special markers is to make it fit better into a rectangular jpg without wasting a lot of space. This problem would go away in a display on a mapper because it will not have to display all the data at once.

A simple bookmarking system for specific rooms would be fine for 'getting bearings' in either a 2D or 3D map. Either way, trying to map out such abstract areas that are found in muds and mushes will require some concessions to be made, since the rules of geometry do not always apply.

No matter how this is coded, people will still have to maintain some sort of theme package for the client if they want it to work well with their servers. Using non-stock images, having various actions for combining or enchanting items, even inventory slots and character creation will all have to be modified to some degree per game. A lot of this can be done through downloading files from the server through the client. It would amount to the same as having to download a theme package from the game's website and having that world use it, but with less mouse clicking.


Making GUI manipulation a more open environment where a script can play around with settings much more than the current closed environment of MUSHclient would solve most of the aforementioned issues. In fact, it would almost be required for any of the new options this protocol would open up. However, it is not required to have this protocol in order to make use of a more script interactive GUI. I cannot see starting off with a protocol like that without having the base scripting in, so it is only logical to focus on GUI manipulation before getting into any creation of a new protocol.

Presumably if a server is speaking the protocol, they are willing to maintain their 'theme package' to take advantage of it. The possibilities opened by such a thing are huge.


I'm not sure what you're trying to say here. You could just as easily download the 'theme package' (I'd think of it more accurately as a layout engine since it does a lot more than change some pictures) from inside the client as well. Besides, it's a one-time procedure. Saving 2, 10, 20 clicks isn't a big deal.


Yes, that's what I meant when I said that it would be a consequence of what I'm suggesting. What I'm suggesting is basically impossible without it.


This is true.


The point is simple: knowing what you're designing for allows you to, well, design for it. Sometimes knowing what the end goal is allows you to better focus your efforts.

Ok, let me try to sum up what I've been saying, since you have repeated a few of my points and then said you didn't understand what I'm trying to say after quoting something that meant exactly what I've been saying...

The protocol idea is completely superfluous.

• Anything that this protocol would need is a good idea to have in the client anyway.
• The protocol can be made as a plugin which checks incoming data packets.
• I believe it would be a waste of time to start off with this specific protocol in mind, as it would not be anywhere near as widely used as you seem to think.
• I still think it is an interesting idea, but because the new client would hopefully have all these features in place to begin with, having plugins for various protocols should be easy to implement. This would open up more options than focusing on just one protocol.

Being able to support MCP, MXP, IMP, MSP, even mudFTP would be great for this client. If a better event driven scripting environment were to be created, these could all be easily added in as plugins. Kind of lick language packages for various programs.

Well, as a disclaimer, I never said it'd be widely used. (In fact I expect it to be something of a niche market.) That said, I think this point is probably the most relevant. I maintain that knowing what you are going for can be very important, instead of just providing a general-purpose scripting interface. That, and making it into a protocol allows for standardization, instead of a bunch of plugin authors running amok creating different ways of handling every MUD's way of encoding the data.

A protocol doesn't have to be anything fancy, you know.

But in the end of the day, I really think we are talking about the same thing, by the way. You keep talking about plugins to handle this stuff, which I have been referring to as the layout engine. All that I'm proposing on top of you is that the data sent around be in a standardized form.

Yeah, in either system. I wouldn't suggest not letting a person scroll away from where they are, for example. 2D or 3D you lose the ability to see certain areas. 3D imho, does provide some capacity to display things that 2D can't. Neither can "solve" the issue you are talking about, since both need to limit what they display. Ok, lets be clear about one thing, a 2D in a 200x200 area *may* be a real good idea, since its too small for a 3D system. But, lets assume for a moment that, as part of the mapper, you added a accelerator, which could open a larger version, which is like 3-4 times bigger, which did do 3D, and could show more rooms total. Lets also say you could rotate it around, to get different views, etc.

The two are not mutually exclusive concepts. One have benefits the other doesn't, and vice versa.

As for making up a jpg to show the idea.. I am not that good at translating the "idea" into results, when drawing things. In fact, I suck at that. lol Now, if I was coding it... probably not so good there either. But the point is to give options to how to display things, not lock someone into the "assumption" that every system will work with a 2D system, or as well as you seem to think it would. I mean, think of it this way. Your "tower" example is less than what? 20 rooms **in** the tower, and a lot branches off in absurd directions. I have a tower I planned, but never got around to doing, that would have had 9 levels, each with about 10 rooms at the base, to like 2 at the top, not including balconies, and the "stairs" where all located like this:



Now, you *could*, I suppose displace all 9 levels diagonally ,with a different colored line showing the linked rooms, but we are talking about about 10 rooms each floor, or roughly the *maximum* radius a map could display, so, for all practical purposes, you **still** can't see more than one at a time. Now, imagine that instead of 2D, you could switch to 3D. Then you have a view like this:



Yes, of the "size" of the level is big enough, it may be necessary to still limit the number of "visible" rooms, and maybe fade the ones farther away, but it gives a way better view than one that looks like:



Where the extra / are the "lines", showing where the up paths lead. There would of course need to be similar lines to show where the "down" links went, but you **can't** see any of the rooms they go to at all. They would be outside the range of what "can be shown" for where you are in such cases. 3D lets you see where you are now, where you could go in all directions, and a lot of what may be under or above you. Its not perfect, but 2D could be worse. If you get what I am saying here. I mean, even if all it did was show rooms one level "under" yours, with a ability to move up one level, you still get a better sense of location in *some* cases. I am sure there are ones where 2D is better too, which is why it would be nice to have "both" options.

Can we please have the mapper discussion in a separate thread esp. when the posts are getting so long. :) It's a huge topic in and of itself, and both it and the new client deserve their own threads.

lol That may be a good idea. Though, mind you, until we actually get to trying to implement something, its mostly just and argument over "if" something will work, in theory. It is kind of tied to the client itself though, since a client that supports good GUI only needs some way to handle the "general" map data, since display can probably be handled through the GUI elements, using what ever method the developer wants. I.e., having the mapper also do the display limits what you can do at all. On the other hand, it still means we need two types of plugins, one to deal with "mud related" issues, while the other deals with interfaces. Why? Because the interface one needs to operate independent of the main thread, so it doesn't hang the system. only having one class of plugin either means making them also all operate parallel, which would cause issues with synchronization, or they would need some way to prevent certain commands that require that, so the plugin can run parallel, without causing those problems.

Now, one solution has always then been to have the feature run independently, as a separate program, which is possible, withing limits. This however is less practical under something like Linux, where COM isn't really available. MONO may work to bridge the gap, or it might not. Other methods are possible, like the UDP thing we already use, but that has serious drawbacks too. It might be easier to simply make sure that things that *need* to operate in parallel within the client can. And a mapper is one of them. So, its necessary to decide imho, if you want to even allow alternate display methods, other than the simplest 2D one, and then figure out from there how the mapper would need to handle the data, and interface with your GUI plugin for displaying it, not to mention whether or not that is going to have enough of a performance hit to require a independent thread, or if its small enough to run in a "normal" plugin, which isn't able to run parallel to the main processes.

There are several ways to do inter-process communication on Linux... it's not as if COM is the be-all, end-all solution. :)

I agree that the mapper discussion is important in general, but the discussion in this thread should probably be limited only to what repercussions a mapper would have on the new client's design. Concerns about guessing rooms and even displaying them aren't quite relevant at present; but on the other hand, how to handle IPC, if it's even needed, would be more relevant. So my suggestion is just that the map discussion should be moved away for now, and if/when a conclusion is come to, we should bring it back to this topic once there is a clearer idea of what needs to be done. And in the meantime I will do my part and stop talking about this. :-P

So ... what's the plan from this point onwards? Is the whole idea of the crossplatform client accepted? Is there enough motivation to do this? What's the status?

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.

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

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.

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.

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

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? ;)

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

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.

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:



becomes something like:



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.

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

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.

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.

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.

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.

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.

Actually, just to be argumentative, your right and wrong. Some patches for EQ2 have included changes to the icons, so you can tell some items apart easier, but usually the patcher is fixing something in the main engine, or a few things in specific zones, most of it not dealing with graphics changes. The two nights ago was an engine patch, which took like two hours on dialup, so it was still a pain. Usually, most of the patching happens in a dozen xml files, and more rarely in their graphics packages. Thankfully they can just patch the smaller new file into the older one somehow, otherwise it would take 10 days, instead of 10 hours (I know, that is roughly how long the "first" patch took to update it from what was on the CD. Shudder!!)

So, yeah, for a text client, or even one that uses some limited graphics, like icons, its not going to be that bad. But that is also why I would consider a torrent style update. Let the people that have broadband shoulder the burden of downloading it all at once, when the update happens, then let everyone else leech it at the pace "they" can handle. Unless its critical to game operation, which it shouldn't be in a text game, it won't matter if some guy with dialup has limited the bandwidth to like 0.5k/s to avoid lag, and it takes him 3 days to patch. He can always just sit out a day, on his own option, and let the client download it at 4k/s, or what ever. Normal FTP can't bandwidth limit, and will grab as much as it can, to the limit of what the server its getting it from allows, to get the file to you, which is **horrible** for someone without lots of bandwidth to do that.

But yeah, I can sort of be of two minds about it too. The problem I see is mostly that MS and some others are pushing the idea of everything sitting one "someone else's" server, then only loading it as needed, which means some twits are going to go, "Heh! Great idea!", without considering the complications of the system, the bandwidth they will lose all the time, if say every player clears their cache every day at the end of the session, etc. For a big company, who can afford the overhead, its not bad, though too many users trying to get the application will lag the system like hell, but for the little guy running a mud... You might want to rethink hosting any but the most *basic* client on your own server. lol

I also would have to say, anything like an AJAX sort of thing in a muck client just plain isn't for me. Even if it wasn't browser dependant. Mentioned it before, but I'd be a lot more happy with a "real" client, if I may it so bluntly.

Hi guys. I just ran into this thread. It's kind of ironic. I've been building a GUI front-end to smaug for the past month and a half and my thoughts were very similiar to what has been discussed in this thread. We're basically replacing all the 'obvious' elements with graphics and everywhere else we think is possible. I have a demo client already working, written from scratch, ansi support, and some graphical features working. We also have two graphic designers atm that will be adding front-end graphics.

It's all written in .NET C#. The current client is .net 3.5 using ClickOnce, and the web-client is written in Silverlight 1.1 alpha. And the smaug server is of course, written in c. (and using 1.8b currently)

My primary goal is to create an interface that cuts out a lot of the steep learning curve of muds and makes it easier for a new generation to get into mudding. I think there's a lot of work already put into these muds and i'd like to harness it but make it more palatable for people who are used to WoW and other modern-day mmo's.

If you're interested in any more info feel free to email me at tarlyn72@hotmail.com. I'm currently the only coder and reaching the point where I really could use some help coding-wise. If you'd like to help i'd love to discuss it with you. I'm also not opposed to maybe one day releasing the source if it ever comes to the point where it's working fairly well.

Does that new client also work with simple, plain mucks? The point of those mucks is to basically tell stories in roleplaying. There are no stats to keep track of whatsoever. Quite simple actually. For a good muck-client you'd basically need really good text editing features for the input area, cut & paste support and all that jazz. All these mud related features, except ANSI support, a muck client doesn't really use.

However, I'm still, of course, focused on the idea of a new MUSHclient, 'cause so far that handles mucks with excellency. Running it through wine however is not my thing.

Lot of muds have started to do that Mojosmitty. The discussion is mostly about how to do it "generically", so that, much like how you start with a code base, then just design what ever you want, you can start with a client, then just do what ever you want, with some ideas for how the mud/muck can send basic layouts and other data, to customize that generic client for "their" server, without having to code one that only really supports that they wanted. So far, I haven't seen a trend in that direction. Its mostly been either the VB theory of design, "You can do anything you want, as long as it still *looks* like a VB application.", or the, "You can do anything you want, as long as you are willing to code it yourself.", method. The intermediary kind of, "Here are the features we support, you figure out how to use them and what to skin them with.", type client isn't really seen much in mud/muck style clients yet.

That's been kind of the point of this thread. What do you need to make one that is generic enough to use any place, but flexible enough that you can skin and script it to work from anything from a story muck, to a single D&D style stat system and RPG, to something really complex, in terms of both the character data and how the world is interacted with? Custom built clients that limit you to a specific set of "features" just won't cut it any more. ;)

I couldn't agree more with Gammon when he say's: "I am inclined to think 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."

That is exactly what i am doing with my client. Now, whether it is actually generic enough to support all other forms of muds is a good question. From the client side if it doesn't care what type of mud it is interacting with, as long as it gets the correct "event messages" as Nick put it. I am of course designing custom graphics because i'd like to make my world to be unique, but if the client had some simple scripting interface, all of that could be modified by the user. It's just a GUI responding to event messages from the server after all.

But if we're talking about a generic client that supports all types of muds/mushes right out of the box, without the mud server implementing the special "event message" syntax, i don't believe that is very feasible. Parsing out text strings only gets you so far. The server (like my modified smaug server does now) will have to support those "Event Messages" to pass to the client.

If we want to have a generic graphical client we'll also have to agree on an Event Message syntax for our server's to implement, and then actually implement it correctly in the various mud's/mush's, etc. which isn't trivial at all.

In my case, my client sends a handshake to the server, and once completed the server knows the "Custom Client" is connected. The server then sends Event Messages to the user for the client to interpret and parse out. Otherwise the server acts just like a normal Smaug server.

Well, yes and no. Realistically, if you want it to work well, you do need a new protocol, with events linked to the server content you want displayed. *However*, a lot of content that is already generated uses existing client triggers to do everything from auto-rolling, to modification of how ones inventory looks, to storing data on what specific items do. There is no real reason why lots of things, including your character inventories, can't just be trapped, as they are now, and displayed through the same GUI elements. The point being to make one flexible enough that you can do that, if the mud supports "anything at all" that could be put into GUI, but not the more sophisticated protocol.

And, using script to *change* the GUI kind of depends on what you mean. If you mean something like applying a different GUI layout to something the mud "expects" to work a certain way, then yeah. That is part of it. But, one issue I have discussed is separating the *design* from the *code*, such that you could create an inventory layout, store than in XML or something, then have it "loaded" in the script, instead of having to use the script to *code* the whole thing, which isn't going to be practical if the server is updating only the GUI, or it has to update the script, but not the GUI, etc.

Mind you, the other trick is to support some way to *merge* scripts, so you only send the updates you need, not an entirely new script or GUI setup. The reason to keep them separate is that if they are the same, then changes to your GUI layout could scramble changes to the code, and vice versa. In the best cases, you would want to avoid changing the "code" from the user end at all, instead providing a way to get a different plugin to also receive the same "events" if needed.

Basically, you need the server to be in control of *what* the elements are that make up the GUI and the main code used to handle them, but you want the user to be able to loadUI over the layout of the GUI and maybe provide some method to have their own code react to things like button clicks from the GUI, or data from the server (such as if storing the tooltip for an inventory item as it arrives, so that they can put it in a database).

This is a bit more complicated than just scripting everything, then hoping the user doesn't mangle the code for everything from the events to the GUI itself. lol

I hope this doesn't come across as 'rubbing the wrong way':

So far I've thought that the idea was to create a new cross-platform client version of MUSHclient without all that much changed about it.

But instead, it seems like many of you are looking for 'the' client for 'the' the new breed of servers. And I'm getting worried if this will still be a MUD or muck client at all, in the end. I'm sure that new stuff is going to be great, with the exception of running things in a browser (god forbid) using flash or or whatever, or to virtualise the client in any way whatsoever.

Just don't leave the low-end out. At least those're my thoughts as a non-programmer.

While you focus on that next evolutionary step, don't regress the client in terms attractiveness for use with "simple", normal MU*'s, if possible :).

Well, Jammet, i guess we have hijacked the thread somewhat :)

It's probably off-topic, but i'll address your concerns from my point of view.

My purpose, at least from the server side, is to make sure that "older' clients like zmud, gmud, mushclient, etc. can all connect, and people can play like normal. But also support the new graphical client as well.

From the custom client side, your fears are probably semi-realistic. My client at least is honestly not really going to be much of a mud/muck client at all in the traditional sense. At least thats not the -purpose- of it anyway. We're doing a Silverlight client, which is basically Flash on steroids. I really want to target the Flash game market, and get a lot of new people playing muds, and having a 1-click in-browser experience with graphical support is imo the best way to do that. But that's maybe not as bad as you think. There is the traditional telnet capability built in, and it would be fairly trivial to provide a 'non-graphical skin' type option, to give you more of the traditional look on the client, if one wanted to do that.

A standard MUD is essentially a special case of the enhanced "event-based-special-protocol-thingamjig" server, in which every character sent by the MUD is to be interpreted as the event of putting that character on the screen. So I wouldn't worry too much about a fancier client not being able to handle standard servers.

Ah, thanks for explaining in some more detail.

I'll get back to talking actual MUSHclient now, but before I do I share my opinion (I'll be real honest) on the Silverlight client / server.

It sounds pretty promising for the future. I will never use a flash client, (I really loathe the idea, sorry sorry), but a whole lot of people will. And attracting more casual crowds with that will probably work. Let's hope they're not too casual -- so far I thought the broad masses not being present on mucks I play on is a bliss, as more casual online-d00dz as we've come to know them from World of Warcraft really wouldn't fit in the specific games I play.

Well, something like Silverlight is still a great idea, so by all means, do it. You could perhaps even help having a 'new' MUSHclient be compatible with it.

Well Jammet, if you where paying attention at all, one reason to use wxWidgets would have been to allow for a lot of stuff that just isn't practical in the current MFC based client. That includes the GUI elements, etc, which have been brought up in one form or another a lot of times. Any cross-platform client would likely support better user-definable GUI, and it then becomes the question of, "Ok, now that we have that, how do we use it effectively, and is it reasonable to come up with a better way to have the server control some of this stuff than MXP or the other messes that currently exist?" ;)

Of course I'm paying attention? I hope I didn't write anything that upsets you. Certainly didn't mean to. :)

The thing is, I do not know much anything about programming. I'm here because I like MUSHclient, and there's a chance to have something a lot like it become crossplatform.

I may be somewhat ignorant with what's practical and what's not without even realizing. However, I simply favour a program storied on my harddrive, a native binary, over anything based on a third party plugin, interpreter, browser or the likes.

So I went on describing what kind of client I'd hope the follow-up to MUSHclient is going to be like, that's really all there is to it. :)

You could have a browser application stored on your local computer too, actually. Unless it needs to read files off of the server without talking to the server using HTTP (debatable whether a client needs to do that), you could just run the application in your browser from your local machine and have it connect to another computer.

Basically, the choice of language isn't really a limiting factor, even if it's browser-based technology, in terms of where you can run/store the program. Now, you still might prefer a standalone client over a client in the browser (but perhaps not for the reasons you might first think! it's kind of subtle) but that's a separate issue. (What I meant by that last comment is that a browser can, e.g., run a Java applet; you'd have nearly the full power of Java available to run your client which means you could do pretty much as you could have done in a normal Java app.)

Sorry that I'm repeating myself twice over :). Having it on a local harddrive is possible, but as you mentioned, it's not my thing if it's wrapped up using in the browser, flash, or java.

As for the reasons, well, there are several.

I'm not happy with the overall stability of browsers, or java applets or flash.

Standalone Java programs that simply require the Java-Runtime are fine though.

And I have yet to see a single Java/flash application that works for me, meaning usability, configuration, looks, performance, cpu hogging and what not. No two look alike, no two work alike, no two are configurable alike.

I need the configuration stored in my home directory like with all the other applications, where I can look at it, back it up, have full control over it.

There are several other reasons. Generally, I think I just feel way safer and more comfortable with applications that I can control. If they're the child processes of the children's childrens children, meaning encapsulated, wrapped up in a much bigger package, I can't warm up to them. Never played browser games twice for the same reason.

But again, that's just me. =) Your idea is brilliant and it's going to be great, no doubt. Just felt compelled to reply, outlining why I feel this way.

Oh, I don't really like the idea myself, in most cases. Well, that's too strong: I neither really like nor dislike it. The main (only?) advantage to such a client is that you don't need to install it; many public computers let you use the browser and Java applets therein, but not add programs.

Of course, if you can download a .jar, then you don't need to "install" it, so I think that the same purpose is served thus obviating the need for the browser solution.

I think the issues of safety are somewhat non-technical, in the sense that it's the same JRE that runs a Java application as a Java applet inside a browser. The one isn't going to be more or less reliable than the other. Configuration though is a considerable issue, since by default applets have no access to the file system. (You need applets to be 'signed' in order to give them access to certain privileged OS functions like file I/O. This is a fairly important security feature.)

But I also agree that I've never seen an applet I've been entirely happy with, but I'm not sure if that's due to applets per se, or due to the particular applets I happen to have seen thus far. :)

What? You're not into the whole, "Use silverlite to code you apps and the future is going to have Word, Excel, and anything else other than the browser stored on someone's server!", world vision of Gates (and sadly IBM...)? Neither am I. lol

What happened to this idea?

I stick by my comment at the top of page 9.

With people wanting support for multiple scripting languages, and also with the goal of supporting multiple platforms, the scripting part itself becomes a huge undertaking.

I would be delighted to ditch everything except Lua, but then, that's just me. :-) Running MUSHclient in Wine works well enough, but it has enough quirks that I'd rather something more native. Enough to warrant all the work it'd take to write a new client? To be honest, probably not...

Hmm something happened to the wxWidgets site. The designer's Word Press url shows unable to connect as well...

I was looking at this and wxLua but now I can't seem to get any information regarding wxWidgets or even download it. Anyone else able to connect?

I connected to http://www.wxwidgets.org/ ok just now.

hi Nick, wish u not mind it, i have some ideas about MC code.
MC is stable, strong, fast, probably the best mush client, but still, the code structure can be improved. I just checked and did some changes, one thing i notice is that no proper middle tier in it.
3 tiers: GUI->function layer->data, that will make code cleaner, a bit, when u want to do make huge changes to MC or u want to reuse MC code in a new project, u dont need to write from scratch
To this code, i suggest u create a new class MCWorld, move gui-neutral code from doc to MCWorld, and the call, pDoc->dosomesth() simply change to pDoc->world->dosomesth()
When this is done, a new layer created, that can be used in new client, and old one can be maintained at the same time.
I did some test, function like GetWorld() use too much doc/view thing, need a big change, most others, like AddTrgiier() just copy/paste

You are right, it is messy. The problem was, that when I first started writing it, this was one of my first GUI applications, although I had done a lot of programming previously.

I learnt as I went, and for example, when I implemented the Chat system, it was much more modular. In fact I wrote the functions first, and added the GUI on top of that, which made for a more modular and stable system.

The problem now is, that if I make changes I really need for it to function the same as before, or it will break existing scripts or behaviours (like triggers). So really, I could put a lot of work into improving it under the bonnet, with no difference in end-user behaviour.

man u r open minded. As a programmer my usual reaction to such voices was "my code? what the heck wrong with my code?" :D
as i said, MC is best imho, powerful and fast, thank ur great effort!
actually i can understand ur code very well, i started coding from VC++, doc/view, M$'s MFC now considered as ugly design, but it was best IDE under windows.
I feel ur origional idea very interesting, a thin client yet still hav most power, i dont hav much free time but still trying to dig in a bit. free control of windows with Lua, so nice. things hard should be with event loop and message queue? or if MC migrate to wxWidgets then can interact with wxLua? will read more

Have you considered GTK+/Glade?

That provides a nice clean interface, and configuration. (A lot cleaner than WxWindows IMO.) It also allows for easy XML-Based modding of the interface.

Well the problem is that it would take a lot of work to rewrite the client, regardless of which platform or tools I chose.

Already the client gets a few thousand downloads a month, so someone must like it in the current form. Any sort of major rewrite would be incompatible with existing scripts and is thus likely to get a very slow level of take-up.

Hi,

I haven't really posted here much, but I've been using MUSH since I don't know when. I both love it and hate it( only sometimes ), but I still think that an updated MUSH would be worthwhile.

I downloaded the source code about a month ago with the idea that I would retool some of the issues I had with it (passing lua callbacks as strings instead of closures) but I am afraid I got a bit lost in the code.

I don't think it's bad at all, but it's been around so long, and features/functions, especially of embedded scripting languages have changed alot. I remember when MUSH didn't even have Lua and I did everything in PERL. In my opinion, LUA was a godsend at that point. ( I could be mistaken though, it was years ago ).

Most of the code, to be honest, is too clever for me, as I am a bit of a dullard when it comes to programming.

What I decided to do was to take what I really love conceptually about MUSH and rebuild it in Qt C++ ( Windows/Linux/MAC for free) as an HTML 5 App using the WebKit widget for UI Rendering, allowing all UI work to be done in HTML5, JavaScript, CSS.

This works so far (Basic Telnet, GMCP, Aliases, Triggers with management, all configs in JSON files). MCCP Has been a sticking point because Qt C++ and zlib is a bit problematic, internally strings deflate/inflate, but junk from the server, so I switched to using the MCCP client downloadable from aardwolf for now.

I have added in SQLITE support and am attempting to port the mapper to the application. All of this is done in Minimal C++ ( A few classes that expose Signals and Slots to Javascript, File IO, Socket to play with, Sqlite DB etc), the rest ( even GMCP subnegotiation) is done on the JS Layer.

The downside to what I am attempting right now is no LUA, but I remain hopeful that I can embed lua into the app as well and support some manner of lua coding for plugins as well.

The issue is, all the script embedding is already done for free with Qt when you use JSCore which ships with the 4.7/8 of Qt. No need to handle callbacks as closures( Almost the entire Application logic is already in Javascript, but C++ Signals can connect to anonymous functions, so no need to pass in the string name and therefore lose your scope.

The Core application logic is served to the HTML5 app from a webserver ( so you host the application logic on your website, and when the thin C++ client starts up it loads the app like a web page, making distributing updates to all users automatic and transparent.) All people download is a small C++ App with some dlls, double click and go.

With Lighthouse it may be possible to also compile and distribute the app to Mobile devices.

Things you get for free:
- Scripting (JS, but heh, not so bad as it's not WSH)
- Dead Easy UI (It's HTML/CSS)
- MiniWindows ( I have floating, draggable windows, and
tabbed window regions that you can draw to already
done.)
- HTML5 Canvas allows you to draw if you want to get
fancy.
- Completely themeable ( uses foundation.css for
columns and rows, so different sizes display
gracefully. This should also degrade gracefully
when on mobile apps.
- Regex with good support.
- PLANNED: Script editor using ACE which includes syntax
Highlighting.
- Cross Platform ( Compiles on linux, windows, mac because
it's Qt.
- Completely modular, plugins have plugins. The main App
is more or less agnostic ( Just a Socket/IO/Sql api).

Of course, this app was never meant to be a general MUD client like MUSH, it was specifically designed (in my mind anyway) for connecting to Aardwolf to serve my specific needs, so I am not even sure anyone else would find it even remotely useful.

It was also intended as a promotional gimmick for my clan, with the hopes that people might download the client from our website, not have to install anything, and we could provide them with a slick UI and pre-configured client that would also work on Mobile. The ultimate goal is to get it working there, cause sometimes you just gotta quest while on the go.

I am interested to hear what you think, perhaps if you do start a rewrite of MUSH you might consider Qt for the cross platform stuff, at the very least, what I did is a nice proof of concept, even if it's limited and hackish( I am not really a good C++ programmer or even Javascript programmer, so I have probably done a lot of dumb stuff.)

You can check out the code on github:

https://github.com/jasonknight/qushie
https://github.com/jasonknight/qushie-app

It's very alpha, so probably not very easy to get it up and running.