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.
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.
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.
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.
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.