So far we got several ideas:
I don’t remember the code point off my head but the pattern smells of utf-8 treated as ascii and the holes > 128 might match the multibyte codepoint, but I don’t have the tables around
My answer to PowerWyrm:
Hmm... that's too random to be anything in the code. I guess it comes from your font. Are these symbols in your font mapped to non-ASCII characters? Did you start from the original font file? A modified file?
Previously dev's already fixed similar bug, when it was possible to map only 128 or so symbols... and now there is problem only with other symbols, like 16-31 symbols, so it still could be a bug in code.
I've modified original file (resized it).
The numbers you list mostly correspond to control characters or other non-printable ASCII/extended ASCII codes. I would speculate that the numbers you are using to identify tiles are being fed through something that interprets them as codes of that type.
A nice tileset you have there. At a similarly nice license, I see. You deserve some help for sure and I suppose looking at the issue myself for a bit could not hurt.
More information would be appreciated. In linked posts you mention developer knows about the problem but I could not find any notes on the topic. Is it really that hard nut to crack or nobody could spare the time to investigate the matter?
Meanwhile TomeNET is now compiled locally on my Arch Linux. It is up and running. During loading the game complains your prf files are buggy in two ways (tested on 16x24). First, there is line announcing the name but it is not defining anything. Maybe you can just comment it out. Second, F:218 entry lacks a second colon and is probably ignored.
Could you please tell us how the failure exactly looks? I edited remapping of up staircase to 144 and got a thin +. 195 gets me Ã, 20 looks like a bursting O, 16 like majestic I, 2 gets me roughly this ▓, 157 seems empty, 17 has some waves. On the other hand zero is promptly ignored as if nothing was defined as remapping. Original symbol is displayed.
If on Windows you get no remapping behavior for the whole range you specified in opening post then the problem source is Windows specific, likely lying somewhere in main-win.c. Index zero is unlikely to be ever recovered as valid mapping since if I understood server code correctly it is used to denote absence of remapping.
Also, if you could get me bcf or pcf file for 14x20 size of your font that would help me somewhat. The 16x24t.pcf for which you provide download is too big for my display. I am unable to convert fon files because currently I have neither Windows nor wine.
Hi ho, Widmo!
Thank you very much for so interesting feedback. I'll add it to our headquarters ( viewtopic.php?f=9&t=1737
I suppose it's really hard bug, because dev's fixed similar bug in the past, but this particular one is unsolved for a long time and dev's got not idea what's the problem atm
Considering how errors looks.. I'll make an investigation and would post a report at headquarters.
there is 14x20:
http://mmoforum.org/images/games/tomene ... 1-8/fon.7z
http://mmoforum.org/images/games/tomene ... 1-8/prf.7z
Thank you very much for your time
What happens if you try to map to those characters? Based on the problematic characters, my guess is that something's interpreting them as control codes or something like that for some reason, but I don't think that narrows down the source of the problem very much.
it's becomes blank AFAIR, but I'll check it and post in headquarters soon!