smcameron
commented
9 months ago We may have a fundamental disagreement about how things should work. I gather you may be trying to build some physical consoles and want to map buttons on these consoles to keyboard keypresses. Keypresses are not button presses, they are separate things. I have a separate (unfinished) project for building physical consoles that relies on an entirely different mechanism to communicate physical interface button presses to snis_client: https://github.com/smcameron/snis-consoles It also allows for potentiometer inputs.
The notes section has the most details about my current progress: https://spacenerdsinspace.com/snis-consoles/notes.html
heaventwig
As currently instantiated, the comms screen does not allow (much) for the possibility of keybindings, because the input dialogue box has focus.
For accessibility and customization, both for those who are modding and making exterior IO devices or alternative interfaces, and for those for whom the mouse/trackpad is unworkable, it might help to make it possible to deselect the computer interface dialogue box and use the number keys (possibly modified with meta keys like shift, ctrl, and alt/opt/cmd).
The first solution that occurs to me, surely not the best possible, is to use the top row of the comms screen as a basis for the first layer of these menus -- press 1 to hail, 2 to select channel, shift-3 to put weapons on main screen, shift-7 to return main screen to its default "exterior forward camera" display, 8 to enter cryptanalysis mode, and so on. In this mode, the button attached to the /computer command might return focus to the input dialogue box, from which perhaps the ESC key would bring focus back out from that dialogue (and allow a second ESC to initiate the QUIT interface).
The other items in the comms screen that could then use associated actions are the red alert button, the mining bot button, the main screen toggle (to show recent messages on main, or not), and the zoom controls for the main screen. As a default, I'd suggest the following non-case-sensitive bindings r redalert m miningbot c commsonmain left keyunzoom right keyzoom
This then leaves the commands accessible through the typing interface. The most obvious ones to add to the numberkey line are the ones listed immediately in the help text: /inventory -- which turns out to produce identical output to the /manifest command /passengers /antenna which might be worth adjusting the interface to include these in the visual cue lineup at top of screen, in which case maybe there's some rationale to apply to the sequencing; it seems like they belong at least before the help and about commands. (I've just now noted in a separate report that the help info obtained by hitting f1 is quite different from the info obtained by hitting the help button or typing /help into the input box.)
Since manifest and inventory are synonyms, we have ten functions to assign to numeral keys. Convenient.
If I were resequencing those, I might go as follows, with things not in the current top-of-screen lineup, or in a different location in that lineup, in all-caps: hail, channel, ANTENNA, manifest (or inventory), PASSENGERS, eject, crypto, COMPUTER, HELP, ABOUT (and in case it wasn't clear: I'm not sure the help and about buttons belong here. I think they might more properly belong in top-line items, with the about button putting the credits up as an overlay on whatever else is on mainscreen, and the comms station HELP button -- not F1 -- maybe prompting the computer to put the help screen up on every screen on the ship as if they themselves had hit F1. Might want a confirmation dialogue box for that, too.)
... And reviewing this all before submitting it, I'm seeing that I didn't specify, and it seems worth specifying: what I would hope for after inputting a command like "hail" (with no arguments, whether as terminal input) would be to see a list of options. For HAIL, it might be a set of options like STARBASES, SHIPS, PLANETS (can we hail those yet?), and FACTIONS (because we can slice data in different ways!). Selecting STARBASES (default key 1) might bring up a list of those, perhaps showing each with its associated faction, its coordinates, its registration number, and a number to press to select it (better still: also show the number of missions available to start there, the number of missions you can currently complete there, and something about your current status with that faction); if there are more than ten of them, either require another layer of selection (eg by faction) or, if that's not a distinguishing feature (or if you've already selected a faction and there's still more than ten available interlocutors for hailing), I guess you could make 0 into a "next page" button so long as there are additional pages of interlocutors, and make 1 into a "prev page" button when you're not on the first page.
This does start to suggest another comms interface concept to me, which is to have two of those terminal-ish screens. Make one of them the computer terminal, maybe even having both the cursor and the stdout display, and direct all other comms traffic (Starbase Foo: "we're under attack again!") to the other (what I think of as the current) output screen. This separation of functions would make it possible to navigate even some rather complex menus without getting lost in a stream of starbase complaints about incoming fire. But properly that ought to be a separate issue report, I think. It's not even 100% clear to me that getting lost in comms traffic isn't a ... feature. It definitely evokes the ridiculousness of games like Space Team, and makes the comms station into a very information-management-heavy game.