I’d like to let a blank input make it through to the ‘after reading a command’ stage so that I can intercept it with
if the player's command is "";
… rather than it just going to ‘I beg your pardon?’
My goal is not to print a cute message in response, otherwise I would use a rule for printing a parser error or such as the docs advise. The reason I want to do this is so I can convert a blank input into a repeat of the previously entered command, which is easy to do once we get to ‘after reading a command’.
A caveat is that I am using Unified Glulx Input by Andrew Plotkin, which already contains an edited version of ParserInput. So I was hoping to poke a little modification in there?
“Neutral Library Messages” by Aaron Reed lists “I beg your pardon” as library message ID # 10 - no command given.
I know this isn’t exactly what you want - but it seems you could make a rule something like “If the error message is no command given: (do something else)”. I haven’t worked with redirecting error messages so I don’t know the exact syntax, but that would seem like the place to start.
#ifndef PASS_BLANK_INPUT_LINES;
! If the line was blank, get a fresh line.
if (evtyp == evtype_LineInput && nw == 0) {
! The old Keyboard routine cleared players_command here (to 100). I'm not sure why. If we're on buffer2/table2, the players_command snippet doesn't apply at all.
EmptyInputParserError();
continue;
}
In other words, it calls the EmptyInputParserError function if and only ifPASS_BLANK_INPUT_LINES isn’t defined.
And how does one define that? Well:
Use pass blank input lines translates as (- Constant PASS_BLANK_INPUT_LINES; -).
In other words, if you Use pass blank input lines, the empty input will make it through to all the normal “after reading a command” rules, where you can do what you like with it.
Btw, thanks for the idea, Hanon. I had vetted the idea of tapping the ‘I beg your pardon’ response, but capturing then re-executing actions is a more fraught path than just putting what the player really typed back through the parser. I already had some i6 code to do the latter that I used in Six, but that was in 6G60, and now that I’m using Unified Glulx Input too, it wasn’t safe to re-use.
PS I changed the topic title to SOLVED, which I saw someone else do, and seems like a good idea in general.
PPS In case Zarf reads this topic and was about to say something similar to: 'Beware the path you’re taking! Default mouse input will now no longer be blocked with an ‘I Beg Your Pardon!’ – I would reassure him that I’m only using line and character input in this project.
If you click the three dots under the post that solves the problem and then click the checkmark, it will mark that as a solution–then the checkmark shows up next to the topic title on the topics list.
I took the liberty of doing this–I’m not sure if it’s restricted to mods and the topic owner or what.
Fortunately, in the Unified Glulx Input model, there are three (and only three) parts of parsing that happen before “after reading a command” rules run: rejecting blank input lines, OOPS, and UNDO.
Use pass blank input lines will turn off the first part. Then you can write an “after reading a command” rule that detects blank lines, and “change the text of the player’s command” to “AGAIN”. This’ll work for anything except OOPS and UNDO.
If you’re not using Unified Glulx Input, use Empty Command Handling by Daniel Stelzer. Now you can write a rule “for repairing an empty command” and “change the text of the player’s command” to “AGAIN”. This will work even for OOPS and UNDO, if you really want that.
(But if a blank line acts as OOPS or UNDO, I have some deeper questions about your game design…)