Approaches by Emily Short

This topic is for discussions related to Approaches by Emily Short

When using example Easy Keys, after pressing GO, the following is displayed…

Report on Translation: FailedProduced by Inform 7 (build 6L02)
(Each time Go or Replay is clicked, Inform tries to translate the source text into a working story, and updates this report.)

Problem. I can’t find the extension ‘Plurality by Emily Short’, which seems not to be installed, but was requested by: ‘Include Plurality by Emily Short’ .

You can get hold of extensions which people have made public at the Inform website, www.inform7.com.

Because of this problem, the source could not be translated into a working game. (Correct the source text to remove the difficulty and click on Go once again.)

You can fix this problem by downloading and installing Plurality, as the error indicates. However, the functionality of Plurality (as far as I understand from my own similar issues) is basically standard now so that’d in effect duplicate something 6L02 already has.

Note that installing Plurality doesn’t mean adding the line “Include Plurality by Emily Short” to your own story file – Approaches already does that. Or tries to, at least.

If you have version 6 of Approaches, it looks like I did everything needed to make it independent of Plurality except to actually (doh) strip out the “Include Plurality” line. If you try cutting that line from the extension, it seems to work.

(I’ll upload a fixed version.)

I recently tried making Alias ‘The Magpie’ into an app using Simon Christiansen and Jimmy Maher’s AndroidIF app. Everything worked fine, except when my beta tester tried to use the Approaches extension to “go to [room]”, which caused the app to reset and the game to restart. Does anyone have any idea why this might be?

It would be an easy matter to remove the extension, but I’d also like to app-ify one of my other games, Renegade Brainwave, and Approaches is integral to its workings…

Have you tested this in a bunch of other interpreters?

The game’s been tested in every interpreter I could lay my hands on, and it plays nicely in all of them. It’s just the app-ified version that has the problem. Use the “go to [room]” command, and the game goes right back to the beginning.

It’s the same problem you get if you include Basic Screen Effects and do a “pause the game”, and the instructions for AndroidIF specifically tell you to avoid that, but Approaches doesn’t utilise Basic Screen Effects.

Huh. The instructions (https://github.com/SimonChris/AndroidIF) imply that “pause the game” will be unusable due to not opening the keyboard properly. I wouldn’t have thought the game would reset.

Is there something in the Approaches extension which might be doing keystroke input, or some other low-level UI operation?

I know that “pause the game” causes the game to reset because I left one in by accident. Using Approaches has exactly the same effect.

I’ve since made a further discovery. The extension Small Kindnesses by Aaron Reed includes a “GO BACK” command which keeps track of the player’s previous location and takes them back there. This also causes the game to reset. The common denominator in both extensions is “try going [variable]”.

The original test case for AndroidIF was Death off the Cuff, but since it’s a one-room game, I can’t check if the problem exists there too.

This is going to be a very random question, but what if you try converting a Release For Testing version into an app?

The reason I’m asking is that–though the whole thing is way above my pay grade–I wonder if the error has something to do with which action is action 0. In release versions, the GO action is action 0; in testing versions, it’s GLKLIST, whatever that may be.

So maybe if the testing versions behave differently, that tells you something? And maybe if they don’t that also tells you something.

1 Like

It’s above my pay grade too, but I like the idea. I might make a dummy game with just a few rooms and the extensions installed. If I can’t solve it, I can at least raise the issue on the Github site.

Jimmy Maher thinks this might be caused by a stack overflow, causing the game to reset.

I am afraid I am not actively maintaining this app any more, so raising the issue will only serve to notify others that it exists. I do accept pull requests, but someone else will have to do the actual coding.

Thanks Simon! I appreciate your going to the trouble of discussing it with Jimmy. I think I’ll just remove the extension for now, and find a workaround for the other game if I decide to make that an app too.

You’re welcome :). I am just happy that anyone is actually using this.

1 Like

My friend Mark, who is not a natural IF player, said using the app was his best experience of parser IF. He has nearly completed Alias, which blows my mind a bit.

Just out of curiosity, I took a look at it and managed to narrow the problem down to list handling. This is the minimal code that will also restart the game:

The list-test is a list of numbers that varies.

Instead of waiting:
	truncate the list-test to 0 entries.

If you can change the extension to use something other than lists (there are two, A person has a list of objects called the path so far and A person has a list of text called described motion) you should be able to get it working without crashing.

1 Like

Huh. (I say again.) The dynamic list code (I6 code) is ugly, but it’s also very well tested and it shouldn’t be doing anything that would behave differently between interpreters. Much less crash.

Thanks for looking into it further.

1 Like

It could be that in Memcpy Inform 7 assumes without checking that the @mcopy opcodes exists, but this Java Glulx implementation doesn’t support it.

Maybe. There are a lot of dynamic object operations in the library, though, what with texts and stored actions and so on. I’d be slightly surprised if that was the only one in a given game that hit this problem.

Someone will have to get error information out of the interpreter, I guess.

…I should clarify that I’d only be slightly surprised. Your theory is well within the bounds of Weird-Ass Inform Behavior we’ve seen over the years.