FOSS gamedev and creative worlds

Hi, if I join the server Minemacro 1.0 Brasil and look on a sign, most likely I see the text “<invalid multibyte string>”.

What went wrong here? Do other players experience this problem, too?

I use GNU/Linux; Linux 3.9.4 and Minetest 0.4.8.

I saw you on the server.
The other players were able to see the signs normally.
Perhaps this is because of different coding.
Use windows 7.

brunob.santos wrote:Use windows 7.

NO!

Wuzzy wrote:Hi, if I join the server Minemacro 1.0 Brasil and look on a sign, most likely I see the text “<invalid multibyte string>”.

What went wrong here? Do other players experience this problem, too?

I use GNU/Linux; Linux 3.9.4 and Minetest 0.4.8.

There is no Minetest 0.4.8....
Anyway, does your Minetest build have freetype support compiled in?

PilzAdam wrote:NO!

I use windowns 7. only warning.

Whoops, I meant of couse version 0.4.7.

PilzAdam wrote:

brunob.santos wrote:Use windows 7.

NO!

lol

I don’t know wheather I had FreeType support. I was using the Arch Linux build.

Anyways, I just built version 0.4.7 from source with the FREETYPE flag set. Then I joined the server again but there were still the invalid multibyte strings. :-(

On this new build I also made a new test. I started a new minetest_game world and placed a sign and used a text with the character “ü” in it. This character wasn’t printed, instead there was a long space instead of the “ü” which was about double as long as the character would have been. After I saved the sign text and reopened the dialog, the text looked the same as before; no “<invalid multibyte-string>”

I had that invalid multibyte string problem too: server hosted on a windows machine, any linux clients got only invalid multibyte strings.
found out that this is about umlauts like ä, ö, ü, ß. windows saved these in an encoding differing from utf8. of course, other windows clients could read them, but linux had problems there.
solution: convert these umlauts to utf8 encoding.
maybe this is the problem of the minemacro server too. don't know this server, but if they use non-ascii chars, they should ensure using utf8 for them.

EDIT: My problem was regarding umlauts hardcoded into lua code which was saved by windows in another text encoding. Possibly, the minetest windows build sends text in this strange windows-specific encoding, and the server-side lua has to do an encoding conversion before saving the sign text.

orwell wrote:server hosted on a windows machine, any linux clients got only invalid multibyte strings.

Windows server?????
I think changing the server OS would be a GOOD idea.

This happens because the minetest_game saves the sign text in the map file, which is saved by the Windows kernel in a proprietary format, not in UTF-8. The map saves correctly because it does not contain non-ascii characters, but the sign text will be encoded because it contains those characters.
When the game reads that file, it reads the windows encoding, and sends the text encoded in the microsoft format.
Windows clients can properly show the string, while Linux clients fail and show the "<invalid multibyte string>" warning on the signs.

So the best solution is changing the OS of the server, from windows to linux.
This is because the 99% of the world servers use Linux. :D

jogag wrote:...
This happens because the minetest_game saves the sign text in the map file, which is saved by the Windows kernel in a proprietary format, not in UTF-8. The map saves correctly because it does not contain non-ascii characters, but the sign text will be encoded because it contains those characters.
When the game reads that file, it reads the windows encoding, and sends the text encoded in the microsoft format.
Windows clients can properly show the string, while Linux clients fail and show the "<invalid multibyte string>" warning on the signs.
...

rofl. You are completely wrong. 1. minetest_game saves nothing. The minetest engine saves the map. 2. The map is not saved by Windows kernel, its saved by minetest engine. 3. its not a proprietary format, its saved as blob value in a sqlite database. (or any other database that minetest supports).
All in all it does not care witch OS server or clients are using. The bug only happens, because minetest has a terrible support for Umlauts (äöü) or other special chars and is different from version to version.

BTW: This thread is relay old and the problem is maybe already solved.

jogag wrote:Windows server?????
I think changing the server OS would be a GOOD idea.

I think you have a serious fanatisism problem.
Sorry about this offtopic post.

Dragonop wrote:

jogag wrote:Windows server?????
I think changing the server OS would be a GOOD idea.

I think you have a serious fanatisism problem.
Sorry about this offtopic post.

I started hating windows when I detected a trojan in my laptop for the first time. Then I switched to linux, which is better for me. :)

addi wrote:

jogag wrote:...
This happens because the minetest_game saves the sign text in the map file, which is saved by the Windows kernel in a proprietary format, not in UTF-8. The map saves correctly because it does not contain non-ascii characters, but the sign text will be encoded because it contains those characters.
When the game reads that file, it reads the windows encoding, and sends the text encoded in the microsoft format.
Windows clients can properly show the string, while Linux clients fail and show the "<invalid multibyte string>" warning on the signs.
...

rofl. You are completely wrong. 1. minetest_game saves nothing. The minetest engine saves the map. 2. The map is not saved by Windows kernel, its saved by minetest engine. 3. its not a proprietary format, its saved as blob value in a sqlite database. (or any other database that minetest supports).
All in all it does not care witch OS server or clients are using. The bug only happens, because minetest has a terrible support for Umlauts (äöü) or other special chars and is different from version to version.

BTW: This thread is relay old and the problem is maybe already solved.

Oh, this is because I don't know much of windows, and minetest is made without thinking about issues with these characters... and Minetest is made and tested mostly on linux, so it's not often tested on windows. (thanks to people which test MT on windows!!!)

jogag, Minetest is usually tested on Windows and a bunch of distros. (some devs use Windows as main)
You got the trojan because you didn't use the software that you need to avoid that stuff, or you downloaded illegal stuff (not actually a risk if you know how).
Also, Linux also has viruses, thinking that it doesn't or saying that you have less riks is just dumb. (almost all the stuff is community created....)
You actually wont ever get any virus if you don't download a lot of stuff (witch I actually do, and I never get any viruses btw )

EDIT: what does this has to do with server hosting (I mean, you getting a trojan is not a valid option)

Dragonop wrote:jogag, Minetest is usually tested on Windows and a bunch of distros. (some devs use Windows as main)
You got the trojan because you didn't use the software that you need to avoid that stuff, or you downloaded illegal stuff (not actually a risk if you know how).
Also, Linux also has viruses, thinking that it doesn't or saying that you have less riks is just dumb. (almost all the stuff is community created....)
You actually wont ever get any virus if you don't download a lot of stuff (witch I actually do, and I never get any viruses btw )

EDIT: what does this has to do with server hosting (I mean, you getting a trojan is not a valid option)

I simply tried linux and I started using it because I wanted to switch OS.
And yes, there are windows developers, but I think most developers are on linux.
(There are viruses for linux, but they don't explode your pc while coding, and they want root password I don't give).

I changed my operating system but the problem still occurs. I'm using ubuntu server.

Problem solved. I needed the freetype. I compile the server properly.