Mudlet - Forum

I'm having an issue with special characters, below is an example of how it looks. I want them displayed just like I sent them. I have tried every setting I can find in mudlet with no luck. I'm running mudlet 1.1.1 on Mac OS X 10.6. Any ideas?

say åäö
You say, "åäö"

Sorry for bumping, but after reading around this behavior may occur if the client don't support UTF-8 or unicode?

Can this be the reason å, ä and ö gets messed up, and is there a solution to fix it.

Yep, that's true. Full unicode support requires it being compatible with Lua and there's not enough interest in that atm.

Thanks for clearing that up:)

Guess I'll go back to VMware+zmud until support for unicode might get added. If I could code I would have helped you guys out with it. Anyway, keep up the good work and thanks again.

/Fredrik

Sorry to necro an old thread, but this was the closest I could find to my question.

Although I'm still adding the finishing touches to my Mudlet GUI, even when it's finished it'll still require people to manually download and install it, and a lot of players don't bother to hang around that long. So I've also been looking at ways to improve the cosmetics of that "first impression" newbies get when they initially connect.

I already auto-enable 256 colours for anyone using Mudlet 1.1 or later, and I've started using the extended colours in the ASCII maps - but now I've been wondering about using Unicode characters to produce nicer-looking maps.

Last night I had a brief play with UTF-8, which has the major advantage of being backward-compatible with ASCII, making it extremely easy to add to the mud - you don't need to change anything, you just send the (longer) byte sequence for the Unicode character/s you want.

I don't think this would actually require any changes to the Lua support, either. It's really just a display thing - convert unprintable character sequences into their Unicode equivalent when displaying them in the text window. UTF-8 doesn't use the byte values 192, 193, or 245+, either, so there wouldn't be any conflicts with telnet options.

The only limitation is that the font would need to offer the Unicode character set, and not all do. But if there was some way to identify that support, it would allow muds to enhance their output for Mudlet users without the need for any configuration, let alone downloading and installing special packages.

Is there any possibility of UTF-8 being added as an alternative to full Unicode? Or perhaps it's already been added since this thread, and I just need to enable it somewhere?

1. Mudlet had full unicode support in the beginning (and partly still has today), but I've dropped it at some point because Lua isn't capable to deal with unicode and thus we'd open a huge can of worms if we had some half baked support. Mudlet uses unicode internally (also for the buffer and the display), but you need to transcode this to ASCII when the data is passed into Lua and then transcode it to unicode again when the data passed back from a Lua script. As this is inefficient for everybody else we'd need to patch the relevant Mudlet Lua API to do this automatically for Chinese MUDs. Then we also need to patch a good deal of the native Lua API to deal with unicode e.g. all string manipulation functions would need to be patched to be able to cope with unicode. This is a lot of work that is only interesting for Chinese users. I couldn't find Chinese developers who were willing to spend a fair bit of time to add full support for Chinese. I've built test versions with basic support for Chinese (-> thread on support for Chinese with screenshots to illustrate the problems) but I really needed native speakers to make it decent enough. The problem is that Chinese MUDs use diagraphs and monographs i.e. some characters should be printed at single character width instead of the usual 2 characters width. We'd have to know which characters are expected to be displayed how, otherwise the ASCII art looks twisted. It's up to the Chinese MUD community.

2. Your GUI should either be shipped with Mudlet directly or downloaded automatically when the player connects to your MUD for the first time or both e.g. ship the main GUI and download the avatars or other files & graphics on demand. As you are the first MUD admin to make a complete GUI you have the freedom to design a good ATCP mechanism to announce that your MUD offers a GUI and tell Mudlet which files have to be downloaded, etc.. In my opinion GUIs don't make any sense whatsoever for new players if they aren't set up fully automatically. This should be done in such a way that the server can decide everything and Mudlet just does what the server tells it to in order to setup the GUI.

Heiko wrote:1. Mudlet had full unicode support in the beginning (and partly still has today), but I've dropped it at some point because Lua isn't capable to deal with unicode and thus we'd open a huge can of worms if we had some half baked support.

I understand the problem for regular Unicode. However UTF-8 has the advantage of being compatible with ASCII, so I don't see why you'd need to convert anything except when displaying it. In fact I don't see why Lua scripts would even need to know about it - they could treat it exactly like a sequence of regular ASCII characters (because as far as Lua is concerned, that's exactly what it is).

There has also been some talk in the past of creating a custom mud font, and if that were done I think it would make sense to make it a Unicode font. It could then provide symbols for wilderness maps, dungeons, charts and tables, monsters, equipment, furniture, classes, runes, spells, etc. If several clients could be persuaded to include the font with their distribution, it could provide a very useful tool for mud developers.

It's not urgent, particularly if my GUI can be automatically downloaded by new users, but it would still be a nice thing to have. Even if you're using graphics for maps and such, there is still a lot of data in the text window.

Heiko wrote:2. Your GUI should either be shipped with Mudlet directly or downloaded automatically when the player connects to your MUD for the first time or both e.g. ship the main GUI and download the avatars or other files & graphics on demand.

I hadn't realised that was an option, but it would certainly make things much easier for the players. I include a lot of graphics, so I don't think it would be appropriate to ship everything with Mudlet, and I'd rather not have the files downloaded directly from within mud.

Would it be possible for Mudlet to download and extract a specific file from a website, if the mud provided the URL? Sort of like:

Server: IAC DO ATCP
Client: IAC WILL ATCP
Server: IAC SB ATCP "Client.GUI <version> \n <path and filename>"

Then the client could pop up a window on login informing the user that this mud offers a custom GUI, and asking if they want to install it (with a "don't ask again for this mud" checkbox). If they've already installed it but have an older version number, then they could be asked if they wish to update.

I'd suggest automatically creating a folder for each mud, perhaps using its profile name, so that muds don't accidently (or intentionally) write over each other's files. It may also be worth having some sort of certification to reduce the risk of malicious scripts being distributed - perhaps even allow mud owners to submit their GUI files to a Mudlet repository, where it can be checked for anything dodgy, and allow the client to download directly from there.

Should sound files be distributed as part of the GUI, or separately? Not many of my players seem to use sound, but it's still quite a nice option to offer, particularly when targeting first-time mudders who are used to playing games with both graphics and sound.

KaVir wrote:I understand the problem for regular Unicode. However UTF-8 has the advantage of being compatible with ASCII, so I don't see why you'd need to convert anything except when displaying it. In fact I don't see why Lua scripts would even need to know about it - they could treat it exactly like a sequence of regular ASCII characters (because as far as Lua is concerned, that's exactly what it is).

The problems start when you're dealing with characters outside of the ASCII range.

There has also been some talk in the past of creating a custom mud font, and if that were done I think it would make sense to make it a Unicode font. It could then provide symbols for wilderness maps, dungeons, charts and tables, monsters, equipment, furniture, classes, runes, spells, etc. If several clients could be persuaded to include the font with their distribution, it could provide a very useful tool for mud developers.

We are already shipping a public domain font in order to have a decent standard font for all platforms. If a MUD font was created and used by several MUDs I'd reenable unicode mode and offer a transcode functions. This will not be a priority though as when the mapper is done my primary focus will be on providing very good support for blind users.

I'll move the GUI download part of the thread to the GUI thread for easier future reference.

How does Mudlet currently handle Unicode data? If it's altered in any way, can you create a branch of Mudlet where it just passes the raw byte sequence on to Lua? I've got a Unicode library for Lua that I could try to integrate into LuaGlobal in a way that's transparent for users, overriding the normal string library functions with the ones that can handle Unicode.

KaVir wrote: Would it be possible for Mudlet to download and extract a specific file from a website, if the mud provided the URL? Sort of like:

Server: IAC DO ATCP
Client: IAC WILL ATCP
Server: IAC SB ATCP "Client.GUI <version> \n <path and filename>"

I've seen something very much like this in a different medium (LOVE, a Lua 2D game engine). This user has set up github as a kind of repository; the game, on startup, downloads a manifest file and checks that against the user's current manifest, and downloads and updates as appropriate.

Theoretically, with downloadFile( path, URL ), it's possible to do the same in Mudlet. It's not something I've played with, but it is an interesting concept. Barring a fully-formed Mudlet package repository (with proper package support, of course), this is the next best thing. It would require that as much of the scripting as possible be moved to separate .lua files in order to ease replacement, which introduces other problems (no scriptable Events, can permanent items be deleted via script? to name a couple).

But the pieces exist to put something usable together.