|
(0027706)
|
|
TAS2012
|
|
2014-11-10 06:16
|
|
Thanks for pointing this out to me. I should have read the (updated) options guide before posting here. So, include=old_unicode_glyphs.txt seems to mimic the old char_set=unicode behaviour.
However, it is still quite confusing to the user, or at least to me. Since the "new" unicode glyphs (really: char_set=default) do not use solid wall symbols or the · floor symbol, which was for me when testing this often the only thing I could see to differentiate between "unicode" and "ascii" I didn't see the char_set option switch doing anything at all and doubted its functionality. Analyzing this was made even more troublesome by the fact that even after adding the include line as above (changing the symbols to the old unicode style) the char_set setting was doing nothing. Perhaps the included lines override the char_set=ascii somehow?
Also, "old" in old_unicode_glyphs implies to me that this is some outdated, no longer to be updated, conservationist setting (further emphasized by moving the setting from standard options settings to using the lesser known include syntax) like the 0.xx_monster_glyphs settings. If this is really the case, perhaps it should be 0.15_unicode_glyphs for future clarity of what "old" is referred to.
For those who just want the old non-ascii walls/floor style but other glyphs being updated as Crawl development goes on (like what the non-ascii char_set settings used to do), the real way to mimic old behaviour seems to *not* be to use the include line as above but rather to replace their old char_set=foo with char_set=default and adding:
display_char = wall:?
display_char = permawall:?
display_char = wall_magic:?
display_char = floor:·
Otherwise they will be "frozen" in symbols development and, as an example, not getting the recent change of † as the corpse symbol.
I was trying to find some reason for switching to ascii-style walls/floor even in non-ascii mode, but couldn't find any. Could it be an oversight? |
|