PowerWyrm, yep, it's part of my font:
But it's not the case. I just showed you an example, that it's actually could be _code_ problem, not font. Again:
1) in current (stable) version of TomeNET client glyph #2 works perfectly
2) in test version of client - it become a 'door' (test client could be found at the bottom of this page:
https://tomenet.eu/downloads.php ).
Detailed video explanation of the bug:
https://www.youtube.com/watch?v=5AH61dV3JtQ
// it's temporary hidden video, accessible only by link, would be deleted soon
3) in the past (like ~6 months ago) #2 glyph didn't work either (that's why initially I marked it with 'X', when I just created 1st version of my font). So devs managed to fix #2 in current version, but then they did something wrong in test version of client (which I use right now while playing because of new music features).
This logic gives us an understanding that actually it's very like to be _possible_ fix 16-31 glyphs - cause #2 was recently fixed (and then broken again in test client).
Quote:
Originally Posted by PowerWyrm
This means the code would remap character "2" to something else, like it does for 16-31Unicode.
|
It does not!
If you would check my tileset, you would note that 1-15 symbols works perfectly although they has to be _dead_ (it's system symbols, the same as 16-31). But they works. They show not a system symbols, but glyphs which _works_.
I've wrote symbols which are showed at the place of 16-31 there -
https://tomenet.eu/phpBB3/viewtopic....start=10#p5176 (at oook forum they couldn't be pasted).
The are not remapped! 
It's just a symbols.
It leaves the main quesion very actual:
Why 1-15 glyphs works and 16-31 are not working? I believe that if we would be able to find an answer at this question, we would be able to fix the bug.