The MUD Connector

Old TMC Forums (read-only) => OLD Coders Forum => Topic started by: KaVir on April 01, 2011, 6:33 AM

Title: GUI snippet
Post by: KaVir on April 01, 2011, 6:33 AM
I've been working on improving the interface for God Wars II for nearly a year now, making it easier to navigate through a mixture of graphics, sound, and enhancements to the text.  The following screenshots demonstrate my GUI using MUSHclient and Mudlet:

  • MUSHclient: Opening the large map while standing in Glyphstone Village.

  • Mudlet: Exploring an undead-ridden crypt.

    For the past few weeks I've been working on a snippet that adds the same feature support to other muds, and it's now pretty much complete.  The snippet is relatively self-contained, and is designed to be easy to install and easy to use - I've added it to a few codebases already, and it generally takes me around 5-10 minutes (at least once I've worked out where the hooks need to go).

    The underlying concept isn't new - muds like BatMUD, Maiden Desmodus, Primordiax, Archons of Avenshar, etc, have been offering graphical interfaces for a while.  But those are handled through private clients and closed protocols.  What makes this different is that it operates on existing open source clients, using an open protocol (MSDP) that allows owners and players alike to quickly and easily design custom GUIs for their favourite muds.  You can see some of the interfaces my players have created for MUSHclient and TinTin++ here, here and here.

    A handful of other muds have also made progress in this direction - for example the Aardwolf MUSHclient plugin and the IRE Mudlet interface both work in a similar way.  But implementing full server-side support is a non-trivial job, and many mud owners still view graphical interfaces as some sort of mysterious black magic that requires a huge investment of time and skill.  While it's certainly possible to invest a lot of time into GUI work, even a simple interface can be a huge improvement, and it's something that can be achieved extremely quickly.

    Here are a couple of simple proof-of-concept "themed" demo GUIs I created for other muds - they took me about 1-2 hours each:

  • SlothMUD (click here for screenshot): Now click here to view their website and compare the style.

  • Tir na nOg (click here for screenshot): The map in this case is hand-drawn rather than generated, but this is also a viable approach.

    Here's a slightly more fleshed-out GUI I created and then adapted - it took around 2-3 hours of tweaking to create the first one, the other two took only a few minutes each once I'd found suitable images:

  • Realms of Despair (click here for screenshot): Also demonstrates some of the other features offered by the snippet.

  • The Realm of War (click here for screenshot): Tijer has already implemented the snippet, so I wanted to give him a working demo.

  • Generic GUI (click here for screenshot): A generic GUI for others to download and use.  You can get it from here.

    In layman's terms, the snippet provides the following features:

  • Transmits data invisibly between server and client, allowing you to update your energy bars, maps, icons, buttons, etc, in real-time, without needing to capture anything from the text window.

  • Extends your old 16-colour ANSI to 256 colours (or even 16 million if you really want them).

  • Identifies which clients your players use, their screen size, and other useful details.

  • Allows you to embed clickable links into messages, descriptions and help files, so that players can navigate with their mouse.  Graphics can also be embedded in this way if you wish.

  • Allows you to display unicode characters, such as the runic alphabet, alchemy symbols, gender symbols, weather symbols, linedraw characters, chess pieces, etc.

  • Provides extensive information about your mud to any websites that wish to use it.  This can be used to automatically generate and maintain detailed mud listings, saving you the hassle of updating them manually.

  • Can be used to play background music, as well as sounds for combat, weather, movement, mudsex, communication, eating, sleeping, etc.

    In more technical terms, it adds support for TTYPE, NAWS, MSDP, ATCP, MSSP, MSP and MXP, as well as UTF-8 (using CHARSET) and XTerm 256 colors.  The plugin is a Lua script bundled with some public domain images to get you started.

    The Realm of War has already installed the snippet, while several other muds are currently in the process of adapting it to their needs, including Realms of Despair, SlothMUD and 4Dimensions.

    If you're interested in using it as well, or just want to read more, you can grab the snippet from here.  Even if you hate graphics, you may still find some of the other features useful.
  • Title: RE: GUI snippet
    Post by: Sombalance on April 01, 2011, 7:25 AM
    Kavir,

    Thanks a lot. This is a great resource.  The only problem I
    see is trying to not stop work on my current project so I can
    try this out right away.

    Sombalance
    Title: RE: GUI snippet
    Post by: Kitkat on April 01, 2011, 10:16 AM
    Okay, that is just cool.  

    Are mudlet or the snippet usuable by players on any mud or does it have to be something the mud owner/coder installs and then the players can use?

    Does it work as a client itself?  or do you use it with another client? (sorry-still early here)

    Kitkat - would love to see where her character is in real time -
    Title: RE: GUI snippet
    Post by: KaVir on April 01, 2011, 10:53 AM
    > Are mudlet or the snippet usuable by players on any mud
    > or does it have to be something the mud owner/coder
    > installs and then the players can use?

    Mudlet is an open source mud client, it works for any mud, and allows graphics to be drawn using Lua scripts.  However it needs to know what and when to draw, and that's where the snippet comes in.  The snippet needs to be added to the mud by the owner/coder.

    It is also possible to create a GUI without the snippet, using regular expressions - there are many examples of energy bars that update using information from your prompt, for example.  However these require you to have a specific prompt pattern, and they only refresh when you hit enter.  With the snippet they can update in real-time, without anything being displayed in the text window, and this becomes particularly important for things like maps.

    > Does it work as a client itself? or do you use it with
    > another client? (sorry-still early here)

    You need a client with decent scripting support, such as MUSHclient, Mudlet or TinTin++.  This handles the display, the sound, etc, via a script.  Such scripts are generally pretty easy to create, but they can't pull the data they need out of thin air - they need some way to extract it from the mud.  Many players already create such scripts for their favourite muds, but they're limited to what they can reliably capture from the text window.

    The snippet provides a simple and reliable interface for such scripts, allowing players to directly request whatever data they need (although of course the mud still gets to control exactly what data is available).

    Other features, such as clickable links, extended colour and unicode characters, can be added to messages and help files much like those two-letter ANSI colour codes many muds already use.  Like those codes, they're automatically enabled or disabled by the snippet depending on whether the client supports them.
    Title: RE: GUI snippet
    Post by: jbrianclar on April 01, 2011, 12:55 PM
    KaVir,

    This is really nice code -- thank you! Do you plan to finish
    up the How-To for implementing into TBA -- or at least tell us
    where you left off and what we should do to complete the
    implementation?
    Title: RE: GUI snippet
    Post by: KaVir on April 01, 2011, 1:53 PM
    > This is really nice code -- thank you! Do you plan to
    > finish up the How-To for implementing into TBA -- or at
    > least tell us where you left off and what we should do to
    > complete the implementation?

    The INSTALL_GENERIC.TXT file has general (codebase-independent) instructions, but I can have another look at TBA as well.
    Title: RE: GUI snippet
    Post by: welcor on April 01, 2011, 4:01 PM
    ... april 1st? Not a very nice choice for this sort of announcement, is it? I'll look at it tomorrow ;)
    Title: RE: GUI snippet
    Post by: Macademus on April 01, 2011, 4:58 PM
    well i can tell you its not an april fools! Unlike last year when KaVir posted that everyone must speak german on his MUD by law.. :P
    Title: RE: GUI snippet
    Post by: Lyanic on April 02, 2011, 12:17 AM
    Yeah. I can confirm this is not an April Fools joke. He's been working on it off and on for a couple months at least. I've been working on something similar (or rather, my minion has been) in parallel.
    Title: RE: GUI snippet
    Post by: Keriwena on April 02, 2011, 9:54 AM
    I installed it last night, and it wasn't hard at all.

    There were a few Rom / Merc differences, such as needing to make a GET_AC_TOT(ch) macro, but on the whole I'd say the instructions are pretty clear.

    Thank you, KaVir!
    Title: RE: GUI snippet
    Post by: KaVir on April 03, 2011, 8:12 AM
    > Yeah. I can confirm this is not an April Fools joke. He's
    > been working on it off and on for a couple months at least.
    > I've been working on something similar (or rather, my minion
    > has been) in parallel.

    Yeah I offered to let him use an early version of the snippet for The 7th Plane, but your MSDP implementation was already too far along.

    The snippet includes other stuff as well though, you may still find it worth checking out.
    Title: RE: GUI snippet
    Post by: IFamiINIe on April 03, 2011, 1:23 PM
    Any possibilities to have something similar to zMUD or CMUD?

    (Comment added by IFamiINIe on Sun Apr  3 10:32:51 2011)

    Ahh, I see now after re-reading some of the responses in more depth. This should allow client-based scripts to receive data in real-time rather than hooks based on text patterns. However, when it comes to drawing GUI elements, certain clients may have limitations based on what they can basically piece together from the data received from this script server-side (MUD)?

    If I'm understanding this correctly. Different clients will be able to utilize this based on their own limitations.
    Title: RE: GUI snippet
    Post by: KaVir on April 03, 2011, 2:22 PM
    > Ahh, I see now after re-reading some of the responses in
    > more depth. This should allow client-based scripts to
    > receive data in real-time rather than hooks based on text
    > patterns. However, when it comes to drawing GUI elements,
    > certain clients may have limitations based on what they
    > can basically piece together from the data received from
    > this script server-side (MUD)?

    Yes, the actual drawing is handled by the client.  MUSHclient and Mudlet both have powerful scripting capabilities, and they're free, which makes them ideal candidates for creating a custom GUI.  You could even bundle up the client with the script and images and offer players a single preconfigured download.

    Obviously if your players insist on using windows telnet, GMud, or some other basic client, then they're not going to benefit from the snippet.

    CMUD/zMUD supports some of the features, but I don't know if its scripting capabilities are powerful enough to create a full GUI.  However IMO one of the big advantages of a custom GUI is for bringing in new players - but if they find they have to pay $30 for the client they may decide not to bother.
    Title: RE: GUI snippet
    Post by: Sombalance on April 03, 2011, 3:50 PM
    Thought this might be worth mentioning.  

    I installed the generic plugin for MUSHClient
    4.61 and instead
    of the gray gravelly type background, I got the
    gold color.  
    To fix this, I edited the Generic_GUI.xml file
    and changed the
    setbackground call to

    check (SetBackgroundImage(GetInfo (66) ..
    "Generic/layout/outer_background.png", 13))


    GetInfo (66) returns the home directory of
    MushClient.  

    The command is supposed to be on one line, but
    Chrome likes to break it up for me.

    Sombalance
    Title: RE: GUI snippet
    Post by: Kitkat on April 03, 2011, 4:09 PM

    Mudlet is an open source mud client, it works for any mud, and allows graphics to be drawn using Lua scripts. However it needs to know what and when to draw, and that's where the snippet comes in. The snippet needs to be added to the mud by the owner/coder.


    Ah, okay.  I think I may give mudlet a try even if I can't get all the stuff it and the snippet would provide.

    Thanks and sorry I didn't reply sooner.  Busy, busy week.
    Title: RE: GUI snippet
    Post by: KaVir on April 03, 2011, 4:17 PM
    > GetInfo (66) returns the home directory of MushClient.

    Ah good point, thanks - actually the plugin was pretty hastily thrown together at the last minute, it was really just intended to help get people started.  It could definitely be written better, and I'm hoping we'll see a lot more activity in this direction in the near future.

    What I'm really promoting here is the snippet, because once that's installed anyone can create their own GUIs if they want to.

    But people tend to react much more enthusiastically towards sexy screenshots than clever code, and I wanted to grab people's attention ;)
    Title: RE: GUI snippet
    Post by: Gatz on April 03, 2011, 5:02 PM
    Thanks for releasing this kaVir! I've been following your posts on MUD Bytes on this and was getting super excited. I can't wait to take a stab and putting this in my MUD. Thanks for taking the time to snippet-ize this!
    Title: RE: GUI snippet
    Post by: Sombalance on April 06, 2011, 8:56 PM
    So, I've been porting this snippet over to java and when I was testing it, I noticed that mushclient was sending NAWS info around 20+ times (compared to less than 5 for putty, telnet and mudlet).  MUSHClient seemed to behave the same way regardless of having plugins installed.

    I was wondering if anyone else noticed that.


    Sombalance
    Title: RE: GUI snippet
    Post by: KaVir on April 07, 2011, 7:10 AM
    > So, I've been porting this snippet over to java and when
    > I was testing it, I noticed that mushclient was sending
    > NAWS info around 20+ times (compared to less than 5 for
    > putty, telnet and mudlet). MUSHClient seemed to behave
    > the same way regardless of having plugins installed.
    >
    > I was wondering if anyone else noticed that.

    It should send NAWS every time the screen size changes.  Were you changing the window size at the time?
    Title: RE: GUI snippet
    Post by: MECHFrost on April 07, 2011, 9:21 AM
    Hey, do you mind sharing your Java port?

    (Comment added by MECHFrost on Thu Apr  7  6:22:16 2011)

    Edit: talking to Somnolance.
    Title: RE: GUI snippet
    Post by: Sombalance on April 07, 2011, 9:34 AM
    Nope, I wasn't changing the window size.

    I'll play around with it more today.  The only reason I
    noticed it was that the first time I connect with a plugin,
    there is a noticeable delay in sending/receiving text to the
    screen. After about three or four commands, the delay is gone
    and doesn't appear again unless I completely close MushClient
    before attempting to login again.  I thought I might have been
    spamming a negotiation sequence.  That doesn't seem to be the
    case though, although I haven't ruled out something goofy in
    my stuff.

    Sombalance
    Title: RE: GUI snippet
    Post by: Sombalance on April 07, 2011, 9:41 AM
    Nope, I don't mind sharing it, but you should be aware I've
    only been programming in Java for about 3 weeks now.  I got
    the urge to learn Java and decided that a simple hello world
    tutorial wouldn't cut it.  I'll post it somewhere this weekend
    with an appropriate "use at own risk" type warning.  I am
    still testing it out to see that I haven't wrecked it.

    Sombalance
    Title: RE: GUI snippet
    Post by: KaVir on April 07, 2011, 11:12 AM
    > Nope, I wasn't changing the window size.

    Was the value different each time, or was it always the same?  If it's changing then it sounds like a MUSHclient issue - what version are you using?

    If it's not changing, check whether it does the same in my snippet or just in your ported version.  If the latter, it could be you're not clearing the buffer after receiving the sequence.

    The delay with the plugin is probably because it's redrawing everything each time it receives new data.  It should ideally be changed to only redraw the things that change, and not draw anything initially until all of the data has arrived.  As I said before, the plugin could really do with a rewrite.
    Title: RE: GUI snippet
    Post by: jbrianclar on April 20, 2011, 3:30 AM
    Hey,

    Using the plugin on tbaMUD I am getting the below crash
    every time a zmud 4.62 client connects...

    Program received signal SIGSEGV, Segmentation fault.
    0x080a3639 in process_input (local_mother_desc=5) at
    comm.c:1922
    1922        *(read_point + bytes_read) = '\0';  /* terminate
    the string */
    (gdb) bt
    #0  0x080a3639 in process_input (local_mother_desc=5) at
    comm.c:1922
    #1  game_loop (local_mother_desc=5) at comm.c:820
    #2  0x080a4878 in init_game (argc=2, argv=0xbffff7e4) at
    comm.c:512
    #3  main (argc=2, argv=0xbffff7e4) at comm.c:353
    (gdb)

    any ideas or ways I can go about debugging this. It has
    happened once before when I just connected with putty. It
    never has issues with wintin or MUSHClient.
    Title: RE: GUI snippet
    Post by: plamzi on April 20, 2011, 11:21 AM
    What are the lines in the earlier frames? What does the input string it crashes on look like?

    Also, do I understand you correctly that you've had this happen to you once before you had the snippet installed?
    Title: RE: GUI snippet
    Post by: jbrianclar on April 20, 2011, 12:06 PM
    the input string crashing is after the user enters in a
    correct password.

    This never happened before adding the snippet. I just stated
    it happened after the snippet with putty (once) although I
    cannot repeat it with putty. I can repeat the crash with
    almost every old version of zmud until the 7.x line of zmud
    clients -- which work perfectly.
    Title: RE: GUI snippet
    Post by: KaVir on April 20, 2011, 4:39 PM
    I'm not really familiar with TBA (which is why I'd been hoping someone else would write up the instructions), but from a cursory glance you could try changing this:
        if ( bytes_read >= 0 )
        {
          read_buf[bytes_read] = '\0';
          ProtocolInput( t, read_buf, bytes_read, t->inbuf );
          bytes_read = strlen(t->inbuf);
        }
    To this:
        if ( bytes_read >= 0 )
        {
          read_buf[bytes_read] = '\0';
          ProtocolInput( t, read_buf, bytes_read, read_point );
          bytes_read = strlen(read_point);
        }

    Title: RE: GUI snippet
    Post by: jbrianclar on April 20, 2011, 5:49 PM
    As always, you rock! This fixed the problem!

    There are still a few other oddities, but at least they are
    cosmetic and not causing any problems.

    Thanks again!
    Title: RE: GUI snippet
    Post by: jbrianclar on April 21, 2011, 1:34 AM
    Hey All,

    There is another issue I have run into now. I was testing
    out the functionality by writing the ability to click on a
    vnum to stat an object and the object name to load the
    object when an immortal searches for objects. This works
    fine when I use MUSHClient or a recent version of zmud that
    supports MXP. If I use putty and connect and issue the
    command the mud crashes.


    Program received signal SIGSEGV, Segmentation fault.
    0xb7e8bb33 in vfprintf () from /lib/libc.so.6
    (gdb) bt
    #0  0xb7e8bb33 in vfprintf () from /lib/libc.so.6
    #1  0xb7f2f194 in __vsnprintf_chk () from /lib/libc.so.6
    #2  0x0809f706 in vsnprintf (t=0x83a91e8,
        format=0x8166018 "%3d. \t<send href=\"vstat obj %d\">
    [%5d]@n \t<send href=\"load obj %d\">%-40s@n %s\r\n",
    args=0xbfffe6b8 "\001")
        at /usr/include/bits/stdio2.h:78
    #3  vwrite_to_output (t=0x83a91e8,
        format=0x8166018 "%3d. \t<send href=\"vstat obj %d\">
    [%5d]@n \t<send href=\"load obj %d\">%-40s@n %s\r\n",
    args=0xbfffe6b8 "\001") at comm.c:1356
    #4  0x0809fca1 in send_to_char (ch=0x15,
        messg=0x8166018 "%3d. \t<send href=\"vstat obj %d\">
    [%5d]@n \t<send href=\"load obj %d\">%-40s@n %s\r\n") at
    comm.c:2393
    #5  0x080a8055 in vnum_object (searchname=0xbfffe72c
    "sword", ch=0x83b05e0)
        at db.c:2374
    #6  0x0808baa4 in do_vnum (ch=0x83b05e0, argument=0xbffff4b0
    " obj sword",
        cmd=716, subcmd=0) at act.wizard.c:372
    #7  0x080f63cc in command_interpreter (ch=0x83b05e0,
        argument=0xbffff4ac "vnum obj sword") at
    interpreter.c:607
    #8  0x080a40a5 in game_loop (local_mother_desc=5) at
    comm.c:868
    #9  0x080a4868 in init_game (argc=2, argv=0xbffff804) at
    comm.c:512
    #10 main (argc=2, argv=0xbffff804) at comm.c:353
    (gdb)


    As I have stated, I appreciate the assistance and I do not
    mind paying to have you, or someone, work with me to get
    these little issues resolved. This functionality is fairly
    vital to my project if I am to try and attract as many
    players as possible.
    Title: RE: GUI snippet
    Post by: KaVir on April 21, 2011, 5:08 AM
    > There is another issue I have run into now. I was testing
    > out the functionality by writing the ability to click on a
    > vnum to stat an object and the object name to load the
    > object when an immortal searches for objects.

    You'll have to copy and paste the section of code so that I can see what it's doing - in particular, the part that calls this:

    send_to_char (ch, "%3d. \t<send href=\"vstat obj %d\"> [%5d]@n \t<send href=\"load obj %d\">%-40s@n %s\r\n")

    I need to see what 'ch' is initialised to, and what other arguments you're passing in with the ellipsis.

    You've also forgotten to close the MXP tags, although that shouldn't cause a crash.  From the README.TXT: "As with the extended colour, MXP tags will be automatically removed if the user doesn't support MXP - but it's very important you remember to close the tags."
    Title: RE: GUI snippet
    Post by: jbrianclar on April 21, 2011, 10:33 AM
    Hey,

    I typically do close it with </send> but for some reason
    mushclient must have a bug and was sending the </send> as
    plain text, so I omitted the send so it would display right.
    Zmud does not have an issue using the full <send href> tags
    with ending </send>, but still seems to work if you omit it.

    ch would be a pointer to the player's character structure
    array and at this point they are in state con_playing.

    the other information passed in that function is nothing
    more than the data with the integer/string values inserted
    in for an object's vnum, name, and a tag if it has a
    trigger.

          send_to_char(ch, "%3d. [%5d] %-40s %s\r\n",
                       ++found, obj_index[nr].vnum,
    obj_proto[nr].short_description,
                       obj_proto[nr].proto_script ? "[TRIG]" :
    "" );

    All I did was add in two more obj_index[nr].vnum calls and
    two more %d to put the correct vnum for my send commands.

    Here are the guidelines I was following for using MXP:
    http://www.zuggsoft.com/zmud/mxp.htm#Links

    Title: RE: GUI snippet
    Post by: KaVir on April 21, 2011, 11:26 AM
    > I typically do close it with </send> but for some reason
    > mushclient must have a bug and was sending the </send> as
    > plain text, so I omitted the send so it would display right.

    Are you sure you didn't just forget to put a \t in front of the </send>?  You can't just leave the tags open, they need to be closed or they'll bleed.  The README.TXT has an example of how to do it.

    > All I did was add in two more obj_index[nr].vnum calls and
    > two more %d to put the correct vnum for my send commands.

    Hrm, could it be that you're calling ProtocolOutput() too early, and it's stripping out the tags before applying the arguments?  Try using sprintf() to copy it to a string first, then send that string to send_to_char(), and see if that fixes it.  If so, the TBA installation instructions may need to be changed.
    Title: RE: GUI snippet
    Post by: Macademus on April 21, 2011, 1:40 PM
    if you visit www.mudbytes.net someone has made a patch for adding the GUI to TBA.... I'd suggest checking out that!
    Title: RE: GUI snippet
    Post by: jbrianclar on April 21, 2011, 6:33 PM
    I installed based off that single diff. I did not get any of
    the other documentation, although I have now. That was a bit
    dumb of me. The problem with the send tags was certainly all
    my fault. I did not put a \t before the </send>. I corrected
    this and it worked perfectly.

    That being said, it still crashes when used via telnet. I will
    give what has been mentioned here a try and see what I can
    come up with.
    Title: RE: GUI snippet
    Post by: KaVir on April 21, 2011, 6:50 PM
    > I installed based off that single diff. I did not get any of
    > the other documentation, although I have now.

    Not sure which documentation you're using, but my latest TBA instructions can be found here: http://www.godwars2.org/download/INSTALL_TBA.TXT

    > That being said, it still crashes when used via telnet. I will
    > give what has been mentioned here a try and see what I can
    > come up with.

    Try the sprintf() thing.
    Title: RE: GUI snippet
    Post by: jbrianclar on April 25, 2011, 2:59 PM
    Ok, doing the sprintf does not crash the MUD, but it also
    does not send the MXP tags. It really doesn't help me drill
    down any further into what is causing the problems. I can
    repeat this on stock tbaMUD so right now MXP tags sent via
    send_to_char to a non MXP client running putty or something
    of the sort will crash the MUD.

    sprintf code:

          sprintf(buf, "%3d. [\t<send href=\"vstat obj
    %d\">%5d\t</send>] %-40s %s\r\n",
                       ++found, obj_index[nr].vnum,
    obj_index[nr].vnum, obj_proto[nr].short_description,
                       obj_proto[nr].proto_script ? "[TRIG]" :
    "" );
          send_to_char(ch, "%s", buf);

    output on mud for both MXP/non MXP clients:

    vnum obj sword
      1. [  <send href="vstat obj 21">   21 </send>] War's Blood                              
    [TRIG]
      2. [  <send href="vstat obj 1293"> 1293       </send>] a
    sharp looking samurai sword            
      3. [  <send href="vstat obj 3021"> 3021       </send>] a
    small sword                            
      4. [  <send href="vstat obj 3022"> 3022       </send>] a
    long sword          
    Title: RE: GUI snippet
    Post by: KaVir on April 25, 2011, 5:56 PM
    > Ok, doing the sprintf does not crash the MUD, but it also
    > does not send the MXP tags.

    Because you're doing it like this:

    > send_to_char(ch, "%s", buf);

    As I said in my previous post, it appears you're calling ProtocolOutput() too early, and it's stripping out the tags before applying the arguments.  There are no tags in the string "%s", therefore nothing is being stripped out.

    Try: send_to_char(ch, buf);

    Or better yet, move the call to ProtocolOutput below the vsnprintf() - this works correctly if you follow the installation instructions I posted, rather than the diff.

    Here is the link once more: http://www.godwars2.org/download/INSTALL_TBA.TXT

    I'd suggest going through it and making sure everything is in the right place.
    Title: RE: GUI snippet
    Post by: jbrianclar on April 25, 2011, 9:36 PM
    I moved protocoloutput below the vsnprintf and now nothing
    works. It sends the actual tabs to the client....

    code:

      wantsize = size = vsnprintf(txt, sizeof(txt), format,
    args);

      length = strlen(format);
      format = ProtocolOutput( t, format, &length );  /* <---
    Add this line */
      if ( t->pProtocol->WriteOOB > 0 )         /* <--- Add this
    line */
          --t->pProtocol->WriteOOB;             /* <--- Add this
    line */

    mud output now is
    ------------------
     1204] the overseer's outpost [ INDOORS ] [ Inside]
       The main hang out of the Gods, the Immortal Board Room is
    the place to be.  
    Gods exchange messages here most every day.  The mortal
    board room is to the
    east and the meeting room for the gods is to the south.  To
    the north is the
    Gods' Inn and to the west is a post office for Gods.  In the
    northeast corner
    you spot a small staircase leading upwards.
    [ Exits:        (n      )       (e      )       (s      )      
    (w      ) ]
    [3098] A large expensive computer terminal is here waiting
    to be accessed.

    500HP 100AP 82MV >
    vnum obj sword
      1. [  <send href="vstat obj 21">   21 </send>] War's Blood                              
    [TRIG]
      2. [  <send href="vstat obj 1293"> 1293       </send>] a
    sharp looking samurai sword            
      3. [  <send href="vstat obj 3021"> 3021       </send>] a
    small sword                            
      4. [  <send href="vstat obj 3022"> 3022       </send>] a
    long sword

    Title: RE: GUI snippet
    Post by: KaVir on April 26, 2011, 4:55 AM
    > I moved protocoloutput below the vsnprintf and now nothing works.

    Because you're still using that diff file from MudBytes, and not the instructions I posted a link to.  The code needs to look like this:
      wantsize = size = vsnprintf(txt, sizeof(txt), format, args);
      strcpy(txt, ProtocolOutput( t, txt, (int*)&wantsize )); /* <--- Add this line */
      size = wantsize;                    /* <--- Add this line */
      if ( t->pProtocol->WriteOOB > 0 )   /* <--- Add this line */
        --t->pProtocol->WriteOOB;         /* <--- Add this line */
      if (t->character)
        wantsize = size = proc_colors(txt, sizeof(txt), COLOR_ON(t->character));
    If you follow the instructions in INSTALL_TBA.TXT, your implementation will work.
    Title: RE: GUI snippet
    Post by: jbrianclar on April 26, 2011, 2:54 PM
    You are right, and I am sorry for not listening sooner. I will go through INSTALL_TBA.TXT tonight and ensure everything matches up as it should.

    (Comment added by jbrianclar on Tue Apr 26 14:47:33 2011)

    Ok, the only line I was missing was that 1 line from comm.c. I
    did follow the other instructions and made the changes to
    protocols.c and such earlier.

    That one change fixed the problem and now it works perfectly!
    Title: RE: GUI snippet
    Post by: KaVir on May 22, 2011, 7:11 PM
    If anyone has used the Merc installation instructions, please be aware that I missed something - thanks go to Bryantos for pointing it out.

    In read_from_description(), you need to replace this:
        /* Check for overflow. */
        iStart = strlen(d->inbuf);
        if ( iStart >= sizeof(d->inbuf) - 10 )
    With this:
        /* Check for overflow. */
        iStart = 0;
        if ( strlen(d->inbuf) >= sizeof(d->inbuf) - 10 )
    Without that change, spammed commands will be silently dropped, which can be rather annoying (particularly for movement).
    Title: RE: GUI snippet
    Post by: Keriwena on May 23, 2011, 12:20 AM
    Cool, thanks. I'd noticed that happen, hadn't related it to the snippet.
    Title: RE: GUI snippet
    Post by: KaVir on June 14, 2011, 6:47 AM
    I've updated the snippet to resolve a couple of issues that were recently brought to my attention.  If you're already using the snippet, I recommend using diff first, so that you don't wipe over your MSSP variables.

    The first issue is broken packets.  If the client splits the data across multiple packets, the snippet can now handle it correctly.  Thanks go to Tyche for pointing this out.

    The second issue is a bit more tricky.  RFC 1091 provides a mechanism for cycling through multiple terminal types, and the mud uses this standard to detect support for XTerm 256 colors.  However when used with Windows telnet, the client is left in a terminal emulation mode that appears unable to communicate with the mud - and it refuses to return to the top of the list.  Or to put it in simple terms: Windows telnet freezes when it connects to the mud.

    My solution is a bit nasty, but it's simple and effective.  If the first TTYPE is "ANSI", the mud won't request any further terminal types.  This has no impact on dedicated mud clients such as WinTin++ and BlowTorch, as they identify themselves by name on the first TTYPE request.

    There is an alternative approach using escape codes, which I may add in the future, but it comes with a different drawback; the mud would need to pause for a few seconds before displaying the login screen.  However this approach would also allow you to avoid the automatic disabling of echo for Windows telnet users.


    Title: RE: GUI snippet
    Post by: KaVir on August 28, 2011, 7:30 PM
    I've updated the snippet again, primarily because the MSDP specification has undergone several changes since the snippet was released, but also to resolve a few issues I've encountered while helping other people install it.

  • Added an AllocString() wrapper function, as strdup() isn't standard C.
  • Added support for the new MSDP tables and arrays.
  • Added support for the new UNREPORT and RESET MSDP commands.
  • Added a new REPORTED_VARIABLES list, as described in the latest MSDP spec.
  • Renamed VARIABLES to SENDABLE_VARIABLES as described in the latest MDSP spec.
  • Cleaned up the code, adding consts and fixing -ansi and -pedantic warnings.
  • Added support for the new Mudlet GUI autoinstaller.
  • Added an MCCP flag to make integration with the snippet easier.
  • Updated CopyoverGet() and CopyoverSet() to include TTYPE, MCCP and CHARSET.
  • Added an MSDPFlush() function for variables that need to be sent immediately.
  • ProtocolOutput() now lets you send tabs.
  • The snippet now recognises that DecafMUD supports 256 colours.
  • Updated the TBA instructions with a fix for strfrmt().
  • Updated the installation instructions to use MSDP tables.

    You can download the latest version from my website here - I've updated it on MudBytes as well, but it's still pending approval.

    An updated version of the generic MUSHclient plugin can be downloaded from here.

    The following muds are now using the snippet to offer their players cutting-edge protocol support:

  • 4 Dimensions (only on the test port for now, but see here and here)
  • Ansalon MUD (ansalonmud.net 8679)
  • Arcane Nites (arcanenites.com 7000)
  • ChaosMUD (chaosmud.com 1111)
  • CyberASSAULT (cyberassault.org 11111)
  • Dark Lair (tiopon.mudmagic.com 3500)
  • Fallout: The Dirty South (falloutsouth.net 4000)
  • God Wars II (godwars2.org 3000)
  • GodWars: Rebirth of Apocalypse (apoc.godwars.net 6660)
  • Land of Eternal Sun (simba.darknessmuds.co.uk 5645)
  • Pict (omen.genesismuds.com 4200)
  • Realms of Despair (realmsofdespair.com 4000)
  • Storm Hunters (sh.ackmud.net 7000)
  • The Builder Acadamy (tbamud.com 9091)
  • The Realm of War (row.godwars.net 2000)
  • Tir na nOg (66.212.25.125 6789)

    If you've added the snippet but aren't on the above list, please let me know!

    There are also a few other muds that have implemented their own MSDP solutions, including The 7th Plane (7thplane.net 8888), which has also incorporated a few of the other features from the snippet, ConQUEST (conquest.sdmud.com 5000), Elvenblade (elvenblade.ca 23), and Lowlands (lolamud.net 6969).

    Meanwhile, I've seen a few more muds adding support for GMCP, which offers similar functionality to MSDP.  Both protocols make it considerably easier to design graphical interfaces, so it's pretty exciting to see more and more muds taking the plunge.



    (Comment added by KaVir on Mon Aug 29  2:07:03 2011)

    The latest version is now available directly from MudBytes.

    (Comment added by KaVir on Thu Sep  1  6:04:07 2011)

    If you're using version 3, there's a bug in AllocString() - you need to replace malloc(Size) with malloc(Size+1), to take into account the NUL string terminator.  The above link now points to version 4, which includes the fix.
  • Title: RE: GUI snippet
    Post by: scandum on September 02, 2011, 1:15 AM
    I wasn't sure whether to start a new thread for this, but figured to post this here as the subject is identical.


    I finished work on MTH 1.4, a public domain telnet / protocol handling snippet this week and it's now available for download here.

    MTH 1.3 (released April 6, 2009) added support for NAWS, TTYPE, NEW-ENVIRON, MCCP, and MSSP. The MCCP implementation might be of interest to some because it uses 32K of memory per player, instead of the 138K used by most MCCP implementations.


    MTH 1.4 adds support for EOR, MSDP, MTTS, Arachnos, and xterm 256 colors.


    MSDP follows specification and should work with KaVir's MUSHClient plugin. In addition the MTH snippet has a walkthrough for implementing the ROOM variable, which combined with this TinTin++ script provides you with a status bar and fully automatic automapping. screenshot Not a whole lot of eye candy, but it's very effective, and will work with any other client that can parse MSDP and has an OOB mapper.



    MTTS is a standard I created to negotiate terminal capabilities to the server. It's currently only supported by TinTin++, and in MTH it's used to detect 256 color support, and can be used to detect ANSI, VT100, UTF-8, and SCREEN READER support as well. MTTS is very easy to add both client and server side, unlike other alternatives.


    Arachnos is an MSDP based Intermud network. Arachnos is relatively easy to implement for any MSDP enabled MUD. Instead of the traditional Intermud systems where you connect your MUD to a central server, an Arachnos spider connects to your mud using the normal connection, then uses MSDP to receive and transmit chat messages. Intermud gaming spiders are a likely future addition as anyone can create and run a spider. More information is available in the spec.

    xterm 256 colors MTH extends the classic 16 color ANSI color system to a 32 color system using xterm color codes. ANSI supports 6 primary, 6 secondary, and 4 gray-shade colors. MTH adds the 12 tertiary colors, and 4 gray-shade colors. A stand alone version of the color snippet and a screenshot is available here. The code also supports color code compression.


    Enjoy.
    Title: RE: GUI snippet
    Post by: KaVir on October 12, 2011, 6:19 PM
    While helping Splork get the snippet working in SlothMUD, we came across an interesting problem - it seems that the MXP specification doesn't actually define whether the server should initiate negotiation with IAC WILL MXP or IAC DO MXP.  While some clients therefore support both, others support only one or the other.  I've therefore updated the snippet to support both (it attempts one if the other fails).

    There was also a complaint from another user about the MSSP table being cumbersome to update for non-static fields such as players and uptime.  I've therefore changed the table to use function pointers, which should make it much easier to update in future.

    Scandum also asked me to change LIST to use an array, as per the latest specification, which I've done.

    Other than that there were a couple of bugfixes, but nothing serious.  Here's the list of changes:

  • Added symbolic constants for MSDP_TABLE_OPEN/CLOSE and MSDP_ARRAY_OPEN/CLOSE.
  • MSDPSetArray() was using table values rather than the array values.  Fixed.
  • Added MSDPSendList(), used for the MSDP LIST command (updated to an array in the spec).
  • Doubled MAX_VARIABLE_LENGTH for the list variables.
  • Some of the LISTs had no separators between values when sent using ATCP.  Fixed.
  • The MSSP table now uses function pointers, making it easier to update dynamic fields.
  • Added support for both variants of MXP negotiation.

    You can download version 5 from the usual place.



    (Comment added by KaVir on Wed Oct 12 15:28:31 2011)

    It's also been updated in the MudBytes code repository.
  • Title: RE: GUI snippet
    Post by: ryanwstuck on October 26, 2011, 2:11 AM
    hey kavir. been playing with the gui a bit and have a lot of ideas for it. check out what i have so far

    http://i.imgur.com/mi5K9.jpg

    Title: RE: GUI snippet
    Post by: KaVir on November 19, 2011, 9:00 PM
    Version 6 is now available from MudBytes, and contains the following changes:

  • Removed a stray semicolon.

    The "if ( !pProtocol->bMSDP );" statement had a semicolon at the end, which should be removed.  This bug has very little impact, as MSDP already overrides ATCP, but it does mean that if the user's client supports both MSDP and ATCP, they will be sent the SERVER_ID variable twice.

  • Made it easier to add MCCP support.

    Quite a few muds already support MCCP, and had trouble getting it working with the snippet - particularly if they were using copyover as well.  So I've improved the documentation and made it easier to integrate.

  • Made several minor updates to the installation instructions.

    The INSTALL_MERC.TXT had actually been written for GodWars rather than Merc, and relied on a couple of GodWars-specific changes.  It's been updated to work with both, and now also defines MSDP_CLASS.  The INSTALL_TBA.TXT instructions now define MSDP_CLASS as well.

  • Added an INSTALL_ROM.TXT.

    Although the ROM instructions are very similar to Merc, there are a few minor differences, and someone had trouble adding it to their ROM derivative.  So I added another set of installation instructions.




  • Title: RE: GUI snippet
    Post by: KaVir on August 22, 2012, 4:24 PM
    Version 7 of the snippet is now available (from here, and from MudBytes once they accept the latest update), and includes the following changes:

    • Tyche pointed out that the snippet didn't correctly respond to client-initiated negotiation.  This has now been corrected.

    • A side-effect of the above change is that ECHO is now handled through the snippet.

    • MSDP and ATCP could be used without negotiation.  Although this wouldn't really cause any problems, it was sloppy, and has now been fixed.

    • I noticed most people didn't use the colours, instead preferring to use their existing Lopes-style implementations.  The snippet can now emulate that style of colour system, and includes an extended selection of default colours.

    • MUSHclient wouldn't fully negotiate if it was set to autoconnect, and the same may be true of other clients.  The snippet will now attempt to renegotiate in such cases.

    • Someone complained that "public domain" isn't always legally recognised, so I've clarified that the snippet can be used for any purpose without any conditions.

    If you're updating from an older version of the snippet, please don't forget to make a backup of your MSSP and MSDP variables before copying the latest version, and update the appropriate literals for your mud name, MCCP, etc (in fact I'd recommend doing a diff just to make sure you don't miss anything).  You'll need to update to use the new ProtocolNoEcho() function (instructions are in the installation text files), but other than that you shouldn't need to make any additional changes to the rest of your mud.
    Title: RE: GUI snippet
    Post by: KaVir on November 02, 2012, 8:22 AM
    Just a quick update, in case anyone is using version 7.  One of the variables wasn't initialised, resulting in some confusion during negotiation - this has now been fixed, and uploaded for version 8.  There are no other changes other than a couple of additions to the ROM installation instructions.
    Title: RE: GUI snippet
    Post by: Telgar on January 22, 2013, 7:35 AM
    Aweaomw!!!  Thanksh you Kaivr for the awesoneme code.  I have addled it to my
    mud and it is working aewsome.

    Also, seriously, thanks.

    This *CENSORED* da bomb.
    Title: RE: GUI snippet
    Post by: Macademus on January 22, 2013, 2:26 PM
    is it only me who thinks the previous post is from someone
    trying to be smart?

    Kind of like a Locke sock puppet?? or something?
    Title: RE: GUI snippet
    Post by: Molly on January 23, 2013, 10:33 AM
    It might be a troll, but if so, it's a cute troll. :)