Register forum user name Search FAQ

Gammon Forum

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

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

Entire forum ➜ MUSHclient ➜ General ➜ 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

Shaun Biggs USA (644 posts) Bio

Date

Reply #60 on Tue 28 Aug 2007 09:13 AM (UTC)

Message

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.

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

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #61 on Tue 28 Aug 2007 09:34 AM (UTC)

Message

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

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.

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

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

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shaun Biggs USA (644 posts) Bio

Date

Reply #62 on Tue 28 Aug 2007 09:46 AM (UTC)

Message

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.

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

Posted by

Isthiriel (113 posts) Bio

Date

Reply #63 on Tue 28 Aug 2007 10:43 AM (UTC)

Message

Quote:
David Haley wrote:
I'm not sure it's appropriate to proceed like those studies.

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.

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

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?

Quote:
Nick Gammon wrote:
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.

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

Quote:
Nick Gammon wrote:
Now, Blizzard is big enough to write their own language, or spend weeks evaluating the various languages available.

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

Quote:
Nick Gammon wrote:
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?

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.

Quote:
Nick Gammon wrote:
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.

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

Quote:
Nick Gammon wrote:
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.

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

Quote:
David Haley wrote:
Seems to me that this would require some degree of cooperation with the MUD server.

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?

Posted by

Shaun Biggs USA (644 posts) Bio

Date

Reply #64 on Tue 28 Aug 2007 11:45 AM (UTC)

Message

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

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.

Quote:
WoW is developed by Blizzard. I have no confidence in their programming team

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.

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

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #65 on Tue 28 Aug 2007 04:09 PM (UTC)

Amended on Tue 28 Aug 2007 04:10 PM (UTC) by David Haley

Message

Quote:
That discussion seems kind of backwards to what I was talking about.

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.

Quote:
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?

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

Quote:
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?

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.

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

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

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

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

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shadowfyr USA (1,790 posts) Bio

Date

Reply #66 on Tue 28 Aug 2007 08:28 PM (UTC)

Message

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?

Posted by

Nick Gammon Australia (23,133 posts) Bio Forum Administrator

Date

Reply #67 on Tue 28 Aug 2007 09:50 PM (UTC)

Amended on Tue 28 Aug 2007 09:56 PM (UTC) by Nick Gammon

Message

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

- Nick Gammon

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

Posted by

Nick Gammon Australia (23,133 posts) Bio Forum Administrator

Date

Reply #68 on Tue 28 Aug 2007 09:57 PM (UTC)

Message

Quote:

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?

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.

- Nick Gammon

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

Posted by

Nick Gammon Australia (23,133 posts) Bio Forum Administrator

Date

Reply #69 on Wed 29 Aug 2007 12:39 AM (UTC)

Amended on Wed 29 Aug 2007 12:42 AM (UTC) by Nick Gammon

Message

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.

- Nick Gammon

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

Posted by

Dmpk2k (7 posts) Bio

Date

Reply #70 on Wed 29 Aug 2007 07:11 AM (UTC)

Message

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.

Posted by

Nick Gammon Australia (23,133 posts) Bio Forum Administrator

Date

Reply #71 on Wed 29 Aug 2007 07:21 AM (UTC)

Amended on Wed 29 Aug 2007 07:24 AM (UTC) by Nick Gammon

Message

Quote:

It's a great piece of software, but it's almost a case study in how to not design a UI.

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.

- Nick Gammon

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

Posted by

Jammet (14 posts) Bio

Date

Reply #72 on Wed 29 Aug 2007 10:51 AM (UTC)

Message

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

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #73 on Wed 29 Aug 2007 04:45 PM (UTC)

Message

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Dmpk2k (7 posts) Bio

Date

Reply #74 on Wed 29 Aug 2007 06:10 PM (UTC)

Message

Quote:

However, I have seen worse.

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.

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.

370,946 views.

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

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

Go to topic: Search the forum

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