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.
If the played types “GO TO (unvisited room)” the response is “That noun did not make sense in this context.”
Is it possible to change this response to either “You haven’t visited that room yet.” or “That’s not a room.” as appropriate? None of the rooms is a secret. I just don’t like the standard parser response much.
Thanks.
The Riverside Path example in Approaches’ docs addresses how you would simply allow ‘go to’ to work for unvisited rooms.
Understand "go to [any room]" or "go back to [any room]" or "return to [any room]" or "revisit [any room]" as approaching.
The new approach heading finding rule is listed instead of the approach-heading selection rule in the approach-finding rules.
This is the new approach heading finding rule:
now approach-heading is the best route from the location to the noun.
For sensible handling of unvisited rooms and nonsense, this is an approach…
Understand "go to [any room]" or "go back to [any room]" or "return to [any room]" or "revisit [any room]" as approaching.
Understand "go to [something]" or "go back to [something]" or "return to [something]" or "revisit [something]" as a mistake ("You can't go to that!").
[ previous, worse idea:
Understand "go to [something]" or "go back to [something]" or "return to [something]" or "revisit [something]" as thing-approaching.
Thing-approaching is an action applying to one thing.
Instead of thing-approaching, say "You can't go to that!" ]
Rule for printing a parser error when the latest parser error is the noun did not make sense in that context error:
if the player's command matches the regular expression "^(go\s+to|go\s+back\s+to|return\s+to|revisit)\s+", say "There's no such place.";
otherwise say "That noun did not make sense in this context."
Check approaching an unvisited room:
say "You haven't been there and aren't sure of the way." instead.
After deciding the scope of the player when approaching an unvisited room:
repeat with unvisited-room running through unvisited rooms begin;
place unvisited-room in scope;
end repeat.
The thing-approaching part is so that if the player tries to go to a noun that is in scope but isn’t a room they get “You can’t go to that” instead of “There’s no such place.” And if you have any enterable containers, there would be more cases you’d probably want to handle…
[edited: better than adding a bogus thing-approaching action, we can just understand it as a mistake]