0 votes
by (220 points)
edited by

I've been bopping around with Harlowe for a while now, trying to achieve a functional inventory (+ "return") system. I just got it close today and it threw this error.

Even when I deleted every single passage (seriously!) it kept throwing the error.

Here's what it says:

Sorry to interrupt, but this page's code has got itself in a mess.
TypeError: Cannot read property 'get' of undefined
         at u
         at Object.goToPassage
         at HTMLDocument.<anonymous>
         at f
         at p
(This is probably due to a bug in the Harlowe game engine.)        

I figured I'd ask here first in case it, y'know, ISN'T a bug with Harlowe and I've made some terrible mistake somewhere.

Here's my file, in case that helps any. I'm using Harlowe 2.1.0. 

 

ETA: Ended up copying all my passages out into a new project, which fixed it. Turned out to be the coloured tags that was causing this error, which unfortunately you don't seem to be able to cancel out of. I fixed it by just... avoiding most tags. Eek.

2 Answers

+1 vote
by (63.1k points)
edited by
 
Best answer

ETA: Ended up copying all my passages out into a new project, which fixed it. Turned out to be the coloured tags that was causing this error, which unfortunately you don't seem to be able to cancel out of. I fixed it by just... avoiding most tags. Eek.

Yeah, I think this is a Harlowe bug.  I'm surprised a new version of Harlowe wasn't released alongside Twine 2.2.0 to address this, as it seemed to also be present in the beta.  I suggest creating an issue in Harlowe's repository to let the developer know.

edit. 

This is a bug in the 2.2.0 release. It's been fixed on the repo, so an update is likely coming. See @greyelf's answer and comment below for more. 

Also, a new version of harlowe was in fact released with Twine 2.2.0. I mistook 2.1.0 for 2.0.1 and have been apparently doing so all day. 

by (159k points)
edited by

This is not a Harlowe story format related bug, as projects based on SugarCube also fail with a similar error.

The issue (Issue #428) is caused by web-browsers not understanding the new self-closing tw-tag element (being used to represent tag colours) that was introduced in the new Twine v.2.2.0 application.

As explained changing this new element from <tw-tag /> to <tw-tag ></tw-tag> fixes the issue.

0 votes
by (159k points)
edited by

EDITIssue #428 on the Twine 2 project repository explains what is causing your error and you can fix it yourself by temporary removing the colours from your tags. This issue effects SugarCube as well as Harlowe.

I imported your sample project into the installable release of the Twine v2.2.0 application (so I could easily access the new Harlowe v2.1.0 story format) and I received the same error as you did when I used either the Test or Play options.

I did not receive that error if I:
a. Imported the same sample project into the web-based release of the Twine v2.1.3 application.
b. Updated web-based related of the Twine v2.1.3 application to use the new Harlowe v2.1.0 story format.
c. Created a new Harlowe v2.1.0 based project in Twine v2.2.0 and transferred your Passage/CSS code across piece-by-piece.

While transferring your passage/CSS content I notices a number of issues with it:

1. The (set:) macro in your "Last Passage Tracking" passage is miss it's open parenthesis, it should be...

(if: not ((passage:)'s tags contains "menu"))[(set: $lastPassage to (passage:)'s name)]

2. By default the tagged special passages (like startup, header, and footer) add any visual content (like line-breaks) within them to the output of the current passage, the best way to hide any such visual content is to use CSS like the following.

tw-include[type="startup"], tw-include[title="Last Passage Tracking"] {
	display: none;
}

3. By default the visual content of both the header and footer tagged special passages are append in-line to the output of the current passage, the best way to force that content to appear on its own line is to use CSS to change the "display" property of those HTML elements to "block".

tw-include[title="Header"] {
	display: block;
}
tw-include[title="Footer"] {
	display: block;
}

4. If you want your header or footer tagged special passages to include a horizontal line between them and the output of the current passage then you should use one of the CSS "border" related properties like so. (I have also included the CSS from point 3.)

tw-include[title="Header"] {
	display: block;
	border-bottom: 1px solid #D3B0D6;
}
tw-include[title="Footer"] {
	display: block;
	border-top: 1px solid #D3B0D6;
}

5. Your "Header" passage contain conditional situations where you have "<!--Do Nothing-->", this indicates that the structure of your (if:) related macros is wrong. You are also combining (go-to:) macros with markup based links  within the associated hook of your "Home Inventory" (link:) macro, which is interesting to say the least.

Try replacing the contents of that passage with the following, I believe it achieves the effect you were looking for.

(if: not ((passage:)'s tags contains "noheader"))[\
(set: _passageName to (passage:)'s name)\
(set: _inventories to (a: "HomeInventory", "WorkInventory"))\
[[Smartphone]] | You have $bank credits.\
(if: not (_passageName is "Pockets"))[ | [[Pockets]]]\
(if: not (_inventories contains _passageName))[\
(if: $location is "Home")[ | [[Home Inventory|HomeInventory]]]\
(else-if: $location is "Work")[ | [[Work Inventory|WorkInventory]]]\
]\
]

6. The (click:) macro scans the textual contents of the whole HTML document, and not just that of the Passage it was called within. In the case of your "Pockets" passage this will result in it finding two instances of "Smartphone", the one in the passage itself and the one in the output of the "Header" passage. This leads to two issues:

a. The HTML structure of the header "Smartphone" link is changed to become a link embedded with a link, this means that the Target Passage Name associated with the original markup based link is overridden by the Target Passage Name referenced by the (goto:) macro, which in this case is the same Target Passage Name.

<!-- HTML structure before the (click:) macro was executed. -->
<tw-expression type="macro" name="link-goto">
	<tw-link tabindex="0" passage-name="Smartphone" data-raw="">Smartphone</tw-link>
</tw-expression>

<!-- HTML structure after the (click:) macro was executed. -->
<tw-expression type="macro" name="link-goto">
	<tw-link tabindex="0" passage-name="Smartphone" data-raw="">
		<tw-enchantment tabindex="0" class="link enchantment-link">Smartphone</tw-enchantment>
	</tw-link>
</tw-expression>

b. The colour of the header "Smartphone" link changes colour due to it becoming .enchantment-link CSS class based instead of tw-link element based, and your existing link related CSS rules don't support both of Harlowe's link types. Changing your CSS to the following will fix the colour issue but not the link embedded within a link issue.

tw-link, .enchantment-link {
	font-size: 1.0em;
	font-family: "times";
	color: #55EAC1;
}
tw-link:hover, .enchantment-link:hover {
  	font-family: "times";
  	color: #B021A1;
}

7. Passage targeting links that have been previously selected are assigned a .visited CSS class, your existing link related CSS rules are not taking this into consideration. Adding CSS like the following will fix this oversight.

.visited {
	color: #55EAC1;
}
.visited:hover {
  	color: #B021A1;
}

8. According to the Harlowe v2.1.0 documentation (and the error messages being issued by the story format itself) the (transition:) macro doesn't support "fade-in" nor does it accept a second parameter to indicate the transition time. The transition time can be adjusted by using the (transition-time:) macro.

...