Skip to content

pymudclient

So, for the last several weeks, I've been writing my own mud client to use for Imperian (to be completely precise, I forked an existing open source client, mudpyl, which has been dormant since 2008, and been making extensive modifications to it).

The reasoning for this has been my dissatisfaction with the available options.  Mudlet seemed like the most polished of the bunch, but I still felt pretty trapped by their GUI framework for scripting, and also I wanted to use python rather than lua.

It currently supports regex triggers and aliases, macros of almost any keys, triggers on gmcp_events, color HTML logs, gags and text replacement in triggers with Mudlet-like syntax for colors, tab completion of inputs, as well as history of previous commands.  Combat modules, which is just a collection of triggers, aliases, gmcp event handlers and macros are simply python modules with very easy to learn syntax hooks.  I find it to be just as fast, if not faster, than Mudlet and the coding is much easier (though that's in large part is driven by the fact that I prefer python to lua).  It's feature-complete enough to use, I've been using it exclusively for 3-4 weeks now.

Some of the things not yet implemented that I'm planning for the future:
* Easily customizable interface (probably through something like Glade)
* Multi-line triggers
* Ability to run it as mudbot-like proxy for people who want to use their own client like Mudlet as a user front end
* A bunch of useful imperian-specific modules - possibly a healing module that's a bit more sophisticated than gbot.

Below is a screenshot of the interface.  If anyone's interested in checking it out or helping me develop it further, please let me know

image

Comments

  • MadrigalMadrigal Missouri, US
    I'm just learning Python but, as it's the language I'm using in school, I'd much rather use it than Lua.  I wouldn't be much help in development yet but I'd love to use the client.
  • IniarIniar Australia
    @Ailish, I installed pymudclient on my Mac. Are you really keen/attached to pygtk? Just seemed quite convoluted to acquire it on my machine/easy to get new users confused. Are you planning to package it as a distributable? Would you consider a different gui framework?
    wit beyond measure is a Sidhe's greatest treasure
  • edited September 2015
    I hear you on pygtk.  I'd consider a different framework, but it's the only one I'm at least somewhat proficient with right now.

    The installation is terrible, though.
  • IniarIniar Australia
    I know Kivy isn't great but it's well supported, and more importantly, easy to install cross-platform.
    wit beyond measure is a Sidhe's greatest treasure
  • I'm totally on board with trying to add a kivy interface as there's nothing about the pygtk developer experience that I particularly cherish
  • Ok, I looked at Kivy and it's even more of a pain in the ass to install than pygtk. It doesn't nearly easy-install and the binary installer for Windows they give you installs it's own instance of python rather than using your existing one which is patently ridiculous.

    Nonetheless I'll play around with it but I just don't see how it's any easier
  • Upon yet further investigating, Kivy appears to be terrible for text based applications.

    A shame because I was really taking a liking to it
  • Could look at wxPython maybe. I guess it depends what priority is (cross platform, it should look awesome, easy to install etc).

    Cool project!

  • wxpython is unfortunately the ugliest thing I've ever seen. Kivy is gorgeous and the installation is actually easier than I thought but the fact that it has no usable Text Box type widget and you'd have to handle output using a Label widget that treats text as graphics rather than text is *headdesk *
  • Yeah, you probably don't want to take graphical appeal advice from me. The only other big one that springs to mind is pyqt, and I think that has a nasty licence if I'm remembering rightly (I might not be).
  • IniarIniar Australia
    Think it's a LGPL licence, need to keep your code open source iirc. Yeah, PyQt would be the other popular option but I haven't looked at it much myself. Leveraging Qt is supposedly very beneficial (see Mudlet's 3.0) but I don't see the need myself. Happy to be proven wrong!
    wit beyond measure is a Sidhe's greatest treasure
  • IniarIniar Australia
    Also pygtk would be ok if you could distribute it with pymudclient. (If that's the right way to put it, this is all new to me; Python, version control, etc,)
    wit beyond measure is a Sidhe's greatest treasure
  • The client is already completely open source and freely available. 
  • IniarIniar Australia
    Then PyQt may be something else you might be interested in; that said, if pygtk is the familiar territory and if you could some how bundle it with the rest of your code, that would be sufficient. Sorry, I don't mean to sound demanding, but if you really are going to put the hard yards in, I wouldn't like for it to become unused because of accessibility/ease of installation issues. <3
    wit beyond measure is a Sidhe's greatest treasure
  • edited November 2015
    I haven't posted any updates on pymudclient recently (mostly because there hasn't been a lot of interest in anyone other than me using it).  I do have one important update though.  Pymudclient now (hopefully) fully supports all popular screen readers.  I tested it to the extend that I was able myself, but obviously, I don't really know what proper screen reader support should sound like.  

    I'd really appreciate if the players who actively use screen readers  for accessibility could reach out to me and help me test this.



  • Also, here's what the interface looks like now, in case anyone cares.

    image
  • Im interested. I use screen reader and custom sound files to play. Using github? Message details.
  • github is https://github.com/dmoggles/pymudclient

    There's still the pesky installation issue to deal with, though.  It requires pygtk which is rather annoying to install.
  • Do you actually pay any attention at all to that side panel? I gave up on fancy UI things like that when I realized that I never actually looked at any of it in combat. 

    "On the battlefield I am a god. I love war. The steel, the smell, the corpses. I wish there were more. On the first day I drove the Northmen back alone at the ford. Alone! On the second I carried the bridge! Me! Yesterday I climbed the Heroes! I love war! I… I wish it wasn’t over."

  • I do. I pay more attention to it than I do to the main window
  • IniarIniar Australia
    edited November 2015
    It's pretty. Nice work. The side panels are real helpful when chasing afflictions; but not everyone needs them (I do).

    Again, nice work.
    wit beyond measure is a Sidhe's greatest treasure
  • Re: accessibility

    The gui should probably be disabled on startup if inheriting from ScreenreaderProtocol. You can't really review properly using a screenreader with it enabled (text becomes mixed in with gui data).

    After I disabled the gui, review was very solid. It'd be nice if it tried to wrap on whitespace; i.e

    This is a line of truncated
    data

    Rather than:

    This is a line of trun
    cated data

    I'm used to reading the latter version, but a lot of people won't be and will find it annoying. This is all based on the assumption there is not a setting somewhere to handle wrapping differently; I haven't dug in much yet outside of the accessibility stuff.

    I tested with both jaws and NVDA. NVDA was basically fine out of the box, no issues at all. Jaws would read the command before the output on hitting enter; I imagine this would be resolveable by having an option to remove the last command history. There are probably other ways, but I'm not familiar enough with the interface of accessible_output to know how configurable it is in terms of speech interrupts/prioritisation. That is a fairly big deal though, as it essentially adds a response lag to all entered commands (which grows exponentially with how long it takes to read the command).

    I will try to test voiceover/orca later when I have time to setup gtk on an osx and linux installation.

  • Thanks for taking the time. This is really helpful.

    Re:disabling GUI - good point. This didn't occur to me at all, and in my testing with Windows Eyes this wasn't an issue (or I may not have tested thoroughly enough). This is easy enough to do. What should the ideal interface be in accessibility mode, in your opinion? Just a big text entry box? Sorry if this is a dumb question. I don't really have any understanding of HCI nuances for visual impaired people.

    Along the same lines, does your existing set up allows for "scroll back" and replay of previous output? Is that something I should consider adding support for? (I'm not sure how I would do that yet, but I have some ideas)

    Re: wrapping on whitespace, not sure I understand. Does it have anything to do with where Imperian wrap lines? I have it set up to not wrap all all (wrap width config setting of 0 or something like that) I didn't experience anything like you've described. Window Eyes would read the entire block for me with no midword "pauses". I'll try to replicate the issue some more

    Re: reading back the command. I'm guessing this has to do with the fact that after you push enter, the default behavior of the client is to leave the previous line in the entry box and highlight it so that the user can either easily overwrite it by typing something else or just hit enter to send it again. I'm reasonably sure the highlighting is the reason the screen reader is reading that line again. I'll change it so that in accessibility mode the line is always left blank after you hit enter. You can still access the previous command with up arrow.

    I haven't played much with accessible_output either yet, that's on my list of things to do.

    Thanks, this has been most helpful
  • Interface:
    Just a text field, yeah. The more minimal the better, basically. Sometimes it can be useful to have an info bar of some form at the bottom, but reallistically that's going to be an exception rather than the rule (and if someone needs it they'll probably be able to add it).

    Scrollback:
    Screenreaders basically support this already in varying flavours, I'd not worry much about it. This follows to the next point, this is where I encounter pauses. The actual reading of output when entering commands and such is fine. Its very possible its screenreader dependent. Unfortunately, I've never used window eyes so can't really draw comparrisons there.

    Highlighting:
    Yeah, that'd do it.

Sign In or Register to comment.