Register forum user name Search FAQ

Gammon Forum

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

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

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

Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Wed 22 Aug 2007 11:05 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #1 on Wed 22 Aug 2007 11:53 PM (UTC)

Amended on Wed 22 Aug 2007 11:56 PM (UTC) by Shaun Biggs

Message
# 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.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Guest1   USA  (256 posts)
Date Reply #2 on Thu 23 Aug 2007 12:25 AM (UTC)
Message
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.
Top
Posted by Jammet   (14 posts)  Bio
Date Reply #3 on Thu 23 Aug 2007 02:07 AM (UTC)
Message
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*. :)

Top
Posted by Onoitsu2   USA  (248 posts)  Bio
Date Reply #4 on Thu 23 Aug 2007 02:37 AM (UTC)
Message
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
Top
Posted by Rakon   USA  (123 posts)  Bio
Date Reply #5 on Thu 23 Aug 2007 02:39 AM (UTC)
Message
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:

Quote:

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


Yes, I am a criminal.
My crime is that of curiosity.
My crime is that of judging people by what they say and think, not what they look like.
My crime is that of outsmarting you, something that you will never forgive me for.
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #6 on Thu 23 Aug 2007 04:53 AM (UTC)
Message
Keeping the different scripting languages sounds pretty important to a few people I've talked with.
Quote:
23 Aug 00:36 - You tell **** 'wait a second... Lua is embedded into MUSHclient now. You have to have Lua by default.'
23 Aug 00:37 - ****** tells you 'Actually, 'now' is correct. I haven't updated MUSHclient in a while, and if Lua is mandatory I won't be.

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.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #7 on Thu 23 Aug 2007 05:17 AM (UTC)

Amended on Thu 23 Aug 2007 05:19 AM (UTC) by Nick Gammon

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


Quote:

I haven't updated MUSHclient in a while, and if Lua is mandatory I won't be.


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).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #8 on Thu 23 Aug 2007 05:51 AM (UTC)
Message
Quote:
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.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #9 on Thu 23 Aug 2007 07:13 AM (UTC)
Message
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. :-/
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #10 on Thu 23 Aug 2007 08:20 AM (UTC)
Message
# 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)
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #11 on Thu 23 Aug 2007 08:20 AM (UTC)
Message


# 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)
Top
Posted by Isthiriel   (113 posts)  Bio
Date Reply #12 on Thu 23 Aug 2007 02:57 PM (UTC)

Amended on Thu 23 Aug 2007 03:23 PM (UTC) by Isthiriel

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

Quote:
Nick Gammon wrote:
Let's do a thought experiment ...
(1) 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.
(2) 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.

(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?



Quote:
Worstje wrote:
# 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.)

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
Top
Posted by Cage_fire_2000   USA  (119 posts)  Bio
Date Reply #13 on Fri 24 Aug 2007 01:07 AM (UTC)
Message
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.

Top
Posted by Cage_fire_2000   USA  (119 posts)  Bio
Date Reply #14 on Fri 24 Aug 2007 01:10 AM (UTC)

Amended on Fri 24 Aug 2007 01:12 AM (UTC) by Cage_fire_2000

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

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

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

362,117 views.

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

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

Go to topic:           Search the forum

[Go to top] top

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

Home