FMud 1.0 Alpha Release
12th October, 2011 | Coding, FMud, Games | 21 Comments
It seems like forever since I updated FMud so here is a new version with some new features that hopefully people will find useful. My versioning scheme went out the window some time ago so I’ve decided to call this 1.0 alpha as there are quite a few major new features and hopefully once they are all working properly it’ll be mostly feature complete.
A lot of the new functionality hasn’t had much testing so if you come across any problems please let me know and I will try to fix them ASAP. Bear in mind that MXP is only partially supported and life is probably too short for me to expand it much beyond what is in place now.
Skinning
There is now an images directory at the same level as the swf which contains png images for each of the buttons and one named ‘skin.png’ which can be used to overlay the entire client to provide a more custom graphical look. Simply replace the button images and skin file with your own graphics. I’ve included some plain buttons and a basic skin.png image you can use as a template. Unfortunately the buttons don’t support different states but this was the only way to do it and have the images loadable at run time.
You can also adjust the spacing of the output and command windows relative to the edge of the container in order to better accommodate your custom skin. This is done using flashvars in the embedding page, see the README for a list of the new parameters.
MSDP Support and External Interface
The client will negotiate MSDP and can accept basic MSDP_VAR and MSDP_VAL data which is then passed to the container in the receive_msdp function. Each line from the server is also passed to the container using the receive_text function:
function receive_msdp (msdp_var:String, msdp_val:String):void function receive_text (txt:String):void
In addition, FMud implements the following callbacks from the container for sending data back to the server:
function send_msdp (msdp_var:String, msdp_val:String):void function send_text (txt:String):void
In theory this should allow you to build a GUI in javascript on the embedding page around FMud and communicate back and forth.
This was requested by a couple of people but it’s not something I have much experience with and is basically untested so please let me know if it isn’t working as intended.
MXP Support
FMud now supports SEND, A, GAUGE, COLOR and IMAGE tags, as well as SUPPORTS and VERSION. Context menus using send are also supported. Querying of specific tags using SUPPORT is not available, instead the client will send the full list of supported tags regardless.
Only temp secure mode (4) is supported so you need to send ESC[4z before each MXP tag. There is no negotiation.
Simple !ELEMENT definitions are also supported with a single attribute only, for example you could define the element ‘x’:
<!el x '<send href="&text;|l &text;" hint="move &dir;|look &dir;">' att='dir'>
You could then send the following shorthand tag:
<x 'over the hill'>hill</x>
Which would be parsed as:
<send href="hill|l hill" hint="move over the hill|look over the hill">hill</send>
When clicked this link would open a context menu with two options, “move over the hill” and “look over the hill” which would send the commands “hill” and “l hill” respectively.
Support for up to four gauges is built in using the names gauge1, gauge2, gauge3 and gauge4. You need to specify caption and color attributes for each gauge and then send the data using the entities curr# and max#, for example:
<GAUGE gauge1 caption='Hit Points' color='red'> <GAUGE gauge2 caption='Mana' color='blue'> <GAUGE gauge3 caption='Move' color='yellow'> <!ENTITY max1 100> <!ENTITY max2 100> <!ENTITY max3 100> <!ENTITY curr1 56> <!ENTITY curr2 78> <!ENTITY curr3 24>
The gauges are shown above the input bar so you’ll need to adjust the position of the output window accordingly.
Tags are not case sensitive and !ELEMENT and !ENTITY tags can be shortened to !El and !En. You can use Hex or standard HTML color names with the COLOR tag. Embedding multiple tags within !ELEMENT definitions probably won’t work and embedding tags within tags probably won’t either.
Unicode Support
This is another feature that has been requested a few times now and I’ve implemented what I think is the correct algorithm to decode UTF-8 but I’ve had difficulty finding a live mud to test it on so if anyone uses this on their server please let me know how it works.
You can get the new version from the downloads page. Make sure you check the README for updated flashvars information as well as some more explanation on policy files as this seems to be what trips people up the most.
12th October 2011 at 18:50
The MXP and MSDP support sounds good, I will try and get FMud set up so I can have a play with it.
In regard to Unicode, my mud (and my snippet) identify UTF-8 using CHARSET (RFC 2066) as follows:
Server: IAC DO CHARSET
Client: IAC WILL CHARSET
Server: IAC SB CHARSET REQUEST SEPARATOR “UTF-8″ IAC SE
The response is then either:
Client: IAC SB CHARSET ACCEPTED “UTF-8″ IAC SE
Or:
Client: IAC SB CHARSET REJECTED IAC SE
This works for MUSHclient, TinTin++, Atlantis and DecafMUD, and is apparently partially implemented in BlowTorch.
If it successfully negotiates when connecting to godwars2.org 3000, then when you type “who” you’ll see a gender symbol to the left of each name, and line-draw characters instead of dashes, like this: http://www.godwars2.org/images/plugin_v115_4.png
You don’t need to log on to type ‘who’, you can do it from the connection screen.
12th October 2011 at 20:26
That’s great, thanks. I’ve added in support for CHARSET negotiation and the UTF-8 decoding seems to be working fine as per your screenshot. I’ve also fixed a problem with the MSDP handling and updated the download.
12th October 2011 at 22:49
TinTin++ doesn’t support CHARSET as of yet. It does support MTTS which can be used to detect both UTF-8 and xterm 256 color support.
http://tintin.sourceforge.net/mtts
13th October 2011 at 14:49
For TinTin++ I was just going by http://tintin.sourceforge.net/news.php, which mentioned:
◦ Added support for UTF-8 handling with #config CHARSET UTF-8 enabled.
◦ Added a #config CHARSET option which can be either BIG5, UTF-8.
However I have tested it myself with MUSHclient and DecafMUD, and one of my players tested it with Atlantis, so those definitely work. The BlowTorch developer said (on 23rd March 2011) “I got started on implementing this today and I think everything will be fine. I’m not as far as I’d like to be and going to leave this off of the test build 3. But I will be getting it out soon.” – so although it doesn’t appear to work yet, it’s certainly planned.
There are about 25 people using my snippet, all of whom support UTF-8 through CHARSET, so in combination with the growing popularity of FMud perhaps we’ll see a few more muds start to utilise it.
13th October 2011 at 23:53
That’s the config setting to enable local UTF-8 handling and reporting UTF-8 as enabled using MTTS.
I strongly doubt I’ll support the telnet CHARSET option, the RFC is complicated, confusing, and hasn’t been adopted by clients like PuTTY.
14th October 2011 at 16:45
Hi,
Congratulations on the alpha-release!
Regarding:
Only temp secure mode (4) is supported so you need to send ESC[4z before each MXP tag. There is no negotiation.
I was wondering why you chose to leave the negotiation and other modes out?
It seems to become a trend with new clients to just include a very selective subset of the standard. I’m not a fan of that, because that is OK for tags for which the server can get the info if they are supported via SUPPORT, but for elementary building-blocks of the standard I find this to be a problem. For example, how should the server decide whether MXP support is available, if the client doesn’t negotiate it.
14th October 2011 at 17:35
re: limited MXP support, I may certainly expand on what’s currently supported if enough people want it, but sitting down to do a full MXP implementation isn’t something I’m motivated to do for a free project.
re: negotiation, the way I’ve done it in the past is with a character configuration option on the server as that’s been the most compatible way to handle it for different clients. I can look at adding support for negotiation or other modes if enough people want it though.
16th October 2011 at 00:09
I noticed FMud now freezes when attempting to connect to God Wars II. I checked a few other muds (including those using my snippet) and it seemed fine, so I tried The 7th Plane and that also freezes – like my mud, they use escape codes prior to negotiation to detect Windows Telnet, so I’m guessing that’s the problem.
xtian’s mud (Avalon) uses escape codes too, but they’re not listed on MudGamers so I can’t test if they’ve got the same issue. Likewise, I can’t experiment on my test port to pinpoint the exact cause, because my test port isn’t listed here, so I’m afraid I can’t be much more helpful.
However you may want to have a read over this:
http://posted-stuff.blogspot.com/2010/03/proposal-mud-client-identification.html
I also described my exact solution here:
http://clanscw.brinkster.net/godwars/topic.asp?TOPIC_ID=2675
Regarding MXP: I don’t have an in-game option, nor do any of those using my snippet as far as I know. As players sometimes use multiple clients (eg one at work/school, another at home, another on their smartphone) I prefer to handle it through negotiation.
16th October 2011 at 00:38
Looks like I spoke too soon…I tried to actually *play* some of the muds that use my snippet, and it seems they cause FMud to freeze as well, even though they don’t send the escape codes. Some examples:
GodWars: Rebirth Of Apocalypse (apoc.godwars.net 6660)
4Dimensions (4dimensions.org 6000)
CyberASSAULT (cyberassault.org 11111)
StormHunters (sh.ackmud.net 7000)
So presumably it’s not the escape codes, but something else…but I’ve no idea what. Although if I had to guess, the behaviour does remind me a bit of the way Windows Telnet reacts to cyclic TTYPE requests…
16th October 2011 at 11:50
@KaVir
There was a problem with the MSDP handling but it should be fixed now as I can connect and login to those muds you listed.
Just noticed you mentioned MudGamers – that would explain it as I hadn’t updated that client version. It’s working now.
16th October 2011 at 12:23
just wanted to point out that “waiting for escape codes” works on my MUD, so that can’t be the issue with the alpha (unofficial client test at http://avalon.mud.de/spielen/flash.php).
regards MXP: maybe not having telnet negotiation is a good thing as long as the other MXP sequence modes are not implemented yet? It would break on avalon otherwise atm.
19th October 2011 at 22:50
Hi, I tried to use ‘receive_text(txt)’ when connecting to ‘mud.clessidra.it:4000′, but I receive a javascript error (probably throwed by flash).
Can someone make me an example about send_text(txt) which I can’t use. Regards.
19th October 2011 at 22:55
@Molideus
I haven’t really done anything with that yet so it’s not been tested. What’s the url so I can take a look?
20th October 2011 at 21:38
Hi, there is a text page here:
http://www.clessidra.it/fmud_v2/
PS: just load the page and wait … a javascript error is raised
PPS: press “INVIA” to get another error about the send_text function, but I don’t know if I use it in the right mode.
Thanks.
20th October 2011 at 22:48
@Molideus
I’m not getting a javascript error in Chrome and your divDebug output looks to be working correctly.
To use the send_text callback try something like:
window.document.getElementById(‘FMud’).send_text(‘ciao’);
You may also need to specify allowScriptAccess=”always” in the Flash object.
20th October 2011 at 23:16
Thanks Matt, I’m using Chrome 14.0.835.204 and I get an error: “Uncaught Syntax error: Unexpected Token >”. The same error is raised in Firefox (using Firebug). divDebug output looks correct, I’d like to tell the error however.
About the send_text, I haven’t set “allowscriptacccess”. Tomorrow I’ll try and then i report the solution to all users.
21st October 2011 at 22:48
I have tried “allowscriptaccess” and now I can send custom text. receive_text works but I still receiver error message in Firefox and Chrome and it doesn’t work at all on IE9.
Regards
28th December 2011 at 18:36
I have a bug report and a feature request:
Bug report: It seems that sometimes lines are broken in the middle, as if a linebreak is forced at the end of a packet, even if no \n or \r was received.
And the feature request, could we get xterm 256 color support as described here:
http://www.mudpedia.org/wiki/Xterm_256_colors
Thank you very much if you can do these things.
12th February 2012 at 13:05
Any news about bugfix release?
PS: I have the same problem as Alyssa. Sometimes in differente situation lines are broken
Regards
12th February 2012 at 15:39
The bugs mentioned at the top of the comments should all be fixed in the current download, other than the linebreak issue what else is not working?
22nd February 2012 at 14:44
Hey,
Awesome job here! I have my client working with MSDP, though not yet with MXP. It’s located at http://www.ageofdragons.org/FMud/starwars.html. I modeled it after Molideus’ client. Using KaVir’s protocol patch for TBAMUD.
For those wondering how to do it, you need to manually send out the MSDP using the MSDPSendPair function. I recommend creating a sendMSDP function that has all of these calls in in, and then caling that function everytime there is output (vwrite_to_output worked well for me in comm.c).
The reason why you don’t want to call it in msdp_update is because it seems when MSDP is sent in FMUD, a small line about 2 or 3 pixels high gets send to the screen output. It’s blank, and not noticable when the msdp is only sent on output, but if you send it every second, with msdp_update, it will cause your screen to scroll every second just a tad… eventually if you’re idle causing your display to go blank (unless you scroll up).
Great work though, very handy!