The Mud Connector

Author Topic: Renting, port numbers and other questions.  (Read 5777 times)

RahjIII

  • TMC Member
  • ***
  • Posts: 149
    • View Profile
    • The Last Outpost
Re: Renting, port numbers and other questions.
« Reply #30 on: May 17, 2018, 9:42 AM »
UTF-8 is a character encoding type like ASCII, and if your client supports MTTS protocol, it might provide a client option to say whether or not you want it to indicate support for UTF-8 up to the server.  No clue what that other stuff is.

What client are you seeing these options in, Flint?
"The Last Outpost"

Tijer

  • TMC Veteran
  • *****
  • Posts: 814
    • View Profile
Re: Renting, port numbers and other questions.
« Reply #31 on: May 17, 2018, 11:00 AM »
As far as i know some of those are terminal emulations for ssh/telnet clients.. doesnt really make much of a difference to muds...  As RahjIII says UTF8 allows for an extended charset
--Tijer

Flint Stovetop

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: Renting, port numbers and other questions.
« Reply #32 on: May 17, 2018, 11:44 PM »
Curious x-IBM is listed twice.  I believe those have to do with API and has nothing to do with your mudding phone experience, I would use the default.

There are "x-ibm's" and "x-IBM's", both followed by a few numbers.  I am not sure of the significance, if any, of the lower and upper casing.

What client are you seeing these options in, Flint?

I primarily use Blowtorch for mobile text gaming.  But I found these options in bMudclient on the Google Play Store.  There are several more kinds besides the ones I mentioned and most have dozens of different versions for each type.  I would say between 200 to 300 different options.  I was just kind of taken aback so I just use the default.

RahjIII

  • TMC Member
  • ***
  • Posts: 149
    • View Profile
    • The Last Outpost
Re: Renting, port numbers and other questions.
« Reply #33 on: May 18, 2018, 10:31 AM »
I would guess that they are character set encodings.  Some languages, Korean or Russian for example, use a character set that is different from ASCIII.  If you connect to a mud that is serving one of those languages, you'd need a client that could use that character encoding in order to play.  It looks like bMudClient has support for that. 

The thing about adding support for character set encodings is that it's usually easier to add support for all of them at once than it is to add support for a single target language.   So an app might end up with a menu full of esoteric encoding names to choose from, depending on how many your operating system has installed. 

Unless you know the mud you are trying to play requires a specific code-page, you should set your encoding to UTF8, and you'll be fine. 
"The Last Outpost"

nullscan

  • TMC Member
  • ***
  • Posts: 139
    • View Profile
Re: Renting, port numbers and other questions.
« Reply #34 on: May 18, 2018, 1:01 PM »
As far as i know some of those are terminal emulations for ssh/telnet clients.. doesnt really make much of a difference to muds...  As RahjIII says UTF8 allows for an extended charset

On an ASCII MU, written 100% in English language, which all the original MUs were, UTF-8 wouldn't make any difference at all because UTF-8 was specifically and deliberately engineered to be backward-compatible with ASCII.  ASCII is a 7-bit character encoding, UTF-8 is an 8-bit character encoding within the ASCII printables range.  If you used UTF-16 on an ASCII MU, every other byte will be 0x00 (and the client may transmit a leading Byte Order Marker or BOM at the front of every text string) so you may either send garbage/unreadable input since 0x00 is a string-terminator in data for the C programming language, or you may not be able to connect at all when the BOM is mistaken for data corruption in-transit and the MU just gives up on you.

On a UTF8-MU, written mostly in the English language but using some characters like the umlaut or other Unicode character-enhancements, running in ASCII mode would result in your client printing garbage/unreadable characters.   On a UTF16-MU, written 100% in the English Language, using either UTF-8 or ASCII will both cause problems because the MU expects every other byte to be 0x00 and instead you'll send every byte as a straight-through character.

As RajIII points out, ASCII and Unicode aren't the only encodings and some of those options aren't encoding-related.  Unicode could/should be the only one you encounter in MUs built in the last 10 years or so, but there are older implementations that use encodings that were created before Unicode.