No encoding setting on Linux/Mac?

[Mad Daimond]

Hello to this forum, I have return to MUDs after some years, but now I can’t find the option to change encoding on Mac/linux Mudlet client, the option just no exists in “General” preference tab. It is still there on Windows, through. What happens with this option and how I can change encoding on Linux/Mac?

[demonnic]

I see them myself in the MacOS version, just checked.
Using version 4.16.0 in all cases?

It's next to the Mudlet interface language for me, labeled "Server data encoding"

[Mad Daimond]

Cant use the last version, because I am on old Mac and Linux pc now, it has x86 architecture. But I am double checked, the encoding option was introduced in 3.2.0 version and it is works on my Mac. Better then nothing. But the last version for x86 linux is 3.1.0, this is sad.

[SlySven]

You're (probably) not totally out of luck - you'll just have to build a 32-bit build of the latest source code yourself. Even now the Windows build is still IIRC a 32-bit build - it is just that our CB (Continuous Build) systems on macOs and GNU/Linux are only available in 64-Bit flavours. Take a look at https://wiki.mudlet.org/w/Compiling_Mudlet#Compiling and see if there is anything that matches your Linux distribution; generally the differences between the different ones are down to the exact names needed for the packages that you need to have installed for Mudlet to:

• compile against (with header files with something like `dev` suffixes)
• libraries for it to link with (the same name packages without "dev" or "devel" suffixes)
• tools, including a compiler, to build Mudlet with

[nullByte]

Code: Select all

Technical information:
Version   Mudlet 4.16.0
OS        Fedora Linux 35 (Thirty Five)
CPU       x86_64

I have multiple encoding options in preferences. From server side encoding to client side log encoding... uname -a?

[SlySven]

It usually comes down to what the Server is using (or has been told by the user to use). Mudlet does now try and negotiate with the Server but if it doesn't handle Telnet sub-option 42 (CHARSET) you can try the default (of UTF-8) and see how that goes (that will also handle ASCII fine)...