I installed TADS 3 on Windows 10, using the latest release (from 2016). Mostly, it works well - however, there is one pesky error message I cannot seem to get rid of:
No mapping file is available for the local character set “cp65001”.
TADS itself treats all characters as unicode, but since most operating systems did not support unicode in their consoles, they relied on code pages to represent a certain subset of special characters. TADS offers mapping files for the most common of these code pages.
Ironically, cp65001 is the unicode code page for Windows, representing all characters as unicode. Therefore, there’s no need for a mapping file - all characters already are represented as unicode. Console support for unicode is relatively new, so the TADS VM doesn’t seem to realise that it doesn’t have to map anything here. It stubbornly tries to load a mapping file - one that doesn’t exist, and cannot get generated, since cp65001 represents the entirety of unicode.
I tried to tell my system to use a code page that TADS can deal with, but no matter which system variable I changed, TADS keeps showing the warning message - be it in web mode or console mode. I don’t know where the TADS VM gets its information about the used code page from and I don’t like fooling around with my system variables; usually, it’s recommended to leave cp65001 in place nowadays, only using more restricted code pages if absolutely necessary.
Does anyone know what to do to get rid of the warning? Is there even a possible fix for this, or is the tADS VM itself simply outdated and would need an update? (It has been five years since the last release; that’s a long time by software standards).
System-wide Unicode (aka cp65001) is a relatively recent addition to Windows:
It has a tendency of causing problems with programs expecting a “traditional” (non-Unicode) Codepage. Since the most recent version of TADS is older than that option, it’s quite possible that enabling it would cause trouble.
I’d recommend you check whether you happen to have that option enabled, and if so, disable it and see whether the problem goes away.
Yes, the both of you were right. Weirdly, the checkbox for system-wide UTF8 was unchecked, but my selected codepage was incorrect.
I reset the code page to what it should be and that fixed the issue.
I agree with George, however - eventually, more systems will adopt system-wide UTF8. If that happens, T3 shouldn’t fall back to ASCII.
Does TADS still get actively developed? I googled a bit but could not find any repositories which look like they’re for TADS 3 itself.
AFAIK, no. It seems the developer has been winding down his IF involvement (if one can put it that way, since he started 30 something years ago!). You can get some background searching in this forum.
But remember there is a difference between T3 the language, and the VM/interpreters-- you may have found RealNC’s repos on GH for example.
All that said T3 is still the work of MJR and for any real development to happen I think the community would have to mount a somewhat organized effort.
I agree. I hope such a community-driven effort to make something new or to improve something old happens at some point - my impression is that there’s still room for improvements, even in a genre as mature as text-based games/IF.
Well, my problem is solved, at any rate. Thank you.