Something that has annoyed me for a while is when press-any-key functions are too eager to proceed. Despite their names, players probably don’t want absolutely every key to continue - they will want navigation keys, such as page up/down to be ignored. They’ll also want the mouse scroll wheel to be ignored! (Gargoyle, I’m looking at you!)
I’m working on a better function, which I hope can be included in the next version of Inform 7’s Basic Screen Effects extension. But I need your help!
Please run these files in all the interpreters you have. If they show any numbers that means those interpreters’ navigation keys aren’t being filtered, so please tell me here!
There’s also a poll - the files will filter out Space and Enter, but I’m not sure whether they should be or not. If anyone uses them to page through long text dumps, they might warrant being filtered out. What do you think?
While it would be appropriate for the interpreter to handle the mouse wheel better, it can’t handle the arrow keys for example. If you’re using them to scroll through a long page of text which ends with a press-any-key request, it shouldn’t accept the arrow key because then you’ll miss a lot of the text.
And while perhaps it would be possible for the interpreters to not send key presses which scroll the text buffer to the game, it’s a small change to make to the game code which will work now rather than waiting for every interpreter to be updated.
If space and/or enter is ignored, the problem becomes the wording. “Press any key except space and enter”? It’d be weird if the game asked to press any key but space or enter wouldn’t work (which is probably what most people will press when asked to press any key).
Perhaps the interpreter should ignore all keypresses unless the “press any key” prompt is in view. Or even better, pressing any key (except navigation keys) scrolls the screen down to the prompt, and pressing again triggers the press-any-key request.
Juhana, I think I agree with you that Space and Enter are the most likely keys. I don’t think what you’re suggesting in the second paragraph is really possible. Or, at least it would take a lot of work and time to get all the terps to come to consistent behaviour. Filtering out the arrow keys and mouse wheel might be enough. But asking everyone is still worthwhile - one of the keys I’m filtering out now is ? because Gargoyle/Bocfel converts the mousewheel into it. There could be other unusual conversions in other terps.
(I think this first became aware of this problem playing To Hell in a Hamper in Gargoyle - there are several initial pages of text which the mousewheel will quickly go through.)
For what it’s worth, I agree that this should be handled in the interpreter as much as possible. (And mouse events should never be passed to the game as key events.)
But you’re right that char input is trickier than line input. I page through long text with the space bar. And it seems weird to exclude space from “hit a key to continue”; that’s also a common convention.
The best practice, I guess, is to not follow a long text-dump with “hit a key” and then a screen clear.
Or: it’s a change which a couple of games this year will make, whereas an interpreter change will improve life for all games.
I’m more fond of: pressing any (textual) key scrolls down one page if there’s unseen new text. Once the input (prompt) line is in view, keys go there instead.
(Note that “unseen new text” is not the same as “text off the bottom edge of the window.” If I scroll back up from the bottom, the input line should keep the keyboard focus. Distinguishing these cases is what the little “MORE” tag in the bottom corner is for – if it’s present, it has keyboard focus.)
I guess you’re right that interpreters should do their bit to fix this. What’s the best way to get them to change? I’ll have to think long and hard how I could do it in Parchment, which doesn’t really care about paging. Perhaps I could just make it ignore the Space key unless the bottom of the page is in view.
I see no harm though in filtering out the arrow keys and pg up/down. And if it does make it into the next I7 release, all the better.
In truth, the only thing I would like to filter is the mousewheel, because it isn’t a key. If the only way to block the mousewheel is to block some actual keys, then I accept the need to block them. To me, the arrow keys are super key-y, and the page up and page down keys are kind of key-y. I’d be irked if it said ‘press any key to continue’ and I hit down arrow and it didn’t continue, because that’s totally a key and I press it all the time. Paradoxically I know that’s why you think to block it, but yeah, I don’t like that.
If there’s one big key on my keyboard that I count as “the any key”, it’s the space bar, and barring that, it’s Return. Ignore those two buttons and rig up a hidden cam, and you can then post a funny gif of me, bashing my keyboard like mad while screaming “It Says Press Any Key!”.
