Twine 1.4.2 won't open on Windows 10

[greenbeams]

Hi there: I just installed the latest version of Twine 1 on my Windows 10 machine. Trying to open it only generates an error log, which I cannot fully suss out.

The full log is:
Traceback (most recent call last):
File “app.py”, line 325, in
File “app.py”, line 22, in init
File “app.py”, line 233, in loadPrefs
File “wx_misc.pyo”, line 165, in GetFont
wx._core.PyAssertionError: C++ assertion “wxFontEnumerator::IsValidFacename(font.GetFaceName())” failed at …\src\msw\settings.cpp(302) in wxSystemSettingsNative::GetFont():

The issue appears to be with fonts. I found a thread on the old Twine forum (http://twinery.org/questions/24593/when-try-open-twine-get-error-message-the-log-file-doesnt-exist) where the responder suggested that the error could be because of missing fonts, and said to check that Consolas and Courier New were installed. I have both those fonts. I can’t tell from the log what other font might be missing, or if it’s something else altogether.

Thanks!

[HiEv]

I did a bit more snooping, and it looks like, besides Consolas and Courier New, it also looks for Arial (arial.ttf), Arial Bold (arialbd.ttf), Arial Italic (ariali.ttf), Arial Bold Italic (arialbi.ttf), and possibly Aharoni Bold (ahronbd.ttf; but I think that last one is only showing up because that’s the first font I have alphabetically).

That said, I’d recommend switching to Twine 2.

If you have Twine 1 files, you can use the “Twine 1 compiled HTML to Twine 2 archive converter” utility from here to convert the Twine 1 HTML files to Twine 2 HTML files. Once you’ve done that, then you can import them into the Twine 2 editor. (Note: You may also need to update the game’s story format after you import it.)

Hope that helps!

[0x09tf]

I’ll assume here that you really have to use the obsolete Twine 1.4.2 system on Windows 10.

I’m no C++ programmer but it seems pretty explicit that while enumerating the fonts available on your system, it stumbled upon an “invalid face name” (whatever that means) and barfed big time.

File “wx_misc.pyo”, line 165, in GetFont
wx._core.PyAssertionError: C++ assertion “wxFontEnumerator::IsValidFacename(font.GetFaceName())” failed at …\src\msw\settings.cpp(302) in wxSystemSettingsNative::GetFont():

I did notice that TWine 1.4.2 installed a MSVC++ 2008 redistributable (x86) on my Windows 10 system. (It should not hurt to try it if it did not get installed by default.)

VC++ 2008 SP1 (Security Update – MFC) – v9.0.3.30729.6161
x86
Link: https://www.microsoft.com/en-us/download/details.aspx?id=26368
sha1: 470640AA4BB7DB8E69196B5EDB0010933569E98D

My little finger tells me that it “feels” like a Windows 10/system locale issue. I did install Twine for the heck of it on my [English (United States)] Windows 10 system and all went butter smooth. I used the default install directory too. My Windows system is pretty bland; never installed any other fonts on it; I just have Google Chrome/Gimp/Inkscape on it (and now the 32bit release of Twine 1.4.2)

On the other hand, a French, Cyrillic, Chinese, etc. Windows system might have non-ASCII characters in their fonts “face name” information; that might be the cause of the crash.

What I’d try:

• [plan A] Make sure you have latest VC++ 2008 SP1 x86 redistributable. (If it works, cool!)
• [plan B] Switch Windows 10 display language to English (United States) - it might take a while to download/update the language pack…
• [plan C] If it was already an English/United States system, browse your fonts directory and find/remove the guilty one(s)

[greenbeams]

Thank you both! I realize Twine 1 is old and not supported anymore; my current IF-in-progress would truly work best in Jonah. I did look into Palamo as a fallback, but unlike Jonah it disables historical links.

I will try your suggestions and see what turns up!

[greenbeams]

@0x09tf You seem to have put me on the right track; unfortunately, that track leads into rather murky waters.

The VC++ update did not change things. My system was already on English/US to start with, and I haven’t installed any new fonts (or much of anything: the OS is a recent installation I’ve barely touched.) I see many default fonts that Twine could be tripping over. However their names are all displayed to me as valid ASCII.

My options appear to be: 1) dig into the weeds of C++ to discover what a ‘facename’ is, 2) delete system fonts using guesswork and hope I don’t brick the OS or 3) try to make do with Palamo.

[0x09tf]

I’ve got another idea…

The official source code appears to be here:

tweecode/twine/blob/master/app.py

(unfortunately I’m also a Python illiterate!) lol

That’s our next interesting target if we traceback…

    def loadPrefs(self):
        """Loads user preferences into self.config, setting up defaults if none are set."""
        sc = self.config = wx.Config('Twine')

        for k,v in {
            'savePath' : os.path.expanduser('~'),
            'fsTextColor' : '#afcdff',
            'fsBgColor' : '#100088',
            'fsFontFace' : metrics.face('mono'),
            'fsFontSize' : metrics.size('fsEditorBody'),
            'fsLineHeight' : 120,
            'windowedFontFace' : metrics.face('mono'),
            'monospaceFontFace' : metrics.face('mono2'),
            'windowedFontSize' : metrics.size('editorBody'),
            'monospaceFontSize' : metrics.size('editorBody'),
            'flatDesign' : False,
            'storyFrameToolbar' : True,
            'storyPanelSnap' : False,
            'fastStoryPanel' : False,
            'imageArrows' : True,
            'displayArrows' : True,
            'createPassagePrompt' : True,
            'importImagePrompt' : True,
            'passageWarnings' : True
        }.iteritems():
            if not sc.HasEntry(k):
                if type(v) == str:
                    sc.Write(k,v)
                elif type(v) == int:
                    sc.WriteInt(k,v)
                elif type(v) == bool:
                    sc.WriteBool(k,v)

The line numbers don’t seem to match exactly but I’m curious to see if you managed to get as far as getting a Twine entry in the Windows registry?

If so we might be able to tweak it directly or create it from scratch… (

It should be in [HKEY_CURRENT_USER\SOFTWARE\Twine]

Mine looks like this one:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Twine]
"monospaceFontFace"="Courier New"
"windowedFontSize"=dword:00000012
"imageArrows"=dword:00000001
"fsLineHeight"=dword:00000078
"importImagePrompt"=dword:00000001
"fsBgColor"="#100088"
"displayArrows"=dword:00000001
"fsFontSize"=dword:00000010
"fsTextColor"="#afcdff"
"passageWarnings"=dword:00000001
"fastStoryPanel"=dword:00000000
"monospaceFontSize"=dword:0000000b
"storyPanelSnap"=dword:00000000
"savePath"="C:\\Users\\pitstop"
"windowedFontFace"="Consolas"
"flatDesign"=dword:00000000
"storyFrameToolbar"=dword:00000001
"fsFontFace"="Consolas"
"createPassagePrompt"=dword:00000001
"file1"="C:\\Users\\pitstop\\ttt.tws"
"file2"=""
"file3"=""
"file4"=""
"file5"=""
"file6"=""
"file7"=""
"file8"=""
"file9"=""
"file10"=""
"LastFile"="C:\\Users\\pitstop\\ttt.tws"

You want murky territory, I’ll give give you dangerously murky! lol

[greenbeams]

The plot thickens!

I had [HKEY_CURRENT_USER\SOFTWARE\Twine] in the registry, but it was completely empty. I tried spoofing it by pasting in your version, changing “savePath” to my own directory and setting “file1” and “LastFile” to blank. Alas, running Twine logged the same error as before.

I think you’re right, the answer must be in app.py somewhere.

I do worry, even if we manage to claw Twine 1 back to a working state, will a Windows update just snatch it away again a year from now? I may have to scrape together enough JS know-how to fork Palamo or Snowman myself, if I want Jonah back. A distant prospect.

[HiEv]

If you just want Jonah, I did write up some code to make SugarCube present the passages in a Jonah-like fashion, though there are a few caveats in using it. See the details my reply in this Reddit post: “Modify scroll down JS code”.

Hope that helps!

[0x09tf]

@greenbeams

I had [HKEY_CURRENT_USER\SOFTWARE\Twine] in the registry, but it was completely empty. I tried spoofing it by pasting in your version, changing “savePath” to my own directory and setting “file1” and “LastFile” to blank. Alas, running Twine logged the same error as before.

Are you sure you got the same error as before? I don’t speak Slytherin but the Python code seems to indicate that LoadPrefs() not only loads the current preferences but sets them up as well if they are not present.

The idea here is to manually do/bypass the job of LoadPrefs by editing the registry.

WARNING: editing the registry might brick your windows installation, be hazardous to your health etc. especially if you’ve got a psycho kitty lurking around ready to jump on your keyboard or an angry spouse ready to smash your keyboard over your head (you know you’re guilty.)… As long as you’ve got a steady hand and basic self control, you should be fine!

Copy the following in a plain text file and save it with the “.reg” extension.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Twine]
"monospaceFontFace"="Courier New"
"windowedFontSize"=dword:0000000b
"imageArrows"=dword:00000001
"fsLineHeight"=dword:00000078
"importImagePrompt"=dword:00000001
"fsBgColor"="#100088"
"displayArrows"=dword:00000001
"fsFontSize"=dword:00000010
"fsTextColor"="#afcdff"
"passageWarnings"=dword:00000001
"fastStoryPanel"=dword:00000000
"monospaceFontSize"=dword:0000000b
"storyPanelSnap"=dword:00000000
"windowedFontFace"="Consolas"
"flatDesign"=dword:00000000
"storyFrameToolbar"=dword:00000001
"fsFontFace"="Consolas"
"createPassagePrompt"=dword:00000001
"file2"=""
"file3"=""
"file4"=""
"file5"=""
"file6"=""
"file7"=""
"file8"=""
"file9"=""
"file10"=""
"savePath"="C:\\Users\\greenbeans"

You can use Notepad; just make sure to select Save as Type: “ALL FILES” and manually set the filename to Twine.reg. (if you save it with a .txt extension, double clicking on it will simply reopen Notepad)

You should have a file with an icon looking like a bunch of blue cubes. (meaning it’s a windows .reg file)

Double click on it to automatically get the registry keys registered. You should get a few warnings about impending doom etc, etc… they’re right; you should not just randomly execute .reg files from strangers on the Internet!

Double check with regedit to make sure that the Twine keys were indeed created.

If you run Twine 1.4.2 again you should definitely get a little further; at least it should not choke on the LoadPrefs() subroutine since all the registry keys are already created…

[greenbeams]

Thanks! I tried this code out; it gives me stretchtext but not the feature I most want, which is active historical links. When you scroll up to a previous passage in Jonah, you can select a different choice and the story will rewind and take you down that new branch. Given how Sugarcube works, I suspect that your code can’t be quickly extended to allow active historical links, (perhaps I’m wrong there.) Palamo also disables the links in previous passages.

[greenbeams]

@0x09tf I had updated the registry using your example in the previous post. To double-check that I hadn’t made a mistake in the process, I deleted out the entry and updated the registry again using your second example. (A direct copy-paste, editing only the savePath value to match my Windows username.) I also rebooted my computer afterwards, just in case.

No luck! Twine continues to log the same error from my original post when I try to open it. Apparently the LoadPrefs function will run regardless of if Twine has a registry entry.

Here’s a screenshot of my [HKEY_CURRENT_USER\SOFTWARE\Twine] entry in the registry GUI:

[0x09tf]

@greenbeams

No luck! Twine continues to log the same error from my original post when I try to open it. Apparently the LoadPrefs function will run regardless of if Twine has a registry entry.

I believe you!

It looks like my lack of understanding of python source code is starting to show! (I don’t know what I was thinking…)

But back to loadPrefs, I’m pretty sure we have to focus on this area:

... etc
        for k,v in {
... etc
            'savePath' : os.path.expanduser('~'),
            'fsFontFace' : metrics.face('mono'),
            'fsFontSize' : metrics.size('fsEditorBody'),
            'windowedFontFace' : metrics.face('mono'),
            'monospaceFontFace' : metrics.face('mono2'),
            'windowedFontSize' : metrics.size('editorBody'),
            'monospaceFontSize' : metrics.size('editorBody'),
        }.iteritems():
... etc

So basically we have this funny os.path.expanduser call; unless you’ve got a funny looking windows username (with spaces, accents, funny characters etc.) I don’t think there is anything to worry here.

The more smelly ones are the metrics (as in metrics module?) calls. A quick call to Google can’t give me any definitive answer on what this metrics module really is. (it does smell like it is font related… )

If you’re in for a wild ride we might as well install a Python/wxPython development environment and start Twine directly from a Python interpreter as hinted here:

GitHub - tweecode/twine: UI for creating hypertext stories

[0x09tf]

Well guess what; it finally is not that complicated to get your own Twine 1.4.(3) running from scratch!

1. Download the appropriate Python Environment [https://www.python.org/ftp/python/2.7.18/python-2.7.18.amd64.msi]
2. Download an old wxPython compatible with that old Python installation [https://sourceforge.net/projects/wxpython/files/wxPython/2.9.5.0/wxPython2.9-win64-2.9.5.0-py27.exe/download]
3. Download Twine’s python source code/unzip/double click on app.py [https://github.com/tweecode/twine/archive/master.zip]

Voila! (you even get a 1.4.2 to 1.4.3 upgrade in the process)

The magic might actually be in that wxPython download that makes sure we have the necessary dlls…

[tayruh (null)]

metrics.py is in the root of the Twine project. It just assigns fonts and font sizes based on OS. There’s nothing special there.

I’m beginning to wonder if the OP actually has consolas working correctly? I’ve heard cases where it got uninstalled or corrupted somehow.

[0x09tf]

yes I found my glasses and metrics.py jumped right out of nowhere! lol

[tayruh (null)]

Don’t worry. I was googling for it yesterday before realizing it was a local file. The name just sounds so much like a module that I didn’t even consider it. Plus there actually is a wx.FontMetrics module, but it’s completely unrelated.

But yeah, going over the source code, I don’t see why anything would fail. I don’t even see why it would fail in the middle of writing the configuration since it doesn’t attempt to access any files. Even if the user name directory is wonky like you suggest, it’s only writing the name to the registry, not attempting to access it. In theory the registry should finish writing and then fail when attempting to load or save files.

[greenbeams]

The saga concludes: I have Jonah back (and the rest of Twine 1.4.3). Thanks so much for your persistence! I would’ve lost hope by now, otherwise.

[HiEv]

If you haven’t already, you might want to consider posting this fork on GitHub or somewhere like that. That way other people who need it can have access.

Thanks.

[0x09tf]

@HiEv

If you haven’t already, you might want to consider posting this fork on GitHub or somewhere like that. That way other people who need it can have access.

Oh, we did not fork anything I think… (Not on my part anyway!)

In a desperate move to get past that dreaded error message, we just downloaded the latest 64-bit binaries we could find that I thought would still work with the latest Twine 1.4.x code base and hoped for the best… …and we finally scored!

I agree that a more up to date “package” for 64bit Windows systems might not be such a bad thing after all…

Unfortunately, I have no idea how things work on twinery.org where the official packages seem to be currently hosted…

I have to admit that I kind of like the default looks of the older story formats too! I’m actually in the mood of messing with them just to see what I’m missing and to see for myself what the deal is all about with the old Twine release vs the current browser based one…