I’ve been searching with Google’s ‘site’ function, and on this site by all kinds of terms and suspected authors, but I can’t re-find the post I’m looking for. I expect it was during the last few weeks or months.
A person I suspect was @Draconis or @Dannii, but may have been someone else, chimed in on some tech help topic about lopping unnecessary words off the end of an entered command, running the action from the bit that was left – and maybe throwing in a line to say ‘Hey, you didn’t need to type that extra stuff/noun’ at the same time. Of course, this may not be what the subject line is/was about. It might have been an incidental observation.
While I expect I or YOU (whoever’s reading this) could concoct code for this now, I’d very much like to see that post again first. If you’re responsible for the post, remember who was, or can manage to scrounge it up, it would be much appreciated.
I tried searching “after reading a command” in quotes and quite a few interesting ideas came up but none hat were exactly like what you described. Maybe that search could help you? Sorry if you already tried it!
Speculating wildly, but I doubt this was about “after reading a command”, because that sort of solution to the problem has been in use forever. It was probably about “printing a parser error”…
The parser error that should be relevant to this is JUNKAFTER_PE, but that’s literally never used by the I7 parser. So maybe it’s UPTO_PE, the “I only understood you as far as” error? I7 calls these the “only understood as far as error” and the “didn’t understand the way that finished error”. Looking at the value of wn when one of these is printed would let you trim off the misunderstood words and evaluate the command up to that point.
Unfortunately, searching either the I6 or the I7 names of these doesn’t come up with much. But maybe it’ll jog someone’s memory.
Yeah, when you said that, I think I remembered this post mentioned that. It was about rerouting that error to running the functional bit of the command. And the poster said something like “And this is the start of / this is the beginnings of a an automatic correction system.”
But I’ve now combed “I only understood you as far as” on the site, as well as variations of auto/automatic/automated-correction etc. in all variations of hyphenation and plurality, and I still haven’t turned it up! I mean I can’t even find it in posts preceding this year. Because the most obvious error I could be making here is that maybe I thought it was recent, but perhaps it was mentioned in an older post I happened to come across in yet another search.
Closer than most things I’ve found when I searched for this… but still not especially close to your description.
I’ll note that your description overlaps the domain of Smarter Parser, which includes this error message: You don't always need to specify what you're doing something with. and does refer to auto-correction.
MathBrush’s Let’s Play/Read: Inform 7 manuals (Done for now) was recent, covered an enormous amount of territory, and, having been in the Playing > If Reviews and Essays category, might have escaped what people thought to search for. That said, I didn’t find anything relevant there either…
Ugh, I think that IS that, because that is what I’m trying to do … Good call, peach. Way to post again! I’m going to mark that as a solution so people can stop searching.
Adding Smarter Parser itself now would probably be (a) technically impossible (I doubt it works with Unified Glulx Input) and (b) like throwing a series of grenades into my carefully tested project. But yes, maybe I can crib from it to assist in what I’ll be trying to do.
So I’ve been playing around a bit with “Cave-troll”, and I’ve noticed that if you just type ATTACK TROLL WITH – that is, without specifying what you want to attack the troll with – the game keeps repeating “(ignoring the unnecessary words “attack troll with”)” and the game hangs.
Unfortunately, I don’t know enough about regular expressions to know what’s causing it.
It also hangs for commands like >ATTACK TROLL FORTHWITH or >ATTACK TROLL WITHOUT DELAY.
The issue occurs because the preamble of the first rule does not use regular expression mapping, so it is not sensitive to the position of the substring “with” in the player’s command. As a result, the parser error flag is set. However, no change is made to the player’s command because the code to do this does use regular expression matching and does not see the same substring as relevant. No parser error is printed, but the next iteration of the reading a command activity sees the same player's command, so there is an infinite loop.
The preamble of the rule can be changed to use the same regular expression comparison as the rule body’s code:
Rule for printing a parser error when the latest parser error is the only understood as far as error and the player's command matches the regular expression ".* with .*$":
This ensures that when the rule preamble matches, the player’s command will be changed.